VMware vSphere での仮想マシンのパフォーマンスの分析。 パート 1: CPU

VMware vSphere (またはその他のテクノロジ スタック) に基づいた仮想インフラストラクチャを管理している場合、おそらくユーザーから「仮想マシンが遅い!」という苦情をよく聞くことになるでしょう。 この一連の記事では、パフォーマンス指標を分析し、何が原因で速度が低下するのか、また速度が低下しないようにする方法について説明します。

仮想マシンのパフォーマンスについて次の側面を考慮します。

• CPU、
• RAM、
• ディスク、
• ネットワーク。

CPUから始めます。

パフォーマンスを分析するには、次のものが必要です。

• vCenter パフォーマンス カウンター – パフォーマンス カウンター。vSphere Client を通じてグラフを表示できます。 これらのカウンターに関する情報は、クライアントのどのバージョンでも利用できます (C# の「シック」クライアント、Flex の Web クライアント、HTML5 の Web クライアント)。 これらの記事では、C# クライアントのスクリーンショットを使用します。これは、縮小したほうが見栄えが良いためです:)
• ESXTOP – ESXi コマンド ラインから実行するユーティリティ。 これを利用すると、パフォーマンス カウンターの値をリアルタイムで取得したり、特定の期間のこれらの値を .csv ファイルにアップロードしてさらに分析したりできます。 次に、このツールについて詳しく説明し、このトピックに関するドキュメントや記事への役立つリンクをいくつか紹介します。

いくつかの説

ESXi では、別個のプロセス (VMware 用語では「世界」) が各 vCPU (仮想マシン コア) の動作を担当します。 サービス プロセスもありますが、VM のパフォーマンスを分析するという観点から見ると、それほど興味深いものではありません。

ESXi のプロセスは、次の XNUMX つの状態のいずれかになります。

• ラン – プロセスはいくつかの有用な作業を実行します。
• 待つ – プロセスは何も作業を行っていないか (アイドル状態)、入出力を待機しています。
• コストップ – マルチコア仮想マシンで発生する状態。 この問題は、ハイパーバイザー CPU スケジューラ (ESXi CPU スケジューラ) が、物理サーバー コア上のすべてのアクティブな仮想マシン コアの同時実行をスケジュールできない場合に発生します。 物理的な世界では、すべてのプロセッサ コアが並行して動作し、VM 内のゲスト OS も同様の動作を期待するため、ハイパーバイザーは、クロック サイクルをより速く終了する能力のある VM コアの速度を下げる必要があります。 ESXi の最新バージョンでは、CPU スケジューラは緩和型協調スケジューリングと呼ばれるメカニズムを使用します。ハイパーバイザは、「最速」の仮想マシン コアと「最も遅い」仮想マシン コアの間のギャップ（スキュー）を考慮します。 ギャップが特定のしきい値を超えると、高速コアはコストトップ状態に入ります。 VM コアがこの状態で長時間かかると、パフォーマンスの問題が発生する可能性があります。
• レディ – ハイパーバイザーが実行用のリソースを割り当てることができない場合、プロセスはこの状態になります。 Ready 値が高いと、VM のパフォーマンスの問題が発生する可能性があります。

基本的な仮想マシンの CPU パフォーマンス カウンター

CPU使用率、 ％。 指定された期間の CPU 使用率の割合を表示します。

どのように分析するのか? VM が一貫して CPU を 90% 使用する場合、または 100% までのピークがある場合は、問題が発生しています。 問題は、VM 内のアプリケーションの「遅い」動作だけでなく、ネットワーク経由で VM にアクセスできないことでも表れることがあります。 監視システムによって VM が定期的に低下していることが示された場合は、CPU 使用率グラフのピークに注意してください。

仮想マシンの CPU 負荷を示す標準アラームがあります。

何をしますか？ VM の CPU 使用率が常に異常に高い場合は、vCPU の数を増やすか (残念ながら、これが常に役立つとは限りません)、より強力なプロセッサを搭載したサーバーに VM を移動することを検討できます。

CPU 使用率 (MHz)

vCenter の使用率 (%) のグラフでは、仮想マシン全体についてのみ表示され、個々のコアのグラフはありません (Esxtop にはコアの % 値があります)。 各コアの使用状況を MHz 単位で確認できます。

どのように分析するのか? アプリケーションがマルチコア アーキテクチャ向けに最適化されていない場合があります。アプリケーションは 100 つのコアのみを XNUMX% 使用し、残りのコアは負荷がかからずアイドル状態になります。 たとえば、デフォルトのバックアップ設定では、MS SQL は XNUMX つのコアのみでプロセスを開始します。 その結果、バックアップの速度が低下するのは、ディスクの速度が遅いためではなく (これがユーザーが最初に不満を述べていたことです)、プロセッサが対応できないためです。 この問題はパラメータを変更することで解決されました。バックアップは複数のファイル (それぞれ複数のプロセス) で並行して実行され始めました。

コアに対する不均一な負荷の例。

(上のグラフのように) コアの負荷が不均一で、一部のコアが 100% のピークを持つ状況もあります。 XNUMX つのコアのみをロードする場合と同様、CPU 使用率のアラームは機能しません (VM 全体に対するものです) が、パフォーマンスの問題が発生します。

何をしますか？ 仮想マシン内のソフトウェアがコアを不均等にロードする場合 (XNUMX つのコアのみまたはコアの一部を使用する場合)、コアの数を増やしても意味がありません。 この場合、より強力なプロセッサを搭載したサーバーに VM を移動することをお勧めします。

サーバー BIOS の消費電力設定を確認してみることもできます。 多くの管理者は、BIOS でハイパフォーマンス モードを有効にし、それによって C ステートおよび P ステートの省エネ テクノロジを無効にします。 最新の Intel プロセッサは、他のコアを犠牲にして個々のプロセッサ コアの周波数を高めるターボ ブースト テクノロジを使用しています。 ただし、これは省エネテクノロジーがオンになっている場合にのみ機能します。 それらを無効にすると、プロセッサーはロードされていないコアの電力消費を削減できなくなります。

VMware では、サーバーの省電力テクノロジーを無効にせず、電力管理を可能な限りハイパーバイザーに任せるモードを選択することを推奨しています。 この場合、ハイパーバイザーの消費電力設定で「高パフォーマンス」を選択する必要があります。

インフラストラクチャ内に CPU 周波数の向上を必要とする個々の VM (または VM コア) がある場合、消費電力を正しく調整することでパフォーマンスを大幅に向上させることができます。

CPU 対応

VM コア (vCPU) が準備完了状態の場合、有用な作業は実行されません。 この状況は、仮想マシンの vCPU プロセスを割り当てることができる空き物理コアをハイパーバイザーが見つけられない場合に発生します。

どのように分析するのか? 通常、仮想マシンのコアが 10% 以上の時間で準備完了状態にある場合、パフォーマンスの問題が発生します。 簡単に言うと、VM は 10% 以上の時間、物理リソースが使用可能になるまで待機します。

vCenter では、CPU Ready に関連する 2 つのカウンターを表示できます。

• 準備、
• 準備ができました。

両方のカウンターの値は、VM 全体と個々のコアの両方で表示できます。
Readiness は値をパーセンテージとしてすぐに表示しますが、リアルタイムでのみ表示されます (過去 20 時間のデータ、測定間隔 XNUMX 秒)。 このカウンターは、「すぐにでも発生する」問題を検索する場合にのみ使用することをお勧めします。

Ready Counter の値は、歴史的な観点から見ることもできます。 これは、パターンを確立したり、問題をより深く分析したりするのに役立ちます。 たとえば、仮想マシンがある時点でパフォーマンスの問題が発生し始めた場合、CPU Ready 値の間隔と、この VM が実行されているサーバーの合計負荷を比較し、負荷を軽減するための措置を講じることができます (DRS の場合)。失敗します）。

Readiness とは異なり、Ready はパーセンテージではなくミリ秒で表示されます。 これは合計タイプのカウンターです。つまり、測定期間中に VM コアが準備完了状態にあった時間を示します。 次の簡単な式を使用して、この値をパーセンテージに変換できます。

(CPU レディの合計値 / (グラフのデフォルトの更新間隔 (秒) * 1000)) * 100 = CPU レディ %

たとえば、以下のグラフの VM の場合、仮想マシン全体のピークの Ready 値は次のようになります。

Ready パーセンテージを計算するときは、次の XNUMX つの点に注意する必要があります。

• VM 全体の Ready 値は、コア全体の Ready の合計です。
• 測定間隔。 リアルタイムの場合は 20 秒、たとえば日足チャートでは 300 秒です。

積極的なトラブルシューティングを行うと、これらの単純なポイントが簡単に見落とされ、存在しない問題の解決に貴重な時間が無駄になる可能性があります。

以下のグラフのデータに基づいて Ready を計算してみましょう。 (324474/(20*1000))*100 = VM 全体の 1622%。 コアを見ればそれほど怖くない：1622/64 = コアあたり 25%。 この場合、問題は非常に簡単に見つかります。Ready 値は非現実的です。 ただし、複数のコアを備えた VM 全体で 10 ～ 20% について話している場合、各コアの値は通常の範囲内である可能性があります。

何をしますか？ Ready 値が高い場合は、サーバーに仮想マシンの通常の動作に十分なプロセッサ リソースがないことを示します。 このような状況では、残っているのはプロセッサー (vCPU:pCPU) によるオーバーサブスクリプションを減らすことだけです。 明らかに、これは、既存の VM のパラメータを減らすか、VM の一部を他のサーバーに移行することによって実現できます。

共同停止

どのように分析するのか? このカウンタも Summation タイプであり、Ready と同じ方法でパーセンテージに変換されます。

(CPU 同時停止の合計値 / (グラフのデフォルト更新間隔 (秒) * 1000)) * 100 = CPU 同時停止 %

ここでは、VM 上のコアの数と測定間隔にも注意する必要があります。
Costop 状態では、カーネルは有用な作業を実行しません。 VM サイズとサーバー上の通常の負荷を正しく選択すると、共同停止カウンターはゼロに近づくはずです。

この場合、負荷は明らかに異常です:)

