失敗したバッチジョブの診断
概要
このガイドでは、Rescaleプラットフォームでジョブをバッチ処理で実行しているユーザが遭遇する一般的なエラーの原因をいくつか紹介します。また、これらのエラーの診断方法についても説明します。また、これらのエラーを回避し、修正する方法についても説明します。
Job Statusページ
- Job Statusページの出力を確認する Status: 同じページよりお手続きを頂けたら幸いです。
ガントチャートでジョブ履歴を調べる
- コマンドは検証ステップ(Validating Input)を緑のチェックで適切に通過しているか? 検証は、製品、システム、または... その他
ジョブログにエラーメッセージが表示されていますか? Stopping job (User terminated)… セクション?
Resultsページ

process_output.log
ジョブが成功したかどうかにかかわらず、すべてのジョブに対して常に提案する最初のステップは、 process_output.log
ファイルを確認することです。このファイルには、実行中のソフトウェア解析手法からの標準出力が記録されています。また、潜在的なエラーメッセージも記録されます。
-
process_output.log
ファイルを見つけるには、Job Results ページに移動します。 同じページよりお手続きを頂けたら幸いです。 - 検索バーでクエリする。
- 通常
log
orprocess
で十分な検索可能です。
- 通常
- Actions欄のスクリーンアイコンで
process_output.log
ファイルを表示します。 の項目に表示されます。ファイルが大きすぎる場合は、まずファイルをダウンロードしてからテキストエディタで表示する必要がある場合があります
- このログファイルを注意深く見て、警告やエラーメッセージを探します。
- ほとんどの場合、エラーはここで確認することができます。 エラーはここで特定できます
- ほとんどの場合、エラーはここで確認することができます。 エラーはここで特定できます
Exit Codes
重要なのは、 process_output.log
ファイルの最後にある”exit code”です。解析メソッドがスムーズに実行され、エラーメッセージを出さずにきれいに終了した場合は、次のような結果が得られるはずです。
Exit with code 0
ジョブが code 0
で完了することがありますが、これは単にエラーが発生せずにプロセスが実行されたことを意味します。もちろん、これはジョブが意図したとおりに実行されたことを保証するものではありません。プログラムが明示的なシステムエラー (メモリ不足、コアダンプ、ディスク容量不足など) に遭遇した場合、プロセスは XNUMX 以外の終了コードを生成します。遭遇する可能性のある一般的な終了コード ジョブが意図したとおりに実行されたことを確認します。 プログラムで明示的なシステム エラーが発生した場合 (つまり、メモリ不足、 マルチコアプロセッサ内の個々の処理ユニット... その他
Exit Code | 意味 |
---|---|
1 | 一般的なエラーのキャッチオール |
2 | シェルビルトインの誤使用 |
126 | 呼び出されたコマンドが実行できない |
127 | コマンドが見つからない |
128 | 終了時の引数が無効 |
128 + n | 致命的なエラー信号 “n” |
130 | Ctrl-Cでスクリプトを終了させる |
137 | プロセスの明示的な終了やメモリ不足など、終了モードが未確定なもの |
255 * | 終了ステータス範囲外 |
もちろん、これらのエラーコードは最も有益なものではありませんが、デバッグの出発点となるものです。
デバッグの基本的な手順
故障のメカニズムは多岐にわたりますが、代表的な問題点とその診断・回避策を以下に示します。
入力ファイルの欠落
- すべての必要なファイルが、個別に、または圧縮(zip、tarballなど)された入力ファイルデッキでジョブに含まれていることを確認します。
ファイルパスが正しくない
- 圧縮された入力ファイルデッキが適切なディレクトリパスに展開されることを確認する。
- スクリプト、入力ファイル、その他のジョブ定義で相対ファイルパスを使用する。
- Rescaleは、ソフトウェア設定ページで指定されたソフトウェアコマンドを、圧縮ファイルを解凍するのと同じ作業ディレクトリで実行します。
- また、caseサブディレクトリ(例:
- zip/tar/etc コマンドが実行されるディレクトリのレベルの入力ファイル
- また、caseサブディレクトリ(例:
run01_configB
)を使用する場合は、解析ソフトウェアコマンドの前に、次のようにディレクトリを適切に変更することを確認してください:cd run01_configB && run_analysis
- Rescaleプラットフォームでは、このようなワークフローは推奨されません。
共通のファイルシステムにアクセスする必要がある複数ノードのジョブ
ヘッドプロセスがファイル入出力とワーカープロセスとの通信を処理するほとんどの解析手法では、Rescaleはユーザが指定した入力ファイルをデフォルトで ~/work
に配置します。しかし、一部の手法では、ワーカープロセスがノード上で起動し、共有ファイルシステムにもアクセスできることが必要です。
- Rescaleプラットフォームでは、
~/work/shared
ディレクトリがジョブ内の全ての計算ノードにNFSマウントされます。- Rescaleはこれらの分析手法のほとんどを識別し、デフォルトで
~/work/shared
ディレクトリにジョブを開始します。 - しかし、ランタイムのカスタマイズやオプションにより、ノード上で動作するワーカープロセスが、入力ファイルへのアクセス、ランタイムライブラリのロード、出力ファイルの書き込みを必要とする場合があります。
- Rescaleはこれらの分析手法のほとんどを識別し、デフォルトで
- また, Software SettingsページのCommandの前に、moveとchange directoryのコマンドがあること。 や
入力ファイルの読み込みエラー
- 入力ファイルが解析ソフトの期待通りに正しく構築されていることを確認する。
- ソフトウェア設定」ページで、適切なソフトウェアのバージョンが選択されていることを確認します。
- テキスト入力ファイルが適切な形式であることを確認する
- バッチコンピュートノードは一般にLinuxマシンです。テキストエディタの種類によっては、行末・ファイル末尾の文字のエンコードが異なる場合があります。
- Windowsのテキストエディタでは、Linuxが使用しない^M改行文字を含むファイルが作成されることがよくあります。
^M
Linux が使用しない改行文字- VI/VIMなどのテキストエディタでこれを置き換えるには、以下のコマンドでこれらの文字を置き換えることができます
:%s/^M$//
- 注:
^M
はctrl-Vとctrl-Mで入力します。ctrl-V
やctrl-M
- VI/VIMなどのテキストエディタでこれを置き換えるには、以下のコマンドでこれらの文字を置き換えることができます
解析方法から他のログファイルを調べる
-
Rescale Platformは標準出力メッセージを
process_output.log
に出力しますが、一部の分析手法では重要な情報を他のログファイルに出力します。 -
これらの出力ファイルの拡張子は通常”log”,”out”,”live”,”dat”ですが、解析方法によって異なる場合があります。ソフトウェアベンダーのドキュメントを参照してください。
これらのログファイルは通常ASCIIテキストファイルですので、右側の列のファイル名の隣にある小さな画面のアイコンを使って表示することができます。
-
process_output.log
ファイルと同様に、サイズが大きすぎる場合は、ローカルのワークステーションにダウンロードし、テキストエディタで表示してください ワークステーションは、プロ向けに設計された強力なコンピュータ システムです。 その他
-
ライブラリファイルの欠落
- ジョブで使用されるカスタム・ライブラリ・ファイルに対して、プロセスが適切なアクセス権とパス定義を持っていることを確認してください。
- Rescaleサポートは、お客様のアプリケーションのために追加のライブラリをインストールする必要がある場合があります。
システムリソースが不足している
- シミュレーション・プロセスに十分な物理メモリとストレージがあることを確認する シミュレーションは実験であり、シナリオをテストし、作成することです... その他
- 一部のコードは解析に応じてランタイム中にメモリ・フットプリント・サイズを変更するため、スタートアップ時に十分なメモリを確保できない場合があります 。
- 一部のコードは大量のスクラッチデータファイルを生成し、最終出力ファイルよりもストレージ・フットプリントが大きくなる場合があります。
- Job Status ページの下部にある Cluster Status で空きメモリとディスク容量のモニターを確認 Status:
- メッシュ/シミュレーションのサイズを小さくして、ジョブが正常に動作するか確認します
- コア/ノード数を増やして実行 物理メモリやストレージがより多い特殊コアタイプを選択します。
適切なライセンスアクセス
- ソフトウェア設定のページで、ライセンス設定が正しく定義されていることを確認します。一般的に、これらはport@hostnameの形式になっています。
- process_output.log からわかるように、ライセンスファイルの機能をチェックアウトしていることを確認します。
- 実行しようとしているコマンドに、機能を確認するための正しいオプションが使用されているかどうかを確認します。
- 実行しようとしているコマンドに、機能を確認するための正しいオプションが使用されているかどうかを確認します。
- ライセンスサーバーの責任者である場合 サーバーは、他のサーバーにサービスを提供するコンピューター プログラムです。 その他:
- ライセンスが失効していないことを確認する
- ライセンスサーバーが起動していること、ネットワークにアクセスできることを確認します。
- 詳しくは、 SSHトンネル や IPフォワーディング のガイドをご参照ください。
ワークフローのデバッグ
- 本番運用を始める前に、ワークフローを確認するための小さなテストケースを立ち上げてください。
- プリポストステップが解析オプション > コマンドに適切に統合されていることを確認します。 >
- テストジョブを対話的に実行する
- 既存のコマンドを
sleep 3600
ssh
計算ノードが起動したら、sshでログインする。 従来のコンピューティングでは、ノードはネットワーク上のオブジェクトです。 ... その他- 解析方法に適したディレクトリ
~/work
or~/work/shared
) - インタラクティブにジョブを起動しようとする
- 成功した結果をもたらすコマンドをすべて記録する
- コマンドを適宜修正する
- また, コマンド入力ウィンドウでは、改行, ; ,&マークによるコマンドの区切りが可能です。
;
or&&
- 注:&で区切られたコマンドは、前のコマンドがコード XNUMX で終了した場合のみ実行され、;に続くコマンドは、常に前のコマンドの後に実行されます。
&&
code 0
;
- また, コマンド入力ウィンドウでは、改行, ; ,&マークによるコマンドの区切りが可能です。
- 既存のコマンドを
これらの一般的なデバッグ手順でも問題が解決されない場合は、Rescaleサポートに連絡し、ジョブを共有してください。 .