盗む: 仮想マシンから CPU 時間を盗むのは誰か

こんにちは！ 仮想マシン内で盗みが発生するメカニズムと、クラウド プラットフォームのテクニカル ディレクターとして私が深く掘り下げる必要があった、彼の調査中になんとか発見できたいくつかの非明白な成果物について、簡単な言葉で話したいと思います。 Mail.ru クラウド ソリューション。 プラットフォームは KVM 上で動作します。

CPU スティール時間は、仮想マシンが実行のためにプロセッサ リソースを受け取らない時間です。 この時間は、仮想化環境のゲスト オペレーティング システムでのみ考慮されます。 人生において、これらの割り当てられたリソースがどこに使われるのかという理由は非常に曖昧です。 しかし、私たちはそれを解明しようと決心し、いくつかの実験を行ってみました。 盗みについてすべてを知っているわけではありませんが、ここで興味深いことをお話しします。

1. 盗むとは

したがって、スティールは、仮想マシン内のプロセスのプロセッサ時間の不足を示すメトリックです。 説明どおり KVMカーネルパッチ内、steel は、ハイパーバイザーが仮想マシン プロセスを実行のキューに入れているにもかかわらず、ホスト OS 上で他のプロセスを実行している時間です。 つまり、スティールは、プロセスの実行準備が整った時間と、プロセスに CPU 時間が割り当てられた時間との差として計算されます。

仮想マシン カーネルは、ハイパーバイザーからスチール メトリックを受け取ります。 同時に、ハイパーバイザーは、他にどのようなプロセスを実行しているのかを明示せず、単に「忙しいので時間を与えることができません」とだけ述べています。 KVM では、スチール計算のサポートが追加されています。 パッチ。 ここで重要な点が XNUMX つあります。

• 仮想マシンはハイパーバイザーからスチールについて学習します。 つまり、仮想マシン自体のプロセスの損失という観点から見ると、これは間接的な測定となり、さまざまな歪みが生じる可能性があります。
• ハイパーバイザーは、他に何を行っているかに関する情報を仮想マシンと共有しません。重要なのは、ハイパーバイザーがそれに時間を費やさないことです。 このため、仮想マシン自体は、競合するプロセスの性質によって評価されるスチール インジケーターの歪みを検出できません。

2. スティールに影響を与えるもの

2.1. スティール計算

実際、スチールは通常の CPU 使用時間とほぼ同じように考慮されます。 リサイクルがどのように考慮されているかについてはあまり情報がありません。 おそらく大多数がこの質問は当然だと考えているからでしょう。 しかし、ここにも落とし穴があります。 このプロセスの概要については、以下をお読みください。 ブレンダン・グレッグによる記事: 使用率を計算する際のさまざまなニュアンスと、次の理由でこの計算が誤る状況について学びます。

• プロセッサの過熱。サイクルがスキップされます。
• プロセッサーのクロック周波数を変更するターボ ブーストを有効/無効にします。
• SpeedStep などのプロセッサ省電力テクノロジを使用するときに発生するタイム スライスの長さの変化。
• 平均的な問題の計算: 80 分間の使用率推定値 100% では、短期間のバースト XNUMX% が隠れる可能性があります。
• スピン ロックによりプロセッサは再利用されますが、ユーザー プロセスでは実行の進行が見られません。 その結果、プロセスによるプロセッサの推定使用率は XNUMX% になりますが、プロセスは物理的にプロセッサ時間を消費しません。

スティールの同様の計算を説明した記事は見つかりませんでした (ご存知の場合は、コメントで共有してください)。 しかし、情報源から判断すると、計算メカニズムはリサイクルの場合と同じです。 KVM プロセス (仮想マシン プロセス) 用に別のカウンターがカーネルに直接追加され、プロセッサー時間待機状態にある KVM プロセスの継続時間をカウントするだけです。 カウンタは仕様からプロセッサに関する情報を取得し、すべてのティックが仮想マシン プロセスによって使用されているかどうかを確認します。 すべての場合、プロセッサは仮想マシンのプロセスにのみ関与していたと考えられます。 それ以外の場合は、プロセッサが別のことを実行していて、steel が出現したことを通知します。

盗塁カウントのプロセスには、通常の盗塁カウントと同じ問題が発生します。 このような問題が頻繁に発生するというわけではありませんが、落胆するように見えます。