何をしますか？ 多数のコアを備えた複数の VM が XNUMX つのハイパーバイザー上で実行されており、CPU でオーバーサブスクリプションが発生すると、共同停止カウンターが増加し、これらの VM のパフォーマンスに問題が発生する可能性があります。

また、XNUMX つの VM のアクティブ コアが、ハイパートレッドが有効になっている XNUMX つの物理サーバー コア上のスレッドを使用する場合、共同停止が増加します。 この状況は、たとえば、VM が実行されているサーバー上で物理的に利用可能なコアよりも多くのコアを VM に持っている場合、または VM に対して「preferHT」設定が有効になっている場合に発生する可能性があります。 この設定についてはこちらをご覧ください ここで.

高い同時停止による VM のパフォーマンスの問題を回避するには、この VM 上で実行されるソフトウェアの製造元の推奨事項と、VM が実行される物理サーバーの機能に従って VM サイズを選択します。

予備のコアを追加しないでください。これにより、VM 自体だけでなく、サーバー上の隣接する VM にもパフォーマンスの問題が発生する可能性があります。

その他の有用な CPU メトリクス

ラン – 測定期間中に vCPU が RUN 状態にあった時間 (ミリ秒)、つまり実際に有用な作業を実行していた時間。

アイドル – 測定期間中に vCPU が非アクティブ状態にあった時間 (ミリ秒)。 高いアイドル値は問題ではありません。vCPU は単に「何もすることがない」だけです。

