盗む：仮想マシンからプロセッサ時間を盗む

こんにちは 私は、仮想マシン内でのスチールの出現のメカニズムと、彼の研究中に発見できたいくつかの明白でないアーティファクトについて、わかりやすい言葉で伝えたいと思います。 プラットフォームはKVMで実行されます。



CPUスチール時間は、仮想マシンが実行のためにプロセッサリソースを受け取らない時間です。 この時間は、仮想化環境のゲストオペレーティングシステムでのみ考慮されます。 これらの非常に割り当てられたリソースが人生のように行く理由は非常にあいまいです。 しかし、私たちはそれを理解し、一連の実験全体を設定することにしました。 盗みに関するすべてを知っているわけではありませんが、今すぐ何か面白いことをお話しします。

1.スチールとは

したがって、スチールは、仮想マシン内のプロセスのプロセッサー時間の不足を示すメトリックです。 KVMカーネルパッチで説明されているように 、スチールは、ハイパーバイザーがホストOS上で他のプロセスを実行する時間ですが、実行のために仮想マシンプロセスをキューに入れています。 つまり、スチールは、プロセスを実行する準備ができた時間と、プロセッサにプロセス時間を割り当てる時間との差と見なされます。



仮想マシンのカーネルは、ハイパーバイザーからスチールメトリックを受け取ります。 同時に、ハイパーバイザーは、それが実行する他のプロセスを正確に指定せず、単に「忙しい間、時間を与えることができません」 KVMでは、 パッチにスチールカウントのサポートが追加されました。 ここには2つの重要なポイントがあります。

• 仮想マシンは、ハイパーバイザーからのスチールについて学習します。 つまり、損失の観点から、仮想マシン自体のプロセスの場合、これはさまざまな歪みの影響を受ける可能性がある間接的な測定値です。
  
  
• ハイパーバイザーは、他のユーザーと何をしているかについての情報を仮想マシンと共有しません-主なことは、時間に専念しないことです。 このため、仮想マシン自体はスチールインデックスの歪みを検出できません。これは、競合するプロセスの性質によって推定される可能性があります。
  
  

2.盗みに影響するもの

2.1。 計算スチール

実際、スチールは通常のCPU使用時間とほぼ同じと見なされます。 廃棄がどのように考慮されるかについての情報はあまりありません。 おそらく大多数がこの質問を明白だと考えているからでしょう。 しかし、ここにも落とし穴があります。 このプロセスに慣れるために、Brendann Greggの記事を読むことができます。使用率の計算における多くのニュアンスと、次の理由でこの計算が誤っている状況について学びます。

• クロックサイクルがスキップされるプロセッサの過熱。
  
  
• ターボブーストのオン/オフを切り替えます。その結果、プロセッサのクロック周波数が変わります。
  
  
• SpeedStepなどのプロセッサの省エネ技術を使用する場合に発生する時間の長さの期間の変化。
  
  
• 平均の計算の問題：80％で1分以内の使用率の見積もりは、100％の短期バーストを隠すことができます。
  
  
• 循環ロック（スピンロック）により、プロセッサは破棄されますが、ユーザープロセスは実行の進行状況を確認できません。 その結果、プロセスがプロセッサ時間を物理的に消費することはありませんが、プロセスによる推定プロセッサ使用率は100％になります。
  
  

盗みの同様の計算を説明する記事は見つかりませんでした（ご存じの場合は、コメントを共有してください）。 しかし、発生源から判断すると、計算メカニズムは廃棄の場合と同じです。 KVMプロセス（仮想マシンプロセス）のために、カーネルに直接別のカウンターが追加されるだけで、KVMプロセスがプロセッサー時間のスタンバイ状態にある時間の長さをカウントします。 カウンターは、その仕様からプロセッサに関する情報を取得し、すべてのティックが仮想プロセスによって使用されているかどうかを確認します。 それがすべてであれば、プロセッサは仮想マシンプロセスでのみ使用されていたと考えられます。 それ以外の場合、プロセッサが何か他のことを行っていることを通知し、スチールが表示されます。



