長時間のPython処理を検証済みの結果まで追跡する

1. 画面が混同している4つの状態を区別する

接続が開いていることは、まだマシンと対話できることだけを証明します。見えているターミナルが、すでに計算が終了したシェルを保持していることもあります。逆に、接続を失ってもプロセスが停止したとは判断できません。まず実行とその痕跡を確認する場所に名前を付けましょう。

プロセスの存在、業務上の進捗、結果の受け入れを別々に追跡します。ログの行数は成功したデータのカウンタではありません。プログラムが同じ警告を繰り返すこともあります。部分的な出力は、読み取れても不完全である可能性があります。

この方法は、必要なアクセス手段を受け取り確認済みであることを前提としています。特定のアクセスプロトコルやファイルの自動保存を約束するものではありません。利用可能なツールと保存先は、実際に提供された環境で確認する必要があります。

表をスクロールしてすべての列を表示してください。

各観察は異なる問いに答えます。
観察	それが示すもの	それが証明しないもの
接続がアクティブ	チャネルが応答している。	計算が進んでいる。
プロセスが存在する	実行がまだ存在している。	正しい要素を処理している。
検証済みカウンタが増加	予定された単位が完了している。	コーパス全体が完了している。
終了コードがゼロ	プログラムが正常終了を通知している。	結果があなたの契約を満たしている。
検証済みの出力を取得	選択した基準が検証されている。	その基準を超える品質。

Python: 終了コードの意味

2. 切り離す前に識別可能な実行を準備する

データ、実際の構成、アプリケーションの短い初回実行を確認します。GPU診断は別の問いに答えます。バックエンドが計算を実行できるかどうかです。コーパス全体の読み込みやプログラムのロジックを検証するものではありません。長時間の実行を開始する前にこれらの確認を行ってください。

実行識別子と新しいフォルダを選びます。秘密情報を含まないコマンド、コードのバージョン、入力の識別情報、期待される結果を保持します。ログの書き込み先とファイルの取得先を決めておきます。2つの実行が同じフォルダに同時に書き込んではいけません。

独立したパーティションに分割された作業では、パーティションがいつ完了するかを決めます。計算の完了、ファイルのクローズ、内容の検証、状態の記録です。書き込み中のファイルは、受け入れられた結果と同じ意味を持ってはいけません。開始前に実際に使用可能な容量も確認してください。

3. 状況が許すときは見つけられるターミナルを保つ

環境に Unix シェルと tmux が用意されている場合、このマルチプレクサを使うとターミナルをデタッチし、再接続後に再び見つけることができます。これは接続クライアントの喪失からこの作業を保護しますが、マシンの再起動やプロセスの破壊後の復旧機構ではありません。

以下のコマンドは教育用であり、実行されません。Bash、tmux、そして示されたオプションを備えたあなた自身のプログラム traitement.py を前提としています。このファイルは提供されるリソースではありません。まずその短いコマンドを確認し、2つの計算を混同しないよう別のセッション名を使用してください。

セッションを作成し、その中で2番目のブロックを起動します。フォルダの作成はすでに存在する場合は失敗し、これによりそのログを暗黙的に再利用することを防ぎます。シェルが書き込み段階に到達すればリターンコードは保持されますが、突然の停止によりこのファイルの作成が妨げられる可能性があります。したがって、コードの欠如は暗黙の成功ではありません。

デフォルトのショートカットでは、Ctrl-b の後に d でデタッチします。再接続後、セッションを一覧表示してから正しいものを再アタッチします。プログラムが終了していてもシェルは表示されたままになることがあります。ログと記録されたコードを確認してください。以前のターミナルが消えたからといって、すぐに 2 つ目のコピーを開始しないでください。

セッションを作成する — 教育的なコマンド

tmux new -s campagne-a

セッション内で — 適応させる例、実行されない

mkdir -p runs
mkdir runs/campagne-a && (
  code_retour=0
  python -u traitement.py --config config.toml --output runs/campagne-a \
    > runs/campagne-a/execution.log 2>&1 || code_retour=$?
  printf '%s\n' "$code_retour" > runs/campagne-a/exit-code.txt
  exit "$code_retour"
)

再接続後 — セッションを見つけ直す

tmux ls
tmux attach -t campagne-a

