失敗したバッチジョブの診断

概要

このガイドでは、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 or process で十分な検索可能です。
  • Actions欄のスクリーンアイコンで process_output.log ファイルを表示します。   の項目に表示されます。
    • ログビューアファイルが大きすぎる場合は、まずファイルをダウンロードしてからテキストエディタで表示する必要がある場合があります
  • このログファイルを注意深く見て、警告やエラーメッセージを探します。
    • ほとんどの場合、エラーはここで確認することができます。 エラーはここで特定できます プロセス出力.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”
130Ctrl-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 ディレクトリにジョブを開始します。
    • しかし、ランタイムのカスタマイズやオプションにより、ノード上で動作するワーカープロセスが、入力ファイルへのアクセス、ランタイムライブラリのロード、出力ファイルの書き込みを必要とする場合があります。
  • また, Software SettingsページのCommandの前に、moveとchange directoryのコマンドがあること。 や
mv * shared
cd shared
<run_analysis>

入力ファイルの読み込みエラー

  • 入力ファイルが解析ソフトの期待通りに正しく構築されていることを確認する。
  • ソフトウェア設定」ページで、適切なソフトウェアのバージョンが選択されていることを確認します。
  • テキスト入力ファイルが適切な形式であることを確認する
    • バッチコンピュートノードは一般にLinuxマシンです。テキストエディタの種類によっては、行末・ファイル末尾の文字のエンコードが異なる場合があります。
    • Windowsのテキストエディタでは、Linuxが使用しない^M改行文字を含むファイルが作成されることがよくあります。 ^M Linux が使用しない改行文字
      • VI/VIMなどのテキストエディタでこれを置き換えるには、以下のコマンドでこれらの文字を置き換えることができます :%s/^M$//
      • 注： ^M はctrl-Vとctrl-Mで入力します。 ctrl-V や ctrl-M

解析方法から他のログファイルを調べる

  • 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サポートに連絡し、ジョブを共有してください。 .