スチールカウントプロセスには、通常のリサイクルカウントと同じ問題があります。 そのような問題が頻繁に現れると言うわけではありませんが、それらは落胆するように見えます。

2.2。 KVMでの仮想化の種類

一般的に、仮想化には3つのタイプがあり、それらはすべてKVMでサポートされています。 仮想化のタイプによって、スチールが発生するメカニズムが決まる場合があります。



放送 この場合、ハイパーバイザーの物理デバイスを使用した仮想マシンのオペレーティングシステムの操作は、ほぼ次のように行われます。

1. ゲストオペレーティングシステムは、ゲストデバイスにコマンドを送信します。
   
   
2. ゲストデバイスドライバーはコマンドを受け入れ、デバイスのBIOSに対する要求を生成し、それをハイパーバイザーに送信します。
   
   
3. ハイパーバイザープロセスは、コマンドを物理デバイスのコマンドに変換し、とりわけ安全性を高めます。
   
   
4. 物理デバイスドライバーは、変更されたコマンドを受け入れ、物理デバイス自体に送信します。
   
   
5. コマンドの実行結果は同じパスに沿って戻ります。
   
   

翻訳の利点は、任意のデバイスをエミュレートできることと、オペレーティングシステムのカーネルを特別に準備する必要がないことです。 しかし、まずはスピードでそれを払わなければなりません。



ハードウェア仮想化 。 この場合、ハードウェアレベルのデバイスは、オペレーティングシステムからのコマンドを理解します。 これが最速かつ最良の方法です。 ただし、残念ながら、すべての物理デバイス、ハイパーバイザー、ゲストOSでサポートされているわけではありません。 現在、ハードウェア仮想化をサポートする主なデバイスはプロセッサです。



準仮想化（準仮想化） 。 KVMでのデバイス仮想化の最も一般的なバージョンであり、一般にゲストオペレーティングシステムで最も一般的な仮想化モードです。 その特徴は、ハイパーバイザーの一部のサブシステム（ネットワークまたはディスクスタックなど）で動作すること、または低レベルのコマンドを変換せずにハイパーバイザーAPIを使用してメモリページの割り当てが発生することです。 この仮想化方法の欠点は、ゲストAPIを使用してハイパーバイザーと対話できるようにゲストオペレーティングシステムのカーネルを変更する必要があることです。 しかし、通常、これはゲストオペレーティングシステムに特別なドライバーをインストールすることで解決されます。 KVMでは、このAPIはvirtio APIと呼ばれます 。



準仮想化では、変換と比較して、仮想マシンからホストハイパーバイザープロセスにコマンドを直接送信することにより、物理デバイスへのパスが大幅に削減されます。 これにより、仮想マシン内のすべての命令の実行を高速化できます。 KVMでは、virtio APIがこれを担当し、ネットワークやディスクアダプターなどの特定のデバイスでのみ機能します。 そのため、virtioドライバーは仮想マシン内に配置されます。



この高速化の裏側は、仮想マシン内で実行されるすべてのプロセスが仮想マシン内に残るわけではないということです。 これにより、盗み出される可能性のある特殊効果が作成されます。 仮想I / OのAPI：virtioを使用して、この問題の詳細な調査を開始することをお勧めします 。

2.3。 公正なスケジューリング

実際、ハイパーバイザーでの仮想化は、Linuxカーネルでのスケジューリング（プロセス間のリソースの割り当て）の法則に従う通常のプロセスであるため、詳細に検討します。



Linuxは、いわゆるCFS、Completely Fair Schedulerを使用します。これは、カーネル2.6.23からデフォルトのディスパッチャになりました。 このアルゴリズムを理解するには、Linux Kernel Architectureまたはソースを読むことができます。 CFSの本質は、プロセスの実行期間に応じて、プロセス間のプロセッサー時間を分散させることです。 プロセスに必要なプロセッサ時間が長いほど、受信する時間が短くなります。 これにより、すべてのプロセスの「正直な」実行が保証されます。そのため、1つのプロセスがすべてのプロセッサを常に占有することはなく、他のプロセスも実行できます。