2.2. KVM での仮想化の種類

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

放送する。 この場合、仮想マシンのオペレーティング システムとハイパーバイザーの物理デバイスの動作は次のようになります。

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

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

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

準仮想化。 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 カーネル アーキテクチャまたはソースを読むことができます。 CFS の本質は、プロセスの実行時間に応じてプロセス間でプロセッサ時間を配分することにあります。 プロセスに必要な CPU 時間が増えるほど、取得できる CPU 時間は減ります。 これにより、すべてのプロセスの「公平な」実行が保証され、XNUMX つのプロセスが常にすべてのプロセッサを占有することがなくなり、他のプロセスも実行できます。

場合によっては、このパラダイムが興味深い成果物につながることがあります。 長年の Linux ユーザーは、コンパイラなどのリソースを大量に消費するアプリケーションの起動中に、デスクトップ上の通常のテキスト エディタがフリーズしたことをきっと覚えているでしょう。 これは、デスクトップ アプリケーションのリソースをあまり消費しないタスクが、コンパイラなどのリソースを積極的に消費するタスクと競合するために発生しました。 CFS はこれは不公平であると考え、テキスト エディタを定期的に停止し、プロセッサにコンパイラ タスクを処理させます。 これはメカニズムで修正されました sched_autogroup、しかし、タスク間のプロセッサ時間の分散に関する他の多くの機能は残りました。 実際、この話は CFS のすべてがどれほど悪いかについてではなく、プロセッサ時間の「公平な」配分が最も簡単なタスクではないという事実に注意を向けようとする試みです。

スケジューラにおけるもう XNUMX つの重要な点は、プリエンプションです。 これは、プロセッサから笑いのプロセスを追い出し、他のプロセスを動作させるために必要です。 追放のプロセスは、コンテキスト スイッチング (プロセッサ コンテキスト スイッチ) と呼ばれます。 同時に、タスクのコンテキスト全体 (スタック、レジスターなどの状態) が保存され、その後プロセスは待機状態になり、別のプロセスがそのプロセスを引き継ぎます。 これは OS にとってコストのかかる操作であり、めったに使用されませんが、実際には何の問題もありません。 コンテキストの切り替えが頻繁に発生する場合は、OS に問題があることを示している可能性がありますが、通常は継続的に発生し、特に何も示しません。

XNUMX つの事実を説明するには、このような長い話が必要です。つまり、正直な Linux スケジューラでプロセスが消費しようとするプロセッサ リソースが増えるほど、他のプロセスも動作できるよう、プロセスがより早く停止されます。 これが正しいかどうかは難しい問題であり、負荷が異なれば解決方法も異なります。 Windows では、最近までスケジューラはデスクトップ アプリケーションの優先処理に重点を置いていたため、バックグラウンド プロセスがハングする可能性がありました。 Sun Solaris には XNUMX つの異なるクラスのスケジューラがありました。 仮想化が開始されたとき、XNUMX 番目の仮想化が追加されました。 フェアシェアスケジューラ前の XNUMX つは Solaris ゾーン仮想化では適切に機能しなかったためです。 この問題については、次のような書籍で詳細な研究を始めることをお勧めします。 Solaris の内部: Solaris 10 と OpenSolaris カーネル アーキテクチャ または Linux カーネルを理解する.

2.4. 盗みを監視するにはどうすればよいですか?

仮想マシン内のスチールの監視は、他のプロセッサ メトリックと同様に簡単です。任意のプロセッサ メトリック ツールを使用できます。 重要なのは、仮想マシンが Linux 上に存在する必要があるということです。 何らかの理由で、Windows はそのような情報をユーザーに提供しません。 🙁

一番上のコマンドの出力: プロセッサーの負荷の詳細、右端の列 - スチール

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

これらのプロセスは何を待っているのでしょうか? 明らかな答えはプロセッサです。 しかし、プロセッサーが空いていて LA がスケールから外れてしまう場合があるため、答えは完全に正しいわけではありません。 覚えて NFS がどのように衰退し、同時に LA がどのように成長するか。 ディスクや他の入出力デバイスでもほぼ同じことが言えます。 しかし実際には、プロセスは、I/O デバイスに関連付けられた物理的なロックと、ミューテックスなどの論理的なロックの両方で、ロックの終了を待つことができます。 また、ハードウェア レベルでのロック (ディスクからの同じ応答)、またはロジック (いわゆるロック プリミティブ。これには、一連のエンティティ、ミューテックス アダプティブおよびスピン、セマフォ、条件変数、rw ロック、ipc ロックが含まれます) も含まれます。 ..)。