待つ – 測定期間中に vCPU が待機状態にあった時間 (ミリ秒)。 このカウンターには IDLE が含まれているため、Wait 値が高くても問題はありません。 ただし、Wait が高いときに Wait IDLE が低い場合は、VM が I/O 操作の完了を待っていたことを意味し、これはハード ドライブまたは VM の仮想デバイスのパフォーマンスに問題があることを示している可能性があります。

最大制限あり – 設定されたリソース制限により、測定期間中に vCPU が準備完了状態になった時間 (ミリ秒)。 パフォーマンスが説明できないほど低い場合は、このカウンターの値と VM 設定の CPU 制限を確認すると便利です。 実際、VM には、ユーザーが気づいていない制限がある可能性があります。 たとえば、これは、CPU 制限が設定されているテンプレートから VM のクローンが作成された場合に発生します。

スワップ待機 – 測定期間中に vCPU が VMkernel スワップによる操作を待機した時間。 このカウンターの値がゼロより大きい場合、VM には明らかにパフォーマンスの問題があります。 SWAP については、RAM カウンターに関する記事で詳しく説明します。

ESXTOP

vCenter のパフォーマンス カウンターが履歴データの分析に適している場合は、問題の運用分析を ESXTOP で行う方が適切です。 ここでは、すべての値が既製の形式で表示され（何も翻訳する必要はありません）、最小測定期間は 2 秒です。
CPU の ESXTOP 画面は「c」キーで呼び出され、次のようになります。