時々、このパラダイムは興味深いアーティファクトにつながります。 長年のLinuxユーザーはおそらく、コンパイラーのような要求の厳しいアプリケーションを実行しながら、デスクトップ上の通常のテキストエディターのフェードを覚えているでしょう。 これは、デスクトップアプリケーションのリソースを消費しないタスクが、コンパイラなどのリソースを積極的に消費するタスクと競合するために発生しました。 CFSはこれを不正とみなします。したがって、定期的にテキストエディターを停止し、プロセッサーがコンパイラータスクを処理できるようにします。 これはsched_autogroupメカニズムを使用して修正されましたが、タスク間のCPU時間の分散に関する他の多くの機能が残っていました。 実際、この話はCFSの悪さに関するものではなく、プロセッサー時間の「正直な」分布が最も些細な作業ではないという事実に注意を向けようとする試みです。



シェダーのもう1つの重要なポイントはプリエンプションです。 これは、プロセッサからスニッカープロセスを駆動し、他のユーザーが動作できるようにするために必要です。 追放プロセスは、コンテキストスイッチング、プロセッサコンテキストスイッチングと呼ばれます。 同時に、タスクのコンテキスト全体（スタックの状態、レジスタなど）が保存されます。その後、プロセスは待機し、別のプロセスが実行されます。 これはOSにとって高価な操作であり、めったに使用されませんが、実際には何も問題はありません。 コンテキストの頻繁な切り替えは、OSの問題を示している場合がありますが、通常は継続的に発生し、特に何も示していません。



1つの事実を説明するには、このような長いストーリーが必要です。正直なLinuxシェデラーが消費しようとするプロセッサーリソースが多くなればなるほど、他のプロセスも動作できるように速く停止します。 これが正しいかどうかは複雑な問題であり、負荷が異なると異なる方法で解決されます。 Windowsでは、最近まで、シェドラーはデスクトップアプリケーションの優先処理に重点を置いていました。これは、バックグラウンドプロセスがハングする可能性があるためです。 Sun Solarisには5つの異なるクラスのシェダーがありました。 仮想化を開始したときに、前の5つはSolaris Zone仮想化との連携が不十分だったため、6番目のFair share schedulerを追加しました。 Solaris Internals：Solaris 10 and OpenSolaris Kernel ArchitectureまたはLinux Kernelの理解のような本でこの問題の詳細な調査を開始することをお勧めします。

2.4。 盗みを監視する方法は？

