☰

在 VMware 中多少争用才算过多？

tag-icon • tag-icon virtualization memory vmware-vsphere
在 VMware 中多少争用才算过多？

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

我最近下载并安装了 Veeam VMware 管理包 SCOM 2012 的试用版，但我（和我的老板）都很难相信它向我报告的数字。为了说服我的老板它告诉我的数字是真实的，我开始研究 VMware 客户端本身以验证结果。

我看过此 VMware 知识库文章；具体来说，Co-Stop 的定义如下：

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

我正在翻译

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

这个翻译看起来正确吗？

如果是这样，那么我很难相信我所看到的情况：包含大多数“慢速”虚拟机的主机当前显示 CPU 同步停止平均值为127,835.94毫秒！

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

该主机上有两个 4 核 CPU，并且有 1x8 CPU 客户机和 14x4 CPU 客户机。

答案1

我可以描述我在这个领域的一些经历......

我不认为 VMware 在客户教育方面做得足够好（或管理员) 的最佳实践，他们也没有随着产品的发展更新以前的最佳实践。这个问题就是一个核心概念（如 vCPU 分配）尚未完全被理解的例子。最好的方法是从单个 vCPU 开始，直到确定 VM 需要更多 vCPU。

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

描述的虚拟机布局是总共 15 个客户机；1 x 8 vCPU 和 14 x 4 vCPU 系统。这太过分了，尤其是在存在具有 8 个 vCPU 的单客户机。这毫无意义。如果你需要这么大的虚拟机，那么你可能需要更大的服务器。

请尝试合适的尺码您的虚拟机。我确信大多数虚拟机都可以使用 2 个 vCPU。添加虚拟 CPU 并不能加快运行速度，因此如果这是解决性能问题的一种方法，那么这种方法是错误的。

在大多数环境中，RAM 是最受限制的资源。但如果争用过多，CPU 可能会成为问题。你有证据证明这一点。如果分配给单个虚拟机的资源过多。

可以监控这一点。您要查找的指标是“CPU 就绪百分比”。您可以从 vSphere 客户端访问它，方法是选择虚拟机并转到Performance> Overview> CPU 图表。

  • CPU 就绪率低于 5%- 你没事。
  • 5-10% CPU 就绪- 密切观察活动。
  • CPU 就绪率超过 10%- 不好。

请注意下图中的黄线。 在此处输入图片描述

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

答案2

您在评论中指出，您有一个双四核 ESXi 主机，并且正在运行一个 8vCPU VM，并且十四4vCPU 虚拟机。

如果这是我的环境，我会认为这是严重地过度配置。我最多会在该硬件上放置四到六个 4vCPU 客户机。（这是假设相关虚拟机的负载需要它们具有如此高的 vCPU 数量。）

我猜你不知道黄金法则……使用 VMware 时，你永远不应该为虚拟机分配超过其需要的内核。原因是什么？VMware 使用相当严格的协同调度，除非有与虚拟机分配的内核一样多的内核，否则虚拟机很难获得 CPU 时间。这意味着，除非同时有 4 个物理内核打开，否则 4vCPU 虚拟机无法执行 1 个工作单元。换句话说，从架构上讲，最好有一个 CPU 负载为 90% 的 1vCPU 虚拟机，而不是有一个每个内核负载为 45% 的 2vCPU 虚拟机。

所以...始终创建具有最少 vCPU 的虚拟机，并且仅在确定必要时添加它们。

对于您的情况，请使用 Veeam 监控客户机上的 CPU 使用情况。尽可能减少 vCPU 数量。我敢打赌，您可以将几乎所有现有的 4vCPU 客户机上的 vCPU 数量降至 2vCPU。

当然，如果所有这些虚拟机实际上都具有 CPU 负载以要求它们具有的 vCPU 数量，那么您只需购买额外的硬件。

答案3

127,835.94 毫秒是一个总和，您需要除以采样时间才能获得正确的 %RDY 值。不过，现在您似乎已经获得了正确的 %RDY 读数。您可以将 vCPU 与物理 CPU 的比率调高到相当高，但不能按照您现在的方式。

您有太多四 vCPU 虚拟机，甚至 8 vCPU 虚拟机。已经有一些高质量的回复讨论了正确大小以及不将周期整合到较少 vCPU 上的一些后果。我确实想澄清的一件事是，虽然虚拟机不再必须等待等于其 vCPU 数量的物理 CPU 可用后才能处理任何指令，但对于多 vCPU 虚拟机与物理核心的比例，这种程度的过度配置是非常有害的。8 个核心上的 64 个 vCPU 远远超出了 4:1 的最大比例。我假设您在这些处理器上有 HT，所以您有 16 个逻辑核心？对于负载较轻的 1 和 2 vCPU 虚拟机来说，这可能没问题，但如果虚拟机负载很重，就很难实现。

仅供参考：HT 处理器未用于计算 CPU 使用率 - 这意味着如果您的服务器上有 32 个逻辑核心以 2.4 Ghz 运行，则当您达到 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

......

答案4

此后，我们安装了 Veeam ONE，它在很大程度上揭示了我们的性能问题所在。通过查看 Veeam ONE 中的 CPU 瓶颈屏幕，然后使用对已停止响应的虚拟机进行故障排除：VMM 和客户机 CPU 使用率比较作为参考，我们已经弄清楚了我们的“不可接受”的论点在哪里。

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

相关内容