テクノロジー · 実用ガイド
Python の BrokenProcessPool？再作成前に worker の終了境界を保存する
例外が示すのは worker の非正常終了だけです。task、PID、開始方式、stderr、終了状態、OOM 証拠を保存してから修正を選びます。
BrokenProcessPool は OOM や __main__ エラーを断定しません。ProcessPoolExecutor の worker が正常終了しなかった境界です。
1 件の失敗を task、worker、OS event に結び、証拠に合う修正だけを行い、同じ task と通常 task の両方で検証します。
1. pool 再作成前に失敗を固定する
task ID、入力 fingerprint、時刻、Python、platform、executor 設定、start method と例外 chain を保存します。
自動 retry より先に同じ module、initializer、start method、limit で 1 件へ縮小します。
2. entry point と process death を分ける
保存済み __main__ の import、guard、callable・引数・戻り値の pickle を確認し、同じ方式で単純な top-level 関数を実行します。
単純 task が始まらなければ entry point 側、実 task 開始後に壊れるなら終了証拠へ進みます。
3. worker 終了境界を捕捉する
task ID、PID、initializer、task start、stderr、faulthandler を pool 終了後も残る場所へ記録します。
private 属性を恒久 API にせず、version ごとの exit code、signal、host crash log を保存します。
4. signal、OOM、deploy event を関連付ける
Linux では memory.events の前後差を取り、同じ時間窓の oom_kill 増分だけを OOM 証拠とします。
peak memory、並列数、input size、restart と operator kill を同じ timeline に置き、証拠がなければ未解決にします。
5. 証明済み原因だけ直して二重検証する
entry point、native extension、capacity、supervisor を原因別に修正します。
同条件で元 task を再実行し、同じ pool で普通の task も成功し、新しい crash/OOM event がないことを確認します。
