問題タブ [lsf]

私たちのクラスターでは、40 を超えるノードまたは 640 コア (を含む) を要求するジョブを送信すると、$LSB_HOSTS が空になり、ジョブが停止します。この変数を使用して、次のように mpirun コマンド ラインで使用する nodelist ファイルを生成します。

ここにヒントはありますか？

このスクリプトに問題があることがわかりますか?

ありがとう、

エリック。

途中で計算を行ったところ、ランタイム制限の 50:00 では不十分であることがわかりました。そこで、$bstop 1234 を使用してジョブ 1234 を停止し、古いランタイムを -W 50:00 から -W 100:00 に変更しようとしました。そのためのコマンドを提案できますか?

私は試した

によると

http://www.cisl.ucar.edu/docs/LSF/7.0.3/command_reference/bmod.cmdref.htmlから

構文がよくわかりません。-Wn は Wall time new という意味ですか

助けてくれて本当にありがとうございます！

Python で X 回完了する単一のタスクがあり、LSF を使用してそれを高速化します。別々に並行して実行できる複数の Python スクリプトを含むジョブを送信するのと、マルチプロセッサ モジュールを利用する 1 つの Python スクリプトを送信するのとでは、どちらが適していますか?

私の問題は、LSF が Python コードを複数のプロセスに分割する方法を知っているとは思えないことです (LSF がこれをどのように行うのかはわかりません)。ただし、非効率的で整理されていないように見えるため、いくつかの Python スクリプトが飛び交うのも望ましくありません。

当面のタスクには、6 つの非常に大きな ASCII ファイルを解析し、後で使用するために出力を Python dict に保存することが含まれます。6 つのファイルを並行して解析したいと考えています (それぞれに約 3 分かかります)。LSF では、Python が「ねえ、スクリプトは 1 つですが、これらの 6 つのプロセスに分割するつもりです」などと言うことができますか? LSFは Python にそれを伝える必要がありますか、それともその方法を既に知っていますか?

さらに情報が必要な場合はお知らせください。背景の「ちょうどいい」と「多すぎる」のバランスをとるのに苦労しています。

ジョブ スケジューラを使用してプログラムを実行すると、スケジューラはジョブに(ユーザーが指定した) n 個のプロセッサ コアを割り当てます。OpenMP を使用するプログラムが実行されると、OpenMP は一般にOMP_NUM_THREADSスレッドを使用します。簡単にするために、それぞれが異なるプロセッサ コアにマップされているとします。

OpenMP は、スケジューラによってどのコアがプログラム/ジョブに割り当てられたかについて何も知りません (私の知る限り)。また、OS は、OpenMP ではなく、実際に OpenMP スレッドをコアにマップするものです。

私の質問は、OpenMP スレッドが、ジョブ スケジューラによってジョブに割り当てられたコアにのみマップされるように、舞台裏で何が起こっているのかということです。

私の質問は一般的なものにしたいのですが、プロセスがジョブ スケジューラ間で本当に異なる場合は、LSF 固有の回答が最適です。

次の方法で、perl スクリプトから bsub コマンドを実行しようとしています。

しかし、 の二重引用符のために perl が混乱していると思います"testid::1"。これを実装する適切な方法は何ですか?

submit_time に基づいて bjob​​s 出力をソートする方法はありますか? それとも他のフィールドによると？

JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME

私のプログラムでは MPI+pthreads を使用しています。n-1 個の MPI プロセスは純粋な MPI コードですが、pthreads を使用する MPI プロセスは 1 つだけです。最後のプロセスには、2 つのスレッド (メイン スレッドと pthread ) しか含まれていません。このプログラムを実行したい HPC クラスターは、それぞれが 12 個のコアを持つ計算ノードで構成されているとします。ハードウェアを最大限に活用するには、バッチ スクリプトをどのように記述すればよいですか?

以下は、私が書いたバッチスクリプトです。最後の MPI プロセスには 2 つのスレッドがあり、他のプロセスにもそれぞれ 2 つのスレッドがあると想定する必要があるため、 export OMP_NUM_THREADS=2 を使用します。

次に、ノードごとに 6 つの MPI プロセスを割り当てるので、1 つの MPI プロセスを除くすべての MPI プロセスに 1 つのスレッドがあるにもかかわらず、各ノードは 6xOMP_NUM_THREADS = 12(=各ノードのコア数) のスレッドを実行できます。

このためのより良いスクリプトを作成するにはどうすればよいですか?

現在、Platform Computing "Platform Process Manager" (Flow Manager) バージョン 8.1 によって作成されたlsb.eventsログ ファイルの内容を解読しようとしています。

ドキュメントのさまざまなソースから、jStatus 変数に関する次の説明が表示されます。

• 4=実行
• 32=JOB_STAT_EXIT
• 64=JOB_STAT_DONE

ただし、JOB_STATUS エントリには、2 と 192 の jStatus 値もあります。 これらの値は何を表していますか?

この実装がバンドルされているため、SAS にタグ付けします。補足として、lsb.events ファイルの実際のフィールドが、前述のドキュメントに従って表示されるはずのフィールドと一致しない場合があることに気付きました..

私の問題があまり具体的でないことを願っています...

別のコマンドにパイプされたコマンドの終了コードを返す方法については、多くの質問と回答がありますが、私の場合は少し異なります...

出力をシンタックスカラーリングスクリプトにパイプする汎用コマンドがあります。このコマンドは、LSF の bsub を介して実行されます。このようなもの：

bsub <switches> "command | colorize"

コマンドがゼロ以外の終了値を返すとします。colorize コマンドにより、bsub はゼロの終了値を返しています。

配管しないと--

bsub <switches> "command"

終了値は、コマンドからのゼロ以外の正しい値です。

パイプでゼロ以外の値を取得する方法はありますか?

完全な開示のために、この bsub は実際には perl の system() 呼び出しを介して呼び出されています。bsub がゼロ以外を返す限り、システム コールはゼロ以外を返す必要があり、すべて問題ありません。

$PIPESTATUS 経由でパイプされたコマンドから終了コードを取得する方法を調べましたが、1) シェルではなく perl から実行しており、2) bsub かどうかわからないため、この場合は機能しないと思います。それを返します。

job1 が LSF の変数名を使用して動的に job2 を待機するという問題があります。これが私のコードです。