を使用して、LSF で最も使用率の低いマシンにジョブを送信しようとしていました。
bsub -R "order[ut]"
期待どおりに機能しますが、すべてのジョブ (連続して送信されたもの) が同じホスト (最も使用率の低いホスト) で終了するため、マシンに大きな負荷がかかり、最終的にジョブのパフォーマンスが低下します。最も使用率の低いマシンに連続して送信されたジョブを分散する方法はありますか? または、マシンで使用されているスロットの数を把握する方法は?
1 に答える
1
あなたの説明に基づいて断言するのは難しいですが、私の推測では、あなたが見ているのは、LSF のスケジューリング サイクルの性質によって引き起こされた効果であると思います。以下は、注文文字列に関する LSF ドキュメントからの抜粋です。
http://www-01.ibm.com/support/knowledgecenter/SSETD4_9.1.3/lsf_admin/order_string.dita
ホスト h1 がクラスター内に存在し、110 ユニットの消費可能なリソース「res」を持ち、ホスト h2 がこのリソースを 20 個持っているとします (たとえば、「res」は新しいバッチ組み込みリソース スロットである可能性があります)。これら 2 つのジョブが保留中であり、同じスケジューリング サイクルでスケジューラによって考慮され、job1 が最初にスケジュールされると仮定します。
Job1: bsub -R "maxmem>1000" -R "order[res] rusage[res=100]" -q q1 sleep 10000
Job2: bsub -R "mem<1000" -R "order[res] rusage[res=10]" -q q2 sleep 10000
スケジューリング サイクルの早い段階で、クラスター内のすべてのホスト、または要求されたホスト リスト (-m) にリストされているホストのいずれかを取得し、リソース要件文字列の順序セクションで並べ替えることによって、候補ホスト リストが作成されます。ジョブの順序付けされた候補ホスト リストは、順序付け後に次のようになるとします。
ジョブ1:{h1, h7, h4, h10}
ジョブ2:{h1, h2}
これは、h1 が、両方のジョブの候補ホスト リストの最高の「解像度」ホストになることを意味します。後のスケジューリングでのみ、各ジョブに 1 つずつ、実行するホストとこれらのホストからのリソースが割り当てられます。
Job1 がホスト h1 に着陸するようにスケジュールされているとします。したがって、100 の「res」が割り当てられます。次に、Job2 が考慮されると、ホスト h1 に着陸するようにスケジュールされる可能性があります。これは、その候補ホスト リストがまだ同じように見えるためです。つまり、この同じスケジューリング サイクル内で Job1 に割り当てられた 100 の「res」は考慮されません。
要するに、一度に多数のジョブを送信し、候補ホストをリソース 'ut' で並べ替えるように要求していますが、1 つのスケジューリング サイクル内では、ジョブがホストにスケジュールされているため、ホストの並べ替えは行われません。それぞれが別々のサイクルでスケジュールされるようにジョブの送信の間隔をあけると、ジョブが異なるホストにディスパッチされることがわかります。
現在、ドキュメントのそのページには、各ジョブのサイクル内で LSF に強制的にホストの順序を変更させる方法についても説明されています。注文文字列で：
bsub -R "order[!ut]"
ただし、クラスターに多くのジョブがある場合、スケジューリングが大幅に遅くなる可能性があることに注意してください。
さらに、これがリソース 'ut' で機能するかどうかは 100% 確信が持てません (ジョブがスケジュールされても値が変わらないため)。私が信じている最近のバージョン：
bsub -R "order[!slots]"
編集
私の同僚の何人かは、「!」記号を使用せずにこの動作を回避する別の方法を思いつきました。order文字列の表記であり、JOB_ACCEPT_INTERVALパラメーターlsb.paramsを 1 に設定することです。
これにより、特定のホストに 1 分あたり 1 つのジョブがディスパッチされるという制限が適用されます。これにより、utリソースが更新され、ホスト間でワークロードのバランスを取る時間が与えられます。
于 2015-03-25T02:17:39.053 に答える