GPUクラスタのスケジューリング

GPUクラスタでは、多数のジョブが限られたGPUを取り合います。この研究では、短いジョブを先に実行するサイズ優先方式が、平均待ち時間を短くできる条件と、一部のジョブを長く待たせる条件を調べています。

問い

ジョブサイズ、推定誤差、再開コスト、クラスタ容量の組み合わせが変わると、サイズ優先方式と予約型方式の優劣はどのように変わるのか。とくに、良い平均値の裏で一部のジョブが飢餓していないかを検査します。

これまでの進展

合成シミュレーションで、クラスタ全体を必要とするジョブが一つあるだけで、サイズ優先と貪欲な詰め込みの組み合わせが飢餓を起こしうることを切り分けました。公開トレース2本を調べると、実運用中の11プールにはクラスタ全体を占めるジョブは観測されませんでした。

その後の7本は、自分の出した数値を自分で壊す作業が中心になりました。駆動変数はプール規模ではなく同時実行ジョブ数でした（EP-0006）。看板だった「supportがクラスタ全体を含むと飢餓する」は、背景の粒度だけで消えました（EP-0008）。代表成果だった相図の軸は18倍交絡していました（EP-0009）。「2つの数で決まる」は撤回しました（EP-0010）。

そして判定器そのものが壊れていました（EP-0011）。境界の判定に使っていた flow balance は、応答時間を観測窓で割った打ち切り比であり、発散を検出できません。平均待ち時間が3.9倍に伸びるあいだ、判定器は0.562から0.574にしか動きませんでした。運用数値はいったん全部停止しました。

置き換えた統計量 α（平均待ち時間の観測窓に対する弾性）は、安定な条件で0を、線形発散で1を読み、観測窓を8倍にしても境界を0.02しか動かしません（EP-0012）。運用数値は頻度の列を足した形で戻っています。

現在の公開結論

現在見る量は、最大ジョブがプール容量に占める割合 × 同時実行ジョブ数 × 大ジョブの頻度の3つです。256サーバ、rho 0.85の合成モデルでは、同時10本なら比率0.92（頻度0.002）／0.72（頻度0.02）、同時30本なら0.73／0.66が目安です。頻度を落とすと、希少な大ジョブには保守側、頻繁な大ジョブには危険側の数字になります。

自分のクラスタでは完了率ではなく、平均待ち時間が観測窓とともに伸びるかを見ます。窓を2倍にして平均が1.4倍以上になるなら、そのクラスは発散しています。実クラスタについて言える範囲は極端に狭く、Phillyの11仮想クラスタ中10個には容量の4分の1を超えるジョブがなく、唯一の例外でも容量の半分超は19,100本中1本でした。

証拠の境界： 実際の到着列を使ったスケジューラ比較ではなく、外部からの独立再現もまだありません。

現在のResearch Note（EP-0013）を読む →

GPUクラスタのスケジューリング

問い

これまでの進展

現在の公開結論

公開中のResearch Note