VMware中有多少争用太多？

一段时间以来，我一直在试图弄清楚为什么我们的许多业务关键型系统都收到了从缓慢到极端的“缓慢”报告。我最近把目光投向了托管所有相关服务器的VMware环境。

我最近下载并安装了SCOM 2012的Veeam VMware管理包的试用版，但是我很难确定（我的老板也是如此）它向我报告的数字。为了试图说服老板，我告诉我的数字是真实的，我开始调查VMware客户端本身以验证结果。

我看了这篇VMware KB文章；专门用于Co-Stop的定义，其定义为：

MP虚拟机准备运行的时间，但是由于co-vCPU调度争用而导致延迟

我要翻译成的

来宾操作系统需要主机时间，但是必须等待资源可用，因此可以被视为“无响应”

这个翻译看起来正确吗？

如果是这样，这就是我很难理解的地方：包含大多数“慢速” VM的主机当前显示的CPU Co-stop平均为127,835.94毫秒！

这是否意味着该主机上的VM平均需要等待2分钟以上的CPU时间？

该主机上确实有两个4核CPU，并且它具有1x8 CPU来宾和14x4 CPU来宾。

我可以描述一下我在这方面的经历...

我认为VMware不能充分地教育客户（或管理员）最佳实践，也不会随着产品的发展而更新以前的最佳实践。这个问题是一个示例，说明如何不完全了解vCPU分配等核心概念。最好的方法是从单个vCPU开始，从小规模开始，直到确定VM需要更多虚拟机为止。

对于OP，ESXi主机服务器具有两个四核CPU，产生8个物理核。

所描述的虚拟机布局总共有15位访客。1 x 8 vCPU和14 x 4 vCPU系统。这太过分了，特别是在存在具有8个vCPU的单个来宾的情况下。这没有道理。如果需要这么大的虚拟机，则可能需要更大的服务器。

请尝试调整虚拟机的大小。我敢肯定他们中的大多数人都可以使用2个vCPU。添加虚拟CPU不会使事情运行得更快，因此，如果这是对性能问题的一种补救措施，那是错误的方法。

在大多数环境中，RAM是最受限制的资源。但是如果争用过多，CPU可能会成为问题。您有证据。如果将过多的内存分配给各个VM，则RAM也可能成为问题。

有可能对此进行监视。您要查找的指标是“ CPU就绪百分比”。您可以从vSphere客户端选择一个虚拟机，要访问此Performance> Overview> CPU图形。

• 在5％的CPU就绪下 -很好。
• 5-10％CPU就绪 -密切关注活动。
• 超过10％的CPU就绪 -不好。

请注意下图中的黄线。

您介意在有问题的虚拟机上检查一下并报告吗？

您可以在注释中说明您有一个双四核ESXi主机，并且正在运行一个8vCPU VM和十四个 4vCPU VM。

如果这是我的环境，我认为这将严重超支。我最多在该硬件上放置4到6个4vCPU来宾。（这是假设所讨论的VM的负载要求它们具有很高的vCPU数量。）

我假设您不了解黄金法则...对于VMware，您永远不应为VM分配过多的内核。原因？VMware使用某种程度严格的协同调度，这使得VM很难获得CPU时间，除非分配的VM可用的内核数量一样多。这意味着，除非同时打开4个物理核心，否则4vCPU VM不能执行1个工作单元。换句话说，在架构上，拥有1vCPU VM的CPU负载为90％，然后拥有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的后果。我确实想澄清的一件事是，尽管不再需要VM在等待任何指令被处理之前必须等待等于其vCPU数量的物理CPU数量可用，但这是非常有害的通过多vCPU VM与物理内核的比率来实现这种规模的超额配置。8个内核上的64个vCPU远远超出了最大4：1的比例。我假设您在这些处理器上具有HT，所以您有16个逻辑核心？对于1台和2台vCPU VM负载较小，这可能是可以的，但是如果您在VM上负载较重，则很难完成。

仅供参考。HT处理器未在CPU使用百分比计算中使用-这意味着，如果您在服务器上以32 GHz的速度运行32个逻辑核，则当您达到38.4 GHz时，您的利用率为100％。因此，当您看到平均负载大于1.0时，这就是原因。

这是运行3.5到1个vCPU与物理CPU（包括HT内核）的ESXi主机，平均％RDY为3％。

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使用情况比较作为参考，我们已经确定了“不可接受的”争用的分配位置。

我想特别分享的一个小技巧是，在一种情况下，直到删除虚拟机上的快照，我才能消除CPU争用。希望这对某人有帮助。