LA のもう 100 つの特徴は、OS の平均値として考慮されることです。 たとえば、50 のプロセスが XNUMX つのファイルをめぐって競合すると、LA=XNUMX になります。 このような大きな値は、オペレーティング システムが悪いことを示していると思われます。 しかし、他の不正に書かれたコードの場合、それのみが問題であり、オペレーティング システムの他のプロセスには影響がないにもかかわらず、これは正常な状態である可能性があります。

この平均化 (少なくとも XNUMX 分) が行われるため、LA に関して何かを決定することは、最もやりがいのある作業ではなく、特定のケースでは非常に不確実な結果が得られます。 これを理解しようとすると、Wikipedia の記事やその他の利用可能なリソースでは、プロセスの深い説明がなく、最も単純なケースのみが説明されていることがわかります。 興味のある方全員にもう一度送ります、 ブレンダン・グレッグへ  - リンクに従ってください。 英語で怠け者は誰ですか - LAに関する彼の人気記事の翻訳.

3.特殊効果

ここで、私たちが遭遇した主な窃盗事件について詳しく見ていきましょう。 上記のすべてからどのように結果が導き出され、ハイパーバイザーのインジケーターとどのように相関するかを説明します。

リサイクル。 最も単純で最も一般的な方法は、ハイパーバイザーがリサイクルされることです。 実際、実行中の仮想マシンが多数あり、仮想マシン内でのプロセッサ消費量が高く、競合が多く、LA による使用率は 1 より大きくなります (プロセッサ スレッドによって正規化されます)。 すべての virtualok の内部では、すべてが遅くなります。 ハイパーバイザーから送信されるスチールも増加するため、負荷を再分散するか、誰かをオフにする必要があります。 一般に、すべてが論理的で理解可能です。

準仮想化と単独のインスタンス。 ハイパーバイザーには仮想マシンが 10 つだけあり、その一部は消費されますが、ディスクなどに大きな I/O 負荷がかかります。 そして、どこかから、最大XNUMX％の小さな盗みがその中に現れます（いくつかの実験が示すように）。

事例は興味深いですね。 ここで Steal が表示されるのは、準仮想化ドライバーのレベルでのロックのためです。 割り込みは仮想マシン内で作成され、ドライバーによって処理されてハイパーバイザーに送られます。 ハイパーバイザーでの割り込み処理により、これは仮想マシンに送信されたリクエストのように見え、実行の準備ができてプロセッサーを待っていますが、プロセッサー時間が与えられていません。 仮想マシンは、この時間が盗まれたと考えます。

これは、バッファが送信された瞬間に発生し、バッファはハイパーバイザーのカーネル空間に移動し、バッファがそれを待ち始めます。 ただし、仮想マシンの観点からは、彼はすぐに戻る必要があります。 したがって、盗塁計算アルゴリズムによれば、この時間は盗まれたと見なされます。 おそらく、この状況では他のメカニズム (たとえば、さらにシステム コールを処理するなど) が存在する可能性がありますが、それらに大きな違いはありません。

高負荷の仮想マシンに対するスケジューラ。 ある仮想マシンが他の仮想マシンよりも盗みの被害を受ける場合、これはまさにスケジューラが原因です。 プロセスがプロセッサに負荷をかけるほど、スケジューラはプロセッサをより早くキックアウトし、残りのプロセッサも動作できるようになります。 仮想マシンが少し消費しても、盗むことはほとんどありません。そのプロセスは正直に座って待機しているため、より多くの時間を与える必要があります。 仮想マシンがそのすべてのコアに最大の負荷を生成すると、仮想マシンはプロセッサから追い出されることが多くなり、仮想マシンにはあまり時間を与えないようになります。

さらに悪いことに、仮想マシン内のプロセスがデータの処理に対応できずに、より多くのプロセッサを取得しようとすると、そのような事態が発生します。 その後、ハイパーバイザー上のオペレーティング システムは、誠実な最適化により、プロセッサーに与える時間がますます少なくなります。 このプロセスは雪崩のように発生し、空に飛び上がりますが、他の仮想マシンはほとんど気付かない可能性があります。 そして、コアが多いほど、ディストリビューションに該当するマシンは悪化します。 つまり、多くのコアを備えた高負荷の仮想マシンが最も影響を受けます。

