VMwareでは、どの程度の競合が多すぎますか？
しばらくの間、私は、ビジネスクリティカルなシステムのかなりの数が、軽度から極端な範囲の「低速」のレポートを受け取っている理由を理解しようと努めてきました。問題のすべてのサーバーがホストされているVMware環境に最近目を向けました。
私は最近、SCOM 2012用のVeeam VMware管理パックのトライアルをダウンロードしてインストールしましたが、報告している数値をうまく伝えることができません（上司もそうです）。上司に私が伝えている数字が正しいことを納得させるために、VMwareクライアント自体を調べて結果を確認し始めました。
これまで見てきました このVMware KB記事 ;具体的には、次のように定義されるCo-Stopの定義用。
A MP仮想マシンは実行の準備ができていたが、co-vCPUスケジューリングの競合により遅延が発生した時間
私はこれを翻訳しています
ゲストOSはホストからの時間を必要としますが、リソースが利用可能になるまで待機する必要があるため、「応答しない」と見なすことができます
この翻訳は正しいように見えますか？
もしそうなら、ここに私が見ているものを信じるのに苦労するところがあります：「遅い」VMの大部分を含むホストは現在、のCPUコストップ平均を示しています127,835.94ミリ秒！
これは、このホスト上のVMが平均してCPU時間を2分以上待たなければならないことを意味しますか？
このホストには2つの4コアCPUがあり、1x8 CPUゲストと14x4 CPUゲストがあります
この分野での経験のいくつかを説明できます...
VMwareがベストプラクティスについて顧客（または管理者）を教育するのに十分な仕事をしておらず、製品の進化に伴って以前のベストプラクティスを更新していないと思います。この質問は、vCPU割り当てなどのコアコンセプトが完全に理解されていない例です。最善の方法は、VMがさらに必要であると判断するまで、単一のvCPUで小規模から開始することです。
OPの場合、ESXiホストサーバーには2つのクアッドコアCPUがあり、8つの物理コアが生成されます。
説明されている仮想マシンのレイアウトは、合計15人のゲストです。 1 x 8 vCPUおよび14 x 4 vCPUシステム。特に、8つのvCPUを備えた単一のゲストが存在する場合、これは過度にコミットされすぎます。意味がない。 VMそれだけの大きさが必要な場合は、おそらくより大きなサーバーが必要です。
仮想マシンをright-sizeしてみてください。私はそれらのほとんどが2つのvCPUで動作できると確信しています。仮想CPUを追加しても処理速度は速くならないため、それがパフォーマンスの問題の解決策である場合、それは間違ったアプローチです。
ほとんどの環境では、RAMが最も制約されたリソースです。ただし、競合が多すぎるとCPUが問題になる可能性があります。これの証拠があります。RAM 個々のVMに割り当てられている数が多すぎる の場合は問題になります。
これを監視することは可能です。探している指標は「CPU Ready％」です。 VMを選択し、Performance> Overview> CPU Graphに移動することで、vSphereクライアントからこれにアクセスできます。
- 5％CPU Ready未満-大丈夫です。
- 5-10％CPU Ready-アクティビティを注意深く観察します。
- 10％以上のCPU Ready-良くない。
下のグラフの黄色の線に注意してください。
問題のある仮想マシンでこれを確認し、レポートを返していただけませんか？
デュアルクアッドコアESXiホストがあり、1つの8vCPU VMを実行しており、コメントfourteen = 4vCPU VM。
これが私の環境であれば、それはグロスリー過剰プロビジョニングされていると考えます。そのハードウェアに最大4〜6個の4vCPUゲストを配置しました。 （これは、問題のVMに、vCPUカウントの高い数を必要とする負荷があることを前提としています。）
私はあなたが黄金律を知らないと仮定している... VMwareではVM必要以上のコアを割り当てるべきではない。理由？VMwareはそれを作る幾分厳密な共同スケジューリングを使用するVMが割り当てられているコアと同じ数のコアが使用できない場合を除き、VMがCPU時間を取得するのは困難です。つまり、4vCPU VMは、同時に4つの物理コアが開いています。言い換えると、1vCPU VM 90％CPU負荷の場合、2vCPU VMコアあたり45％の負荷。
したがって、常に最低限のvCPUでVMを作成し、必要であると判断された場合にのみそれらを追加します。
状況に応じて、Veeamを使用してゲストのCPU使用率を監視します。できるだけ多くのvCPU数を減らします。既存の4vCPUゲストのほとんどすべてで2vCPUにドロップできると私は喜んで賭けます。
確かに、これらすべてのVMに実際にCPU負荷があり、vCPU数が必要な場合は、追加のハードウェアを購入するだけで済みます。
127,835.94ミリ秒は合計であり、正しい％RDY値を取得するには、サンプル時間で除算する必要があります。すでに正しい％RDY読み取り値を既に取得しているようです。 vCPUと物理CPUの比率でかなり高くなる可能性がありますが、その方法は異なります。
クワッドvCPU VMが多すぎて、8 vCPU VMさえあります。適切なサイズ設定と、より少ないvCPUにサイクルを統合しないことによる影響については、すでに説明している品質応答があります。私が明確にしたいことの1つは、もはやそうではありませんが、VMは、vCPUの数に等しい物理CPUの数が利用可能になるまで待機する必要があることです。命令を処理できるため、マルチvCPU VMと物理コアの比率でこの大きさを過剰にプロビジョニングすることは非常に有害です。8コアの64 vCPUは、最大の4：1の比率をはるかに超えています。これらのプロセッサで16の論理コアを使用している場合、負荷が軽い1および2のvCPU VMでは問題ないかもしれませんが、VMに重い負荷がある場合、達成するのは困難です。
FYI HTプロセッサはCPU使用率の計算では使用されません。つまり、サーバー上で2.4 GHzで実行されている32個の論理コアがある場合、38.4 GHzに到達すると100％使用されます。したがって、負荷平均が1.0を超えることがわかると、それが理由です。
これは、vCPU対物理CPU（HTコアを含む）の比率が3.5から1で、平均％RDYが3％の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
......
それ以来、Veeam ONEをインストールしました。これにより、パフォーマンスの問題がどこにあるのかがかなりわかります。 Veeam ONEのCPUボトルネック画面を確認し、次に 応答を停止した仮想マシンのトラブルシューティング：VMMとゲストのCPU使用率の比較 を参照として使用して、「許容できない」競合が発生する場所を特定しましたです。
特に共有したかった小さなヒントの1つは、VMにあるスナップショットを削除するまで、CPUの競合を解消できなかったことです。これが誰かを助けることを願っています。