
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
Xenのスケジューラがぜんぜんわからん(全1記事)
リンクをコピー
記事をブックマーク
西村啓佑氏:西村です。「Xenのスケジューラがぜんぜんわからん」というタイトルで発表します。
出オチとして、タイトルどおりXenのスケジューラの話をしようと思いますが、そもそもXenってなんぞやというところから説明したいと思います。XenはVMMの一種で、例えば今回話すスケジューラやVM間通信機構といった機能を提供しています。
Xenのアーキテクチャの世界観の中で、VMMに対するVMはドメインと呼ばれていて、(スライドを示して)この図のように、1つのVMM上で複数のドメインを立ち上げることができます。
各ドメインはvCPUのバーチャルCPUという概念を持っていて、そのvCPUがpCPUに割り当てられることで初めて実行できます。VMMにおけるスケジューラは、vCPUをどうやってpCPUに割り当てるかを決定する機構です。
vCPUスケジューリングについて、もう少し検討していきます。vCPUスケジューリングの目的は計算資源の再配分なので、OSのスケジューラとまったく同じです。OSのスケジューリングの概念と比較すると、スケジューリングに関する単位がVMとProcessのように異なっていたり、実際に動作するアプリケーションに関するセマンティックな情報の粒度が異なっていたりします。つまり、一般的にはOSのほうがアプリケーションに詳しいといったことが起こり得ます。
いろいろありますが、基本的にOSから見た時のCPUの世界観は少し違っていて、常にCPUが使える環境とは限りません。従来の一般的なOSはCPUが常に使えることが前提でした。例えば、I/Oの発生時には、すぐCPUに割り込みが来る想定ですし、IPCの発生時にはすべてのコアが動作しているという想定ですが、このような過程は一切使えないのが仮想化の現状です。
すごく一般的なXenのスケジューラの話をしましたが、具体的なアルゴリズムについて話そうと思います。いろいろなスケジューラが提案されていて、実際にマージされていますが、今回のLTの対象はCreditスケジューラとCredit2スケジューラの2つです。
これらは一般的な汎用スケジューラで、リアルタイムスケジューラと言われるものではありません。元デフォルトスケジューラと、今のデフォルトスケジューラなので、Xenが一般的に使われているかはさておき、それぞれがかなり一般的に使われています。
Creditスケジューラについて説明します。Creditスケジューラは、Xenのバージョン3.0から4.11までがデフォルトでした。Xenは確か2003年にリリースされているはずなので、すごく長い期間デフォルトのスケジューラはCreditスケジューラでした。最新のXenのバージョンは4.15なので、つい最近までCreditスケジューラだったと言えます。
Creditスケジューラの特徴は、固定のタイムスライスとProportional Shareという概念です。Proportional share schedulingがCreditスケジューラの特徴で、デフォルトではタイムスライスは30ミリセコンドに固定されています。
また、Proportional Shareは、各VMあるいはvCPUがWeightで、優先度に比例した時間割り当てを受けるといったスケジューリングのストラテジーです。
名前の「Credit」はWeightに応じて配分された実行時間を指しています。Creditを使い果たした、つまりCreditがゼロ以下のVMあるいはvCPUはOVERと呼ばれ、残っているvCPUはUNDERと呼ばれます。CreditスケジューラはUNDERのvCPUをラウンドロビンで、順にスケジューリングしていく実装になっています。
ここで重要なのはCreditの値には依存しないということです。「ゼロより大きいか」が重要な要素となっています。
(スライドを示して)基本的なスケジューリングのアルゴリズムをフローチャートにまとめました。まず、すべてのvCPUに対してWeightに応じたCreditを加算します。すると、Creditが正のvCPUを1つ選んで実行します。そして、TS時間が経ったあとに実行時間分のCreditを消費します。Creditスケジューラは、これをグルグル繰り返します。
基本的なアルゴリズムはこうですが、実際それだけでは機能として不十分です。具体的にはI/Oが発生した時のLatency(I/O Latency)を削減する工夫がなされています。
具体的にはUNDERなVMへのEvent、つまりI/Oが発生したら、一時的にそのUNDERより強いBOOSTという最高優先度でvCPUを実行できます。(スライドを示して)この図にその概念を表しました。基本的にUNDERの間で、ラウンドロビンでスケジューリングが行われています。しかし、I/Oが発生して、BOOSTという優先度が割り当てられたvCPUは、UNDERでどんなvCPUが実行していようが優先して実行されるため、UNDERの中に割り込んで実行されることになります。
そのようなBOOSTの影響を定量化する実験を行いたいと思います。実験の目的として、あるVMが別のVMのI/O Latencyに与える影響についても同時に調査したいと思います。方法として、バックグラウンドで動作するVMで全体に負荷をかけつつ、別のVM間のpingのラウンドトリップタイムを計測します。
負荷は2つ用意します。1つ目は、iperfで別マシンと通信するネットワークバウンドなタスク。2つ目は、yesコマンドを用いたCPUバウンドなタスクです。
補足として、厳密にはVM間通信はI/Oではないのですが、VMから見ればほとんど同じ、かつ外乱が少ないというメリットがあるので、今回実験に採用しました。また、誤差を減らすためにpingのアプリケーションはLinux上でリアルタイムタスクとして作動させていて、DVFSは無効化しています。
(スライドを示して)結果がこちらです。この結果には、大きく3つの着眼点があります。まず、バックグラウンドがない時は、もちろん普通0.ホニャララミリセコンドくらいでpingができます。これはほとんどLatencyがないと言っていいと思います。一方、CPUバウンドのタスクが後ろで実行されている時も、BOOSTのお陰でLatencyが小さいと言えます。
さらにネットワークバウンドなバックグラウンドが動作している時も、meanの平均は小さいですがmaxは非常に悪化していることが観測されました。
なぜTail Latencyが悪化しているのか。一番の問題は、BOOSTしたvCPU間の調停がないという点にあります。つまり、同じマシンに複数のI/OバウンドなVMが存在する場合にこの問題が起こり得ます。
Tail Latencyの大幅な悪化が観測されているわけですが、BOOSTで割り込んだたくさんのvCPUがOVERにならない程度に長い時間の処理を続けていることが原因です。
1つ目の単純な解決策として、タイムスライスを短くする。つまり、デフォルトのタイムスライスが長すぎることが元凶の1つと言えます。
一方、短いタイムスライスは相対的にContext Switchのコストが上がってしまうので、ここにはトレードオフの関係があると言えますが、タイムスライスを短くするのが無難です。ただちょっと限界があります。
もう1つの解決策が、バックグラウンドのVMに対してCapを設定することです。スライドで説明します。Capは、vCPUの1pCPUに対する実行可能時間(割合)の上限をパーセントで表記したものです。例を見ればわかると思います。
まず4つのpCPUがあるマシン上で、3つvCPUがあるVMを実行します。その状態でCap値を200パーセントで動作させると、最大で全体の50パーセント、つまり2分の1のpCPUを使用できます。
これは、このCap値200を4つのpCPU×100(100パーセント)、つまり4×100を400で割った2分の1の50パーセントという値が、全体の4つのpCPUを50パーセント使用できるという意味を持ちます。
参考までに、Capがない場合は最大で全体の75パーセントです。つまり、3つのvCPUが同時に割り当てられると、最大で全体の75パーセントのCPUを利用することができるということになり、結果として使用量に上限が設けられています。
この是非について議論する時に「Work Conservation」という性質を考えるとすごく見通しがよくなります。Work Conservationは、一般にidleなCPUがある時に、ほかのCPUで実行待ちのタスク、つまりこの場合はvCPUがないという性質ですが、平たくいうと無駄がありません。
Cap値を設けるメリットとしてCPUの空きが保証されますが、Work Conservationが満たされないので無駄が発生してしまうというデメリットもあります。ここにもトレードオフがあります。
Capを設定することで、どれくらいLatencyが改善するのかを示したグラフです。先ほどの結果で示したデフォルトの設定が、この一番左のグラフです。タイムスライスを5ミリセカンドにしたり、バックグラウンドタスクに対するCapを設けたりすると、このようにTail Latencyが大幅に改善されることがわかります。以上がCreditスケジューラの説明です。
次に、Credit2スケジューラの話をします。Credit2スケジューラは、Xenのバージョン4.8からサポートが開始されて、4.12からデフォルト化されているはず。Wikipediaは2017年くらいで更新が止まっていて「Credit2 is not in use by default.」と書いてありますが、ほぼ間違いなく今がデフォルトです。
このCredit2スケジューラの特徴を一言でいうと、変動タイムスライスでProportional Shareなスケジューリングを実現しています。つまり、タイムスライスは実行時間に応じて計算される動的な値です。
Credit2スケジューラも、先ほどと同様にCreditというweightに応じて消費される実行時間、同じような概念を使いますが、先ほどとは異なり、UNDERやOVERというものは直接存在しません。Creditスケジューラは、よりLatencyを抑えたいシステム向きのスケジューラです。
(スライドを示して)基本的なアルゴリズムはこのようになっています。すべてのvCPUに同様のCreditを配布したのち、Credit最大のvCPUを、あるアルゴリズムに基づいた時間で実行します。そして、実行した分のCreditを消費してRunqをソートし、Credit最大のvCPUを実行するというループを、Creditが正のvCPUがなくなるまで実行します。
タイムスライスの決定アルゴリズムについてです。Runqに他の実行待ちのvCPUがある場合は、実行予定(Creditが最大のvCPU)のCreditの値から次に大きなCreditの値を引きます。そして、この値を時間に変換します。Runqに他の実行待ちCPUがない場合は、単純にこの2つ目をゼロとして扱います。この値は、次のCapやRate Limitという最短実行時間の概念を使って調整します。
この実行時間分のCreditの消費は、(スライドを示して)この枠で囲った式で消費Credit量が計算されます。基本原理としては、大きなWeightを持つほどCreditの減りが遅く、最大Weightを持つvCPUは1ナノセコンドで1Creditを消費します。
参考までに、Creditスケジューラは時間に応じた消費Credit量はすべてVM共通で、Creditの分配量のみが異なっていました。
さらに、Event(I/O)が発生した時のvCPUですが、Credit2はBOOSTという機能がない代わりに、Eventが発生したvCPUがRunqに突っ込まれてCredit順にソートされて、最大Creditを持つvCPUを実行するという、先ほどと同じアルゴリズムが走ります。この操作をtickleといいます。
このアルゴリズムの気持ちなのですが、基本的にこのI/OバウンドなVMは待ち時間が多いのでCreditが残っていないことが想定されます。つまりCreditが大きいです。
結果的にEvent発生VMがかなり優先されたスケジューリングが行われます。しかし、複数のスケジュールが同時にI/Oしている状況に対してもCreditという値で実際にその優先度が数値化されているので、先ほどのようなI/Oがたくさん起きる環境でも対応しやすいという特徴があります。
(スライドを示して)実際にCredit2スケジューラの性能を評価してみました。これを見ればわかりますが、Tailの悪化がかなり抑制されています。絶対時間で見ると、だいたいTailで2ミリセコンドくらいかかっていることがわかります。
これは、先ほどのパラメーター調整をしたCreditスケジューラの値ですね。単純にTailの比較をしてもあまり意味がありませんが、おおよその数値としてTailが5から10ミリセコンドくらいあるのに対して、ここは最大でも2ミリセコンドくらいになっています。しかも、特にパラメーターを設定せずデフォルトでこうなっているので、かなり優秀なスケジューラと言えるのではないかと思います。
以上が今回の内容です。スケジューラの説明をすると言いつつ、ロードバランシング、スケーラビリティ、Realtime系のスケジューラについてはまったく触れていないので、また機会があれば話そうと思います。
まとめに入ります。このLTではXenのスケジューラの主要な2つを説明しました。1つ目がCreditスケジューラで、固定タイムスライスでProportional Shareという特徴があります。I/O Latencyを削減するためにBOOSTという機能を使っていましたが、複数のBOOSTが起こる環境ではLatencyが大きくなるという問題がありました。
Credit2スケジューラは、変動タイムスライス、Proportional Shareなスケジューリングをして、Latencyの観点ではCreditスケジューラよりも性能が改善していることがわかりました。
発表は以上です。ありがとうございました。
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10