主页 / server / 问题 / 670171
Accepted
Chuck Herrington
Asked: 2015-02-21 06:11:52 +0800 CST

VMware 中有多少争用过多？

  • 772

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

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

我看过这篇 VMware 知识库文章；专门针对 Co-Stop 的定义，其定义为：

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

我正在翻译

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

这个翻译看起来正确吗？

如果是这样，我很难相信我所看到的：包含大多数“慢”虚拟机的主机当前显示的 CPU Co-stop 平均值为127,835.94毫秒！

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

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

virtualization

4 个回答

  1. 您在评论中声明您有一个双四核 ESXi 主机，并且您正在运行一个 8vCPU 虚拟机和十四个4vCPU 虚拟机。

    如果这是我的环境，我会认为这是严重过度配置。我最多会在该硬件上放置四到六个 4vCPU 来宾。（这是假设所讨论的 VM 的负载要求它们具有如此高的 vCPU 计数。）

    我假设您不知道黄金法则……对于 VMware，您永远不应该为 VM 分配比它需要的更多的内核。原因？VMware 使用了某种严格的协同调度，这使得虚拟机很难获得 CPU 时间，除非有与分配的虚拟机一样多的可用内核。这意味着，除非同时打开 4 个物理内核，否则 4vCPU VM 无法执行 1 个工作单元。换句话说，在架构上最好有一个 90% CPU 负载的 1vCPU VM，然后有一个每个内核负载 45% 的 2vCPU VM。

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

    根据您的情况，使用 Veeam 监控来宾的 CPU 使用情况。尽可能多地减少 vCPU 数量。我敢打赌，您几乎可以在所有现有的 4vCPU 来宾上降到 2vCPU。

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

    • 45
  2. Best Answer

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

    我不认为 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 Ready %”。您可以通过选择 VM 并转至Performance> Overview> CPU Graph 从 vSphere 客户端访问它。

    • 低于 5% 的 CPU 就绪- 你很好。
    • 5-10% CPU 就绪- 密切关注活动。
    • 超过 10% 的 CPU 就绪- 不好。

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

    你介意在你的问题虚拟机上检查这个并报告回来吗？

    • 17

  3. 127,835.94 毫秒是一个总和，您需要除以采样时间才能获得正确的 %RDY 值。不过，看起来您现在已经获得了正确的 %RDY 读数。vCPU 与物理 cpu 的比率可以达到很高的水平，但不能按照您的方式进行。

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

    仅供参考 HT 处理器未用于 CPU 使用百分比计算 - 这意味着如果您在服务器上以 2.4 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

......
    • 2

  4. 此后，我们安装了 Veeam ONE，它对我们的性能问题所在有相当多的了解。通过查看 Veeam ONE 中的 CPU 瓶颈屏幕，然后使用对已停止响应的虚拟机进行故障排除：VMM 和来宾 CPU 使用比较作为参考，我们找出了我们的“不可接受”争用的分配位置。

    我想特别分享的一个小技巧是，在一种情况下，我无法消除 CPU 争用，直到我删除了 VM 上的快照。希望这可以帮助某人。

    • 1

相关问题