4. 活動量だけでなく、受け入れられた作業を数える

Python の -u オプションは、標準出力と標準エラー出力のバッファリングを解除します。これは出力されたメッセージを見やすくするのに役立ちますが、アプリケーション内に進捗イベントを作成するものではありません。ライブラリや無音のステップでは、依然として独自の観測が必要になる場合があります。

理解しやすいフェーズを定義します。読み込み、準備、計算、書き込み、検証です。単位が安定したカウンターと、既知の場合は合計を追加します。受け入れられたパーティションを数えている場合、その名前を変えずにログの途中で読み込んだ行数のカウンターに切り替えないでください。

次の教育用の例は、500要素の8つのパーティション、つまり4000要素を扱います。図示された時点では、5つのパーティションのみが受け入れられています。6番目は部分的であり、合計を膨らませてはいけません。数値は計数の規則を示すものであり、Kernodeckのいかなる実行も記述していません。

表をスクロールしてすべての列を表示してください。

実行されていない教育用スナップショット: 8つのうち5つのパーティションが受け入れられています。
パーティション	状態	受け入れ済みとして数えられる要素	判断
1 から 5	検証済み	2 500	それらの識別子と結果を保持する。
6	部分的な書き込み	0	このパーティションを完了として通知しない。
7 と 8	処理対象	0	作業リストに残す。
全体	不完全	4,000 のうち 2,500	最終フォルダーを受け入れない。

Python : -u オプションの正確な範囲

5. 重複を作成せずに無音または中断を調べる

カウンターが動かない場合、最後に判明したフェーズとその最後に完了した単位を特定します。プロセスが存在するか、エラーメッセージが現れたか、宛先が使用可能なままかどうかを確認します。モデルの起動が遅い場合とブロックされたループは同じ静止した画面を生み出す可能性があります。次の確認は文脈が決めます。

アプリケーションで意図的な停止を準備します。停止要求、安全な単位の終了、状態の保存、そして終了です。シグナルと中断はシステムに依存します。Python は SIGKILL を捕捉できず、Python のハンドラーは実行される前に長いネイティブ呼び出しの終了を待つことがあります。したがって、停止時の保存は定期的なバックアップに代わるものではありません。

接続を失った後は、まず既存のセッションと実行を見つけ直します。確定した停止の後は、何が完全で何が部分的かを判断します。トレーニングの場合、再開にはモデルと最適化の詳細な状態が必要です。専用のガイドでは、このケースを新しいプロセスで検証します。

6. 契約が許可するものだけを再開する

この例では、パーティション単位の再開は、各パーティションが独立しており、入力、コード、設定が同一のままであることを前提としています。検証済みの5つの結果を保持し、6つ目を完全に再計算してから、続く2つを処理することができます。これらの前提が成り立たない場合、このショートカットは正当化されません。

部分的なファイルに新しい行を単純に追加しないでください。重複を生じさせたり、2つの構成を混在させたりする恐れがあります。期待される識別子を使用して、完全、不完全、欠如を区別してください。以前の状態は説明の要素として保持し、新しい試行には別の保存先を用意してください。

大規模な処理に依存する前に、制御された中断で戦略を検証してください。判断基準は、進捗メッセージの同一性ではなく、契約に基づく有用な出力の等価性です。学習、外部作用を伴う計算、分散処理には、この独立パーティションの例とは別の保証が必要です。

7. 作業を終える前に結果を受け取り、取得する

まずリターンコードから始め、次に入力マニフェストと出力を照合します。この例では、8つのパーティションと予定された4000の識別子を、欠落も重複もなく期待します。形式、次元、関連する値を確認してください。ファイルを読むことは、それが正しい結果を含んでいる証明にはなりません。

受け入れた出力、承認された設定、バージョン、検証レポートを取得します。サイズを比較し、必要であれば元とコピー間のハッシュを比較します。同一のハッシュはバイトの転送確認には役立ちますが、モデルの品質やファイルの正当な出所を証明するものではありません。

最後に、保存先から結果を開き、それを使用するツールで確認します。計算へのアクセスが終了する前にこの段階を予定しておいてください。作業は、確認された結果が取得可能で解釈可能になったときに完了するのであり、最後のパーセンテージが100に達したときではありません。

プロセスが終了しても、まだ受け入れられた結果ではありません。