便宜上、Shift-V を押すと、仮想マシンのプロセスのみを残すことができます。
個々の VM コアのメトリクスを表示するには、「e」を押して、対象の VM の GID (以下のスクリーンショットでは 30919) を入力します。

デフォルトで表示される列について簡単に説明します。 「f」を押すと列を追加できます。

NWLD (ワールドの数) – グループ内のプロセスの数。 グループを展開して各プロセス (たとえば、マルチコア VM の各コア) のメトリックを表示するには、「e」を押します。 グループ内に複数のプロセスが存在する場合、グループのメトリック値は、個々のプロセスのメトリックの合計と等しくなります。

％使用済み – プロセスまたはプロセスのグループによって使用されるサーバー CPU サイクルの数。

％走る – 測定期間中にプロセスが RUN 状態にあった時間、つまり有益な仕事をしました。 これは、ハイパースレッディング、周波数スケーリング、およびシステム タスク (%SYS) に費やされる時間を考慮しないという点で %USED とは異なります。

%SYS – システム タスクに費やされる時間 (例: 割り込み処理、I/O、ネットワーク操作など)。VM の I/O が大きい場合、値が高くなる可能性があります。

%OVRLP – VM プロセスが実行されている物理コアが他のプロセスのタスクに費やした時間。

これらのメトリクスは次のように相互に関連します。

%USED = %RUN + %SYS - %OVRLP。

通常、%USED メトリックの方が有益です。

％待って – 測定期間中にプロセスが待機状態にあった時間。 IDLE を有効にします。

%IDLE – 測定期間中にプロセスが IDLE 状態にあった時間。

%SWPWT – 測定期間中に vCPU が VMkernel スワップによる操作を待機した時間。

%VMWAIT – 測定期間中、vCPU がイベント (通常は I/O) を待機している状態にあった時間。 vCenter には同様のカウンタがありません。 値が高い場合は、VM 上の I/O に問題があることを示します。

%WAIT = %VMWAIT + %IDLE + %SWPWT。

VM が VMkernel スワップを使用しない場合、パフォーマンスの問題を分析するときは、%VMWAIT を確認することをお勧めします。これは、このメトリクスには、VM が何もしていなかった時間 (%IDLE) が考慮されていないためです。

%RDY – 測定期間中にプロセスが準備完了状態にあった時間。

%CSTP – 測定期間中にプロセスがコストトップ状態にあった時間。

%MLMTD – 設定されたリソース制限により、測定期間中に vCPU が準備完了状態になっていた時間。

