VMwareでの競合はどれくらいですか？

しばらくの間、ビジネスに不可欠なシステムのかなりの数が、軽度から極度に及ぶ「遅さ」のレポートを取得している理由を把握しようとしてきました。最近、問題のサーバーがすべてホストされているVMware環境に目を向けました。

最近、SCOM 2012用のVeeam VMware管理パックの試用版をダウンロードしてインストールしましたが、報告されている数字を信じることができません（上司もそうです）。上司にそれが言っている数字が真実だと納得させるために、VMwareクライアント自体を調べて結果を確認し始めました。

このVMware KB記事を見てきました。特に次のように定義されるCo-Stopの定義用

MP仮想マシンを実行する準備はできていたが、vCPUスケジューリングの競合により遅延が発生した時間

私が翻訳しているもの

ゲストOSはホストからの時間を必要としますが、リソースが使用可能になるまで待機する必要があるため、「無応答」と見なすことができます

この翻訳は正しいようですか？

もしそうなら、ここに私が見ているものを信じるのに苦労しているところです：「遅い」VMの大部分を含むホストは現在127,835.94ミリ秒のCPU コストップ平均を示しています！

これは、平均してこのホスト上の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が必要な場合は、より大きなサーバーが必要になる可能性があります。

仮想マシンのサイズを適切に調整してください。私はそれらのほとんどが2つのvCPUで生きることができると確信しています。仮想CPUを追加しても処理速度は向上しません。そのため、パフォーマンスの問題の解決策である場合は、これは間違ったアプローチです。

ほとんどの環境では、RAMは最も制約のあるリソースです。ただし、競合が多すぎるとCPUが問題になる可能性があります。これの証拠があります。また、個々のVMに割り当てられる量が多すぎると、RAMが問題になる可能性があります。

これを監視することは可能です。探しているメトリックは「CPU Ready％」です。あなたは、VMを選択しに行くことによってvSphereクライアントからこれをアクセスすることができますPerformance> Overview> CPUグラフ。

• 5％未満のCPU準備完了 -大丈夫です。
• 5〜10％のCPU準備完了 -アクティビティをよく見てください。
• 10％以上のCPU準備完了 -良くありません。

下のグラフの黄色い線に注意してください。

問題のある仮想マシンでこれを確認し、報告していただけますか？

コメントには、デュアルクアッドコアESXiホストがあり、1つの8vCPU VMと14個の 4vCPU VMを実行していると述べています。

これが私の環境である場合、私はそれがひどく過剰にプロビジョニングされていると考えます。そのハードウェアに最大4〜6個の4vCPUゲストを配置します。（これは、問題のVMに、vCPUカウントが高いことを要求する負荷があると仮定しています。）

私はあなたが黄金のルールを知らないと仮定しています... VMwareでは、VMに必要以上のコアを割り当てるべきではありません。理由？VMwareは、VMが割り当てられている数のコアが使用可能でない限り、VMがCPU時間を取得するのを困難にする、ある程度厳密な同時スケジューリングを使用します。つまり、4vCPU VMは、同時に4つの物理コアが開いていない限り、1作業単位を実行できません。言い換えると、90％のCPU負荷を持つ1vCPU VMを使用し、次にコアあたり45％の負荷を持つ2vCPU VMを使用する方が、アーキテクチャ的に優れています。

したがって...常に最小の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の数が利用可能になるのをVMが待つ必要はもはやないが、それは非常に有害であるということです物理コアに対するマルチ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％で、物理CPU（HTコアを含む）に対する3.5対1のvCPU比率を実行している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の競合を解消できない場合があることです。これが誰かを助けることを願っています。