他のプロセッサメトリックと同様に、仮想マシン内のスチールを監視することは簡単です。プロセッサメトリックを削除する手段はすべて使用できます。 主なことは、仮想マシンがLinux上にあることです。 何らかの理由で、Windowsはそのような情報をユーザーに提供しません。 :(





上のコマンド出力：CPU負荷の詳細、右端の列-スチール



ハイパーバイザーからこの情報を取得しようとすると、複雑さが生じます。 たとえば、負荷平均（LA）パラメータ-キューで実行を待機しているプロセスの平均値によって、ホストマシンでのスチールを予測できます。 このパラメーターの計算方法は単純ではありませんが、一般に、プロセッサスレッドの数で正規化されたLAが1より大きい場合、Linuxサーバーが多少過負荷であることを示しています。



これらのプロセスはすべて何を待っていますか？ 明白な答えはプロセッサーです。 しかし、答えは完全に正しいわけではありません。プロセッサーが無料で、LAがロールオーバーすることがあるためです。 NFSがどのように落ち、LAが成長するかを覚えておいてください。 ディスク、および他の入出力デバイスとほぼ同じになる場合があります。 しかし実際には、プロセスは、I / Oデバイスに関連付けられた物理的ロックと、mutexなどの論理的ロックの両方の終了を予期できます。 これには、ハードウェアレベルでのロック（ディスクからの同じ回答）、またはロジック（多数のエンティティ、ミューテックスアダプティブおよびスピン、セマフォ、条件変数、rwロック、ipcロックなどを含むいわゆるロックプリミティブ）も含まれます。



LAのもう1つの特徴は、オペレーティングシステムの平均値と見なされることです。 たとえば、1つのファイルについて100個のプロセスが競合し、LA = 50となります。 このような大きな価値は、OSが悪いことを示唆しているように思えます。 しかし、他の不正に作成されたコードの場合、これは彼にとってのみ悪いものであり、オペレーティングシステムの他のプロセスは影響を受けないという事実にもかかわらず、通常の状態になります。



この平均化のため（1分以上）、LAインジケータで何かを判断することは最も感謝すべきタスクではなく、特定のケースでは結果が非常に不確実です。 理解しようとすると、最も簡単なケースのみがウィキペディアの記事やその他の利用可能なリソースに記載されており、プロセスの詳細な説明はありません。 ここでも、関心のあるすべての人をブレンダン・グレッグに送ります-リンクについて。 英語での怠lazは、 LAについての彼の人気記事の翻訳です 。

3.特殊効果

ここで、遭遇したスチールの外観の主なケースについて説明します。 前述からどのように進み、ハイパーバイザーのインジケーターにどのように関連するかを説明します。



リサイクル 。 最も単純で頻繁なもの：ハイパーバイザーが再利用されます。 実際、実行中の仮想マシンは多数あり、それらの内部で大量のプロセッサが消費され、多くの競合があり、LAの使用率は1を超えています（プロセッサスレッドによって正規化されています）。 すべてのvirtualoksの内部ではすべてが遅くなります。 ハイパーバイザーから送信されるスチールも増加しています。負荷を再分散するか、誰かをオフにする必要があります。 一般に、すべては論理的で理解しやすいものです。



準仮想化と単一インスタンス 。 ハイパーバイザーには単一の仮想マシンがあり、その一部を消費しますが、ディスクなどの入力/出力に大きな負荷を与えます。 そして、その中のどこかから、最大10％の小さなスチールが表示されます（いくつかの実験で示されています）。



ケースは興味深いです。 盗用は、準仮想化ドライバーのレベルでのロックのために表示されます。 仮想マシン内で割り込みが作成され、ドライバーによって処理され、ハイパーバイザーに送られます。 仮想マシンのハイパーバイザーでの割り込み処理により、送信された要求のように見え、実行準備が整い、プロセッサーを待機していますが、プロセッサー時間は与えられません。 Virtualkaは、今回が盗まれたと考えています。



これは、バッファーが送信され、ハイパーバイザーのカーネルスペースに移動したときに発生し、待機を開始します。 しかし、virtualkaの観点から、彼はすぐに戻るべきです。 したがって、スチール計算アルゴリズムによれば、この時間は盗まれたと見なされます。 ほとんどの場合、このような状況では他のメカニズム（たとえば、他のsys呼び出しの処理）が存在する可能性がありますが、それらに大きな違いはありません。



重負荷のvirtualoksに対するシェダー 。 ある仮想マシンが他の仮想マシンよりも盗みに苦しむ場合、それはシェダラーと正確に接続されます。 プロセスがプロセッサにロードする負荷が高いほど、シェダーはそれをより早く排出し、他のプロセッサも動作できるようにします。 仮想マシンが少し消費する場合、彼女はほとんど盗みをしません：彼女のプロセスは正直に座って待っていました、彼にもっと時間を与える必要があります。 仮想マシンがすべてのコアで最大負荷を生成する場合、多くの場合、プロセッサから追放され、多くの時間を与えないようにします。



さらに悪いことに、仮想マシン内のプロセスは、データ処理に対応できないため、より多くのプロセッサを取得しようとします。 それから、ハイパーバイザー上のオペレーティングシステムは、正直な最適化により、プロセッサー時間を短縮します。 このプロセスは雪崩のように起こり、盗みは空に飛びますが、他のバーチャルはほとんど気づきません。 そして、コアが多ければ多いほど、マシンはディストリビューションの対象外になりました。 要するに、多くのコアを備えた負荷の高い仮想マシンが最も被害を受けます。



低LAですが、盗みがあります。 LAが約0.7の場合（つまり、ハイパーバイザーの負荷が低いようですが）、個々の仮想マシン内でスチールが観察される場合：

• 上記の準仮想化オプション。 仮想マシンは、盗むことを指すメトリックを受け取ることができますが、ハイパーバイザーはすべて問題ありません。 私たちの実験の結果によると、このようなスチールオプションは10％を超えず、仮想マシン内のアプリケーションパフォーマンスに大きな影響を与えることはありません。
  
  
• パラメーターLAは誤って考慮されます。 より正確には、特定の瞬間ごとに真であると見なされますが、1分間平均すると、過小評価されます。 たとえば、1つの仮想マシンがすべてのプロセッサをハイパーバイザーの3分の1あたり30分正確に消費する場合、ハイパーバイザーの1分あたりのLAは0.15になります。 同時に動作するこのような4つの仮想マシンは0.6になります。 そして、それらのそれぞれで30分間、LAで25％のワイルドスティールがあったという事実は、もはや引き出せません。
  
  
• 繰り返しますが、誰かが食べすぎだと決めたシェドラーのために、これを待ってください。 その間、コンテキストを切り替え、割り込みを処理し、その他の重要なシステム処理を行います。 その結果、問題が発生しない仮想マシンもあれば、パフォーマンスが大幅に低下する仮想マシンもあります。
  
  

4.その他の歪み

仮想マシンでのプロセッサ時間の正直な返還をゆがめるもう1つの理由があります。 たとえば、ハイパートレッドとNUMAは計算を複雑にします。 シェダラーは係数を使用するため、プロセスの実行のためにカーネルの選択を完全に混乱させます-重みは、コンテキストを切り替えるときに計算をさらに困難にします。



ターボブーストや逆に、省エネモードなどの技術に起因する歪みがあります。これらのモードは、使用率を計算するときに、サーバー上の周波数やタイムスライスを人工的に増減させることができます。 ターボブーストをオンにすると、別のプロセッサスレッドのパフォーマンスが向上するため、1つのプロセッサスレッドのパフォーマンスが低下します。 現時点では、現在のプロセッサ周波数に関する情報は仮想マシンに送信されず、誰かが時間を縛っていると考えています（たとえば、2 GHzを要求したが、半分は受信した）。



一般に、歪みの原因はさまざまです。 特定のシステムでは、他の何かを見つけることができます。 上記へのリンクを提供した本から始めて、perf、sysdig、systemtapなどのユーティリティを使用してハイパーバイザーから統計を取得するとよいでしょう。

5.結論

1. 準仮想化により、一定量のスチールが発生する可能性があり、正常と見なすことができます。 インターネットでは、この値は5〜10％になる可能性があると書いています。 これは、仮想マシン内のアプリケーションと、物理マシンにかかる負荷の種類に依存します。 仮想マシン内のアプリケーションがどのように感じるかに注意を払うことが重要です。
   
   
2. ハイパーバイザーの負荷と仮想マシン内のスチールの比率は、常に一意に相互接続されているわけではありません;両方のスチール推定は、異なる負荷の下で特定の状況で誤っている可能性があります。
   
   
3. Shedulerは、多くの質問をするプロセスを扱いません。 彼は、より多くを求めている人にはあまり与えないようにしています。 大規模な仮想マシンは悪です。
   
   
4. 小さなスチールは準仮想化なしの標準になります（仮想マシン内の負荷、近隣の負荷の特性、スレッド間の負荷分散、およびその他の要因を考慮に入れます）。
   
   
5. 特定のシステムでスチールを見つけたい場合は、さまざまなオプションを調査し、メトリックを収集し、慎重に分析して、負荷を均等に分散する方法を検討する必要があります。 実験から確認するか、カーネルデバッガーで表示する必要がある場合は、どのケースからも逸脱する可能性があります。