しばらくの間、私は、当社のビジネスに不可欠なシステムのかなりの数で、軽度から極度までの範囲で「速度低下」の報告が出ている理由を解明しようとしてきました。最近、問題となっているすべてのサーバーがホストされている VMware 環境に目を向けました。
最近、SCOM 2012 用の Veeam VMware 管理パックの試用版をダウンロードしてインストールしましたが、報告された数値を信じることができません (上司も同様です)。上司に報告された数値が正しいと納得してもらうために、VMware クライアント自体を調べて結果を確認し始めました。
私は見てきましたこの VMware KB 記事; 特に Co-Stop の定義は次のように定義されます。
MP 仮想マシンが実行可能な状態であったが、co-vCPU のスケジュール競合により遅延が発生した時間
これを翻訳すると
ゲスト OS はホストからの時間を必要としますが、リソースが利用可能になるまで待たなければならないため、「応答なし」とみなされます。
この翻訳は正しいでしょうか?
もしそうなら、私が見ているものが信じられないのは、次の点です。「遅い」VMの大部分を含むホストは、現在CPU Co-stopの平均を示しています。127,835.94ミリ秒！
これは、このホスト上の VM が CPU 時間のために平均 2 分以上待機する必要があることを意味しますか?
このホストには 2 つの 4 コア CPU があり、1x8 CPU ゲストと 14x4 CPU ゲストがあります。
答え1
この分野で私が経験したことのいくつかを説明すると...
VMware が顧客教育を適切に行っているとは思えません (または管理者) はベスト プラクティスについて説明しておらず、製品の進化に合わせて以前のベスト プラクティスを更新することもありません。この質問は、vCPU 割り当てなどのコア概念が十分に理解されていない例です。最善のアプローチは、VM にさらに多くの vCPU が必要であると判断するまで、1 つの vCPU から小規模に開始することです。
OP の場合、ESXi ホスト サーバーには 2 つのクアッドコア CPU があり、物理コアは 8 個になります。
記述されている仮想マシンのレイアウトは、合計15のゲスト、1 x 8 vCPUと14 x 4 vCPUシステムです。これは、特に8 つの vCPU を備えた単一のゲストそれは意味がありません。そのくらい大きな VM が必要な場合は、おそらくもっと大きなサーバーが必要になります。
ぜひお試しください正しいサイズ仮想マシン。ほとんどの仮想マシンは 2 つの vCPU で十分だと思います。仮想 CPU を追加しても動作が速くなるわけではありません。そのため、それがパフォーマンスの問題の解決策である場合、それは間違ったアプローチです。
ほとんどの環境では、RAMが最も制約を受けるリソースです。しかし、CPUは競合が多すぎると問題になることがあります。これは証拠があります。RAMも問題になることがあります。個々のVMに割り当てられる容量が多すぎる。
これを監視することは可能です。探しているメトリックは「CPU 準備完了率」です。vSphere クライアントから VM を選択し、Performance[> Overview> CPU グラフ] に移動すると、これにアクセスできます。
- CPU 使用率 5% 未満- 大丈夫だよ。
- 5～10% CPU 準備完了- 活動を注意深く見守ってください。
- CPU 準備完了率 10% 以上- 良くない。
下のグラフの黄色の線に注目してください。
問題のある仮想マシンでこれを確認して、報告していただけますか?
答え2
コメントでは、デュアルクアッドコアESXiホストがあり、1つの8vCPU VMを実行していると述べています。14人4vCPU VM。
もしこれが私の環境だったら、私はこう考えるだろうひどく過剰にプロビジョニングされています。そのハードウェアには、最大で 4 ～ 6 台の 4vCPU ゲストを配置します (これは、問題の VM に、その高い vCPU 数を必要とする負荷があることを前提としています)。
黄金律をご存知ないと思いますが、VMware では、必要以上のコアを VM に割り当ててはいけません。理由は何でしょうか? VMware は、VM に割り当てられているコアと同じ数のコアが使用可能でない限り、VM が CPU 時間を取得するのが困難になる、やや厳格な共同スケジューリングを使用します。つまり、4 つの物理コアが同時に開いていない限り、4vCPU VM は 1 単位の作業を実行できません。言い換えると、コアあたり 45% の負荷の 2vCPU VM よりも、CPU 負荷が 90% の 1vCPU VM を使用する方がアーキテクチャ的には優れています。
したがって、常に最小限の vCPU で VM を作成し、必要と判断された場合にのみ vCPU を追加します。
あなたの状況では、Veeam を使用してゲストの CPU 使用率を監視します。可能な限り vCPU の数を減らします。ほぼすべての既存の 4vCPU ゲストで 2vCPU に減らすことができると思います。
確かに、これらすべての VM に実際に vCPU 数を必要とする CPU 負荷がある場合は、追加のハードウェアを購入するだけで済みます。
答え3
127,835.94 ミリ秒は合計値であり、正しい %RDY 値を取得するにはサンプル時間で割る必要があります。ただし、現在、正しい %RDY 読み取り値が取得されているようです。vCPU と物理 CPU の比率をかなり高くすることはできますが、現在の方法ではそれができません。
クアッド vCPU VM が多すぎます。さらに、8 vCPU VM もあります。すでに、適切なサイズ設定と、サイクルを vCPU の数を減らすことに統合しないことの影響について議論している質の高い回答がいくつかあります。明確にしておきたいのは、VM が命令を処理する前に、vCPU の数と同じ数の物理 CPU が使用可能になるまで待つ必要はなくなったものの、マルチ vCPU VM と物理コアの比率でこの規模のオーバープロビジョニングを行うことは非常に有害であるということです。8 コアで 64 vCPU は、4 対 1 の比率の最大値を大幅に超えています。これらのプロセッサに HT があるため、論理コアが 16 個あると想定しています。負荷が軽い 1 および 2 vCPU VM では問題ないかもしれませんが、VM の負荷が大きい場合は実現が困難です。
参考までに、HT プロセッサは CPU 使用率の計算には使用されません。つまり、サーバー上で 2.4 Ghz で動作する 32 個の論理コアがある場合、38.4 GHz に達すると使用率は 100% になります。そのため、負荷平均が 1.0 を超える場合は、これが理由です。
これは、平均 %RDY が 3% で、vCPU と物理 CPU (HT コアを含む) の比率が 3.5 対 1 で実行されている ESXi ホストです。
11:13:49pm up 125 days 7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37
%USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
13.51 15.87 0.50 580.17 0.03 4.67 66.47 0.29 0.00 0.00 0.00
15.24 18.64 0.43 491.54 0.04 4.65 63.70 0.43 0.00 0.00 0.00
13.44 16.40 0.44 494.10 0.02 4.33 66.24 0.48 0.00 0.00 0.00
13.75 16.30 0.51 494.26 0.32 4.32 66.06 0.35 0.00 0.00 0.00
17.56 20.72 0.58 489.35 0.04 4.31 60.76 0.45 0.00 0.00 0.00
13.82 16.43 0.50 494.12 0.07 4.31 66.26 0.26 0.00 0.00 0.00
13.65 16.81 0.49 493.81 0.03 4.21 65.93 0.37 0.00 0.00 0.00
13.73 16.51 0.42 493.63 0.09 4.06 66.24 0.29 0.00 0.00 0.00
13.89 16.37 0.55 580.61 0.04 3.95 66.69 0.28 0.00 0.00 0.00
14.02 17.00 0.33 494.11 0.03 3.93 66.10 0.29 0.00 0.00 0.00
13.44 15.84 0.49 495.17 0.04 3.87 67.24 0.27 0.00 0.00 0.00
13.59 15.84 0.50 580.27 0.04 3.81 67.24 0.44 0.00 0.00 0.00
17.10 19.86 0.50 490.97 0.04 3.74 62.21 0.39 0.00 0.00 0.00
13.32 15.77 0.50 495.34 0.03 3.73 67.47 0.27 0.00 0.00 0.00
13.43 16.15 0.48 494.95 0.05 3.72 67.09 0.38 0.00 0.00 0.00
13.44 16.47 0.49 580.88 0.04 3.72 66.81 0.40 0.00 0.00 0.00
13.71 17.00 0.29 494.13 0.03 3.71 66.26 0.37 0.00 0.00 0.00
17.34 20.41 0.39 490.50 0.05 3.70 61.70 0.37 0.00 0.00 0.00
13.42 16.19 0.50 495.07 0.03 3.66 67.15 0.38 0.00 0.00 0.00
13.56 16.23 0.48 494.97 0.03 3.60 67.12 0.30 0.00 0.00 0.00
14.95 17.53 0.42 578.82 0.09 3.57 65.72 0.35 0.00 0.00 0.00
13.44 16.07 0.56 581.14 0.04 3.54 67.34 0.40 0.00 0.00 0.00
17.19 21.27 0.37 575.41 0.04 3.44 61.08 0.51 0.00 0.00 0.00
13.57 16.99 0.30 580.64 0.01 3.37 66.69 0.38 0.00 0.00 0.00
13.79 16.25 0.43 495.25 0.04 3.35 67.39 0.39 0.00 0.00 0.00
11.90 14.67 0.30 496.86 0.02 3.31 69.00 0.36 0.00 0.00 0.00
17.13 19.28 0.56 491.83 0.03 3.30 63.26 0.48 0.00 0.00 0.00
14.01 16.17 0.50 495.56 0.01 3.30 67.66 0.39 0.00 0.00 0.00
16.86 20.16 0.57 491.19 0.05 3.20 62.44 0.43 0.00 0.00 0.00
14.94 17.46 0.42 580.05 0.08 3.16 66.24 0.40 0.00 0.00 0.00
14.56 16.94 0.36 494.86 0.08 3.14 66.91 0.42 0.00 0.00 0.00
......
答え4
その後、Veeam ONEをインストールし、パフォーマンスの問題がどこにあるのかをかなり明らかにしました。Veeam ONEのCPUボトルネック画面を見て、応答を停止した仮想マシンのトラブルシューティング: VMM とゲストの CPU 使用率の比較参考までに、私たちは「受け入れられない」主張の多くがどこにあるのかを把握しました。
私が特に共有したい小さなヒントは、あるケースでは VM 上のスナップショットを削除するまで CPU 競合を排除できなかったということです。これが誰かの役に立つことを願っています。