LAは低いが、スティールはある。 LA が約 0,7 (つまり、ハイパーバイザーの負荷が低いと思われる) であるが、個々の仮想マシン内でスチールが観察された場合:

• 準仮想化に関するオプションはすでに上で説明されています。 ハイパーバイザーは正常に動作していますが、仮想マシンはスチールを示すメトリクスを受信できます。 実験の結果によると、このスチール オプションは 10% を超えず、仮想マシン内のアプリケーションのパフォーマンスに重大な影響を与えることはありません。
• LA パラメータは正しくないと考えられます。 より正確には、それぞれの特定の瞬間では正しいと考えられますが、0,15 分間の平均では過小評価されていることがわかります。 たとえば、ハイパーバイザーの 0,6 分の 25 に XNUMX 台の仮想マシンがそのすべてのプロセッサをちょうど XNUMX 分消費する場合、ハイパーバイザーの XNUMX 分あたりの LA は XNUMX になります。 このような仮想マシン XNUMX 台が同時に動作すると、XNUMX になります。 そして、それぞれの試合でXNUMX分間、ロサンゼルスのXNUMX％でワイルドスティールがあったという事実は、もはや引き出すことはできません。
• 繰り返しますが、誰かが食べすぎていると判断し、その人を待たせたスケジューラのせいです。 その間、コンテキストを切り替え、割り込みを処理し、その他の重要なシステム関連の処理を行います。 その結果、一部の仮想マシンでは問題が発生しませんが、他の仮想マシンでは重大なパフォーマンスの低下が発生します。

4. その他の歪み

仮想マシンのプロセッサー時間の正直なリターンを歪める理由は他にも XNUMX 万あります。 たとえば、ハイパースレッディングと NUMA は計算を複雑にします。 スケジューラは係数 (重み) を使用するため、プロセスを実行するためのカーネルの選択が完全に混乱します。これにより、コンテキストを切り替えるときに計算がさらに困難になります。

ターボ ブーストやその逆の省電力モードなどのテクノロジによる歪みがあり、使用率を計算するときに、サーバー上の周波数や時間量さえ人為的に増減する可能性があります。 ターボ ブーストを有効にすると、あるプロセッサ スレッドのパフォーマンスが向上するため、別のプロセッサ スレッドのパフォーマンスが低下します。 現時点では、現在のプロセッサ周波数に関する情報は仮想マシンに送信されていないため、誰かが時間を盗んでいると考えられます (たとえば、2 GHz を要求したが、半分の周波数を受信したなど)。

一般に、歪みにはさまざまな理由が考えられます。 特定のシステムでは、別のものが見つかる可能性があります。 上でリンクを示した書籍から始めて、perf、sysdig、systemtap などのユーティリティを使用してハイパーバイザーから統計を読み取ることをお勧めします。 数十.

5 結論

1. 準仮想化により一定量のスチールが発生する可能性がありますが、これは正常であると考えられます。 インターネット上では、この値は 5 ～ 10% になる可能性があると書かれています。 それは、仮想マシン内のアプリケーションと、仮想マシンが物理デバイスに与える負荷によって異なります。 ここで、仮想マシン内でアプリケーションがどのように感じられるかに注意を払うことが重要です。
2. ハイパーバイザーの負荷と仮想マシン内のスチールの負荷の比率は常に明確に相互関連しているわけではなく、負荷が異なる特定の状況ではスチールの両方の推定値が誤る可能性があります。
3. スケジューラは、多くの要求を要求するプロセスに対して悪い態度をとります。 彼は、より多くを求める人には、より少なく与えようとします。 巨大な仮想マシンは悪です。
4. 準仮想化がなくても、小規模なスチールが標準となる可能性があります (仮想マシン内の負荷、隣接マシンの負荷特性、スレッド間の負荷分散、その他の要因を考慮します)。
5. 特定のシステムでのスチールを把握したい場合は、さまざまなオプションを検討し、メトリクスを収集して注意深く分析し、負荷を均等に分散する方法を考える必要があります。 どのような場合でも逸脱が発生する可能性があるため、実験的に確認するか、カーネル デバッガで調べる必要があります。

出所： habr.com