同じ20台に仕事を詰めました。容量の使用率はどの詰め方でも97%以上です。
ところが載った仕事の件数は60件と258件で、4倍以上の開きがありました。
使用率はほぼ埋まっていることしか示しません。何件さばけたかは、別に数える必要があります。
GPU使用率最適化で目標にされがちなのが容量の使用率です。これが指標として働くかを、実際に走らせて測りました。
容量80の台を20枚、仕事を600件用意しました。要求の合計は8474で、隙間なく詰めても106台ぶんです。20台では全部は載りません。
1台の容量 80・20台。仕事 600件の要求の合計は 8474 全部を隙間なく詰められたとしても 106台ぶんになる 詰め方 載った仕事 載らなかった 使えた容量 空いたまま 来た順に詰める 127件 473件 99.2% 13 大きい順に詰める 60件 540件 99.9% 1 小さい順に詰める 258件 342件 97.3% 44
使えた容量はどれも97%以上です。数字だけ並べれば、どの詰め方も同じくらい良く見えます。
載った件数はまったく違います。大きい順に詰めると60件、小さい順なら258件です。
使用率は容量が埋まっているかだけを見ています。1件で30を使う仕事でも、3を使う仕事でも、埋まった量は同じ扱いです。
最も使用率が高い99.9%の行が、最も件数が少ない行です。順位が逆になっています。
載らなかった仕事は消えるわけではありません。出典も待ち行列に入った要求は、メモリを消費し、応答を遅らせると述べています。
使用率はほぼ横並びでも、さばけた件数は4倍違う。
Queued requests consume memory and increase latency.原文Google SRE Book「Addressing Cascading Failures」 この内容の有効期限2027-02-18
同じ処理能力でも、1台にまとめるか分けるかで結果が変わります。待ちだけ見ると判断を誤ります。
GPU使用率最適化のもう1つの論点が、1台にまとめるか、小さく分けるかです。同じ処理能力で比べました。
台数を増やすほど1件あたりは遅くなります。処理能力の合計はどの構成でも同じで、使用率も8割にそろえてあります。
構成 1件あたり 実測の使用率 平均の待ち 95%点の待ち 合計の所要 1台（速い） 2.5分 78.9% 9.3分 32.8分 11.8分 2台（中くらい） 5.0分 78.9% 8.2分 31.0分 13.2分 4台（遅い） 10.0分 78.9% 6.8分 28.9分 16.8分 8台（もっと遅い） 20.0分 78.9% 5.2分 26.0分 25.2分
待ちの列を見ると、分けるほど短くなります。1台の9.3分に対し、8台なら5.2分です。
ところが合計の所要は逆です。1台の11.8分に対し、8台では25.2分と倍以上になります。
待ちが短くても、処理そのものが遅ければ意味がありません。利用者にとっては待ちと処理の合計です。
出典も同じ見方を行列がいっぱいなら、1件の処理に1.1秒かかることになり、その大半は行列で費やされるという例で示しています。利用者が見るのは合計です。
分ける理由は別にあります。1件で1台を占有させないことや、種類ごとに枠を確保することです。速さのためではありません。
待ちだけ見ると分けたほうが速いが、合計では逆になる。
If the queue is full, then a request will take 1.1 seconds to handle, most of which time is spent on the queue.原文Google SRE Book「Addressing Cascading Failures」 この内容の有効期限2027-02-18
使用率は結果です。目標に置くと、詰め方も分け方も間違った方向へ動きます。
GPU使用率最適化という言い方に反しますが、使用率そのものを目標にしてはいけません。この2つの計測がその理由です。
1番目を目標にすれば、小さい順に詰める案が選ばれます。使用率を目標にすると、大きい順が選ばれます。
3番目も要ります。載らなかった仕事が溜まると、投入から完了までの時間が伸び続けます。
出典も行列の扱いを通常、行列がいっぱいであれば、サーバは新しい要求を拒むと書いています。溜め続けない形にしておきます。
行列が長いほど良いように見えるのは、使用率が上がるからです。使用率のために行列を溜めるのは順序が逆です。
件数と合計の所要は、記録していないと出せません。投入した時刻と完了した時刻を残します。
待ちの伸び方そのものはジョブキューの記事で測っています。使用率を上げるほど待ちが跳ねます。
使用率を目標に置くと、件数が減る方向へ最適化される。
詰め込みはメモリの大きさだけを見た単純な形です。実際には計算の取り合いも起きるので、同じ台に載せた仕事は互いに遅くなります。待ち行列のほうも、到着と処理を指数分布で置いています。ここで見せているのは、使用率という1つの数字では詰め方も分け方も評価できないという関係です。
Usually, if the queue is full, the server will reject new requests.原文Google SRE Book「Addressing Cascading Failures」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る