服务器 Gind.cn
  1. 服务器 Gind.cn
  3. VMware有多less争用？
Intereting Posts
windws server 2008 udp组播性能问题 未findActive Directory集成的DNS区域_msdcs.COMPANY.LOCAL Linux工具find重复的文件？ 在Windows Server 2003 R2中做计划任务重叠？ search计划任务（WIN2K3） 如何从SCSI控制器获取硬盘参数 nginx：try_files找不到静态文件，回退到PHP 什么时候值得DBA？ 引导加载程序用sshreplace 单个IP，多个SSL Certs，不使用通配符，IIS 7上的TLS可能？ 共享点错误消息“某些文件可能会损害您的计算机” 如何通过IMAP（通过telnet）访问共享的Exchange邮箱？ PowerShell使用正则expression式删除文件 错误：iptables：没有链/目标/匹配的名称 应用程序从networkingpath启动非常缓慢

VMware有多less争用？

一段时间以来，我一直在试图弄清楚为什么我们的一些关键业务系统正在获得从缓慢到极端的“缓慢”报告。 我最近把我的注意力转向所有服务器托pipe的VMware环境。

我最近下载并安装了适用于SCOM 2012的Veeam VMwarepipe理包的试用版，但是我正在向我报告的数字（我的老板也是如此）难以承受。 为了试图说服我的老板，告诉我的数字是真实的，我开始研究VMware客户端来validation结果。

我已经看过这个VMware知识库文章 ; 专门用于定义为“停止”的定义：

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

我正在翻译

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

这个翻译是否正确？

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

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

这个主机有两个4核CPU，它有1×8的CPU来宾和14×4的CPU来宾。

我可以描述一些我在这方面的经验

我不相信VMware能够为客户（ 或pipe理员 ）提供最佳实践方面的教育，而且他们也不会在产品发展的过程中更新以前的最佳实践。 这个问题是一个如何像vCPU分配的核心概念没有完全理解的例子。 最好的办法是从一个单独的vCPU开始，直到你确定虚拟机需要更多。

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

所描述的虚拟机布局总共有15个来宾; 1个8个vCPU和14个4个vCPU系统。 这太过分了，特别是有8个vCPU的guest虚拟机的存在。 这个不成立。 如果你需要一个很大的虚拟机，你可能需要一个更大的服务器。

请尝试正确调整虚拟机的大小 。 我很确定他们中的大多数人可以用2个vCPU。 添加虚拟CPU不会让事情运行得更快，所以如果这是对性能问题的补救措施，那是错误的做法。

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

可以监视这个。 您正在查找的指标是“CPU Ready％”。 您可以通过select一个虚拟机并转到Performance > Overview > CPU图表从vSphere客户端访问。

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

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

您是否介意在有问题的虚拟机上进行检查并报告回来？

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

如果这是我的环境，我会认为这是严重过度configuration。 在那个硬件上我最多会给4到6个4vCPU的客人。 （这是假定有问题的虚拟机有负载，需要他们拥有那么高的vCPU数量。）

我假设你不知道黄金法则…与VMware你不应该分配一个虚拟机多于所需的内核。 原因？ VMware使用了一些比较严格的共同调度，这使得虚拟机很难获得CPU时间，除非虚拟机分配的核心数量尽可能多。 这意味着一个4vCPU虚拟机不能执行1个工作单元，除非有4个物理内核在同一时间打开。 换句话说，拥有90％CPU负载的1vCPU虚拟机在架构上会更好，然后拥有每个核心具有45％负载的2vCPU虚拟机。

所以…总是用最less的vCPU创build虚拟机，只有在确定需要的时候才添加虚拟机。

根据您的情况，使用Veeam来监控您的客人的CPU使用情况。 尽可能减lessvCPU数量。 我敢打赌，你可以下降到2vCPU几乎所有你现有的4vCPU的客人。

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

127,835.94毫秒是总和，您需要除以采样时间以获得正确的％RDY值。 看起来你现在已经获得了正确的％RDY读数。 你可以用vCPU和物理cpu的比例来达到相当高的水平，但是你不能这样做。

你有太多的四个vCPU虚拟机，甚至一个8个vCPU的虚拟机。 有一些质量响应已经讨论了正确的大小和一些不把循环合并到较less的vCPU的影响。 我想澄清的一件事情是，虽然在处理任何指令之前，VM不再需要等待等于其vCPU数量的物理CPU数量变为可用，但这是非常有害的通过多vCPU VM与物理核心的比例来超量供应这种量级。 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 ......

我们已经安装了Veeam ONE，这已经在我们的性能问题上有了很大的改观。 通过查看Veeam ONE中的CPU Bottlenecks屏幕，然后使用对已停止响应的虚拟机进行故障排除：将VMM和来宾CPU使用率比较作为参考，我们已经计算出我们的“不可接受”争用的分配位置。

我想特别分享的一个小技巧是，在我删除VM上的快照之前，我无法消除CPU争用。 希望这有助于某人。