%WAIT + %RDY + %CSTP + %RUN = 100% – VM コアは常にこれら XNUMX つの状態のいずれかになります。

ハイパーバイザー上のCPU

vCenter にはハイパーバイザーの CPU パフォーマンス カウンターもありますが、これは何も興味深いものではなく、単にサーバー上のすべての VM のカウンターの合計にすぎません。
サーバーの CPU ステータスを表示する最も便利な方法は、[概要] タブを使用することです。

サーバーおよび仮想マシンに対して、標準のアラームがあります。

サーバーの CPU 負荷が高くなると、サーバー上で実行されている VM でパフォーマンスの問題が発生し始めます。

ESXTOP では、サーバーの CPU 負荷データが画面の上部に表示されます。 標準の CPU 負荷 (ハイパーバイザーにとってあまり有益ではありません) に加えて、さらに XNUMX つのメトリクスがあります。

コア使用率(%) – 物理サーバーコアをロードします。 このカウンターは、測定期間中にコアが作業を実行した時間を示します。

PCPU使用率(%) – ハイパースレッディングが有効な場合、物理コアごとに XNUMX つのスレッド (PCPU) が存在します。 このメトリクスは、各スレッドが作業を完了するまでにかかった時間を示します。

PCPU使用率(%) – PCPU UTIL(%) と同じですが、周波数スケーリング (エネルギー節約の目的でコア周波数を下げるか、ターボ ブースト テクノロジによってコア周波数を増やす) とハイパースレッディングが考慮されます。

PCPU_USED% = PCPU_UTIL% * 実効コア周波数 / 公称コア周波数。

このスクリーンショットでは、一部のコアでは、ターボ ブーストにより、コア周波数が公称周波数よりも高いため、USED 値が 100% を超えています。

ハイパースレッディングがどのように考慮されるかについて少し説明します。 コアが公称周波数で動作しているときに、サーバーの物理コアの両方のスレッドでプロセスが 100% の時間実行される場合、次のようになります。

• コアのCORE UTILは100%となり、
• 両方のスレッドの PCPU UTIL は 100% になります。
• 両方のスレッドの PCPU 使用率は 50% になります。

両方のスレッドが測定期間中に 100% 動作しなかった場合、スレッドが並行して動作していた期間中、コアの PCPU 使用量は半分に分割されます。

ESXTOP には、サーバーの CPU 消費電力パラメータを含む画面もあります。 ここでは、サーバーが省エネルギー技術 (C ステートと P ステート) を使用しているかどうかを確認できます。 「p」キーによって呼び出されます:

一般的な CPU パフォーマンスの問題

最後に、VM CPU パフォーマンスに関する問題の一般的な原因を説明し、それらを解決するための簡単なヒントを示します。

コアクロック速度が十分ではありません。 VM をより強力なコアにアップグレードできない場合は、Turbo Boost がより効率的に動作するように電源設定を変更してみることができます。

VM のサイジングが正しくない (コアが多すぎる/少なすぎる)。 インストールするコアの数が少ない場合、VM の CPU 負荷が高くなります。 多い場合は高いコストップを捕まえましょう。

サーバー上の CPU が大幅にオーバーサブスクリプション。 VM の Ready レベルが高い場合は、CPU のオーバーサブスクリプションを減らします。

大規模な VM 上の不適切な NUMA トポロジ。 VM が認識する NUMA トポロジ (vNUMA) は、サーバーの NUMA トポロジ (pNUMA) と一致する必要があります。 この問題の診断と考えられる解決策は、たとえば次の本に書かれています。 「VMware vSphere 6.5 ホスト リソースの詳細」。 これ以上深くする必要がなく、VM にインストールされている OS にライセンス制限がない場合は、VM 上に一度に XNUMX コアずつ多くの仮想ソケットを作成します。 あまり損することはありません:)

CPU については以上です。 質問をする。 次のパートでは RAM について説明します。

便利なリンク集http://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

出所： habr.com