避免VMware平台ESXi主机CPU使用率的“坑”

字数 4411阅读 21854评论 5赞 17

前言
在实际运维中经常会遇到这样的情况，VMWARE虚拟化平台ESXi主机物理CPU及内存使用率较低，但是还是有用户感觉慢，虚拟化平台通过client看到的ESXi主机CPU的使用率的参考价值有多大，或者说那些具体的值才有参考意义，本文将带着你绕过哪些ESXi主机CPU利用的“坑”，让你真正了解虚拟化平台的CPU是否存在瓶颈，平台性能是否良好，请记住，有时候眼见不一定为实。
    说到CPU的利用率不得不考虑一个CPU Ready这个参数，这个参数估计误导过很多虚拟化管理员，言归正传，开始正文。CPU Ready”这个参数有点歧义，大家很容易理解为“CPU Ready”是指有多少空闲的CPU可以使用，“CPU Ready”越多越好。然而，事实完全相反，越多的“CPU Ready”，你的虚拟化平台性能越差。
CPU Ready的值指的是虚拟机就绪但无法获得物理 CPU 调度的时间百分比。CPU Ready的值越大，说明越多的虚拟机（或应用）要去运行但是没有可用的CPU资源去运行，这些虚拟机（或应用）只能等待CPU资源。
1.造成CPU Ready高的原因有哪些？
造成CPU使用率高的原因相对容易好找点，但是造成CPU Ready的原因确让人难以琢磨。
事实上，造成CPU Ready高的原因主要有两个，一个是CPU超额分配严重，另外一个是设置了CPU限制。
CPU超额分配
造成CPUReady最主要的原因是在物理CPU上面运行的过多活跃的虚拟CPU(vCPU)，一般情况向下，分配比pCPU更多的vCPU是非常正常和安全的，但是如果这个比率过高，ESXi调度程序在不影响性能的情况下执行其任务的难度就越大。vCPU/pCPU这个比率为多少的时候，CPU性能会达到最好，目前没有一个放之四海而皆准的规则，但是有一些指导参数可以参考：
![4oebqfig3dd](/home/attachment/201812/06/336597_154405561355028.jpg)

CPU限制
除非在某些特定的场景使用CPU限制，一般情况下不要设置CPU限制。如果在虚拟机资源设置中设置了 CPU 限制，则当虚拟机用尽其分配的 CPU 资源时，系统会有意保留该虚拟机，而防止其调度给 PCPU。无论 CPU 利用率如何，都会发生此问题。在esxtop命令的输出中，有一个参数为%MLMTD，这表示虚拟机准备执行但由于 VMkernel 有意约束而尚未调度 CPU 时间的时间量。因为如果运行的话，会违反资源池、虚拟机或环境的限制设置。这句话是不是有点绕，其实就是说如果设置了CPU限制，那么即使物理CPU处于空闲状态，也不会把资源分配给做了限制的虚拟机。默认进行虚拟机资源限制的级别比较高，所以即使有资源空闲，也不会违反限制规则。正常情况下%MLMTD的值应该为0.000%。大多数情况下，不必指定限制。如果指定限制，则可能浪费空闲资源。下图就是在虚拟机上设置资源限制的方式。
![r2x9s8pv6e](/home/attachment/201812/06/336597_154405564710532.jpg)

CPU亲和力
CPU亲和力的目的是删除一些VMkernel上的调度灵活性，可以避免该线程在不同物理cpu之间切换带来的缓存失效，提高缓存命中率，也就提高了虚拟机的性能。但是在虚拟机上设置CPU亲和力永远不会提高该虚拟机的CPU性能。CPU亲和力的另一个问题是禁用vMotion， CPU亲和力是在ESXi服务器中指定特定的内核用于虚拟机。因为这些物理内核不能在CPU亲和力主机之间移动，也不能移动必须运行在这些内核上的虚拟机。这在分布式资源调度（DRS）群集中具有很大的影响。
FaultTolerance
FT通过创建和维护与此类虚拟机相同且可在发生故障切换时随时替换此类虚拟机的其他虚拟机，来确保此类虚拟机的连续可用性。受保护的虚拟机称为主虚拟机。重复虚拟机，即辅助虚拟机，在其他主机上创建和运行。主虚拟机会持续复制到辅助虚拟机，以便辅助虚拟机可以随时接管工作，从而提供 Fault Tolerant 保护。主虚拟机和辅助虚拟机会持续监控彼此的状态以确保维护Fault Tolerance。如果运行主虚拟机的主机发生故障，系统将会执行透明故障切换，此时会立即启用辅助虚拟机以替换主虚拟机，启动新的辅助虚拟机，并自动重新建Fault Tolerance 冗余。如果运行辅助虚拟机的主机发生故障，则该主机也会立即被替换。在任一情况下，用户都不会遭遇服务中断和数据丢失的情况。
如果FT两个虚拟机之间的网络有问题，不能时时同步两个虚拟机之间的信息，这时CPU性能将会下降，以保持两个虚拟机之间的同步。最好的做法是在两个虚拟机之间使用专用的，高带宽的网络。他们之间的网络类似于oracle rac之间的心跳，心跳网络尤其重要，心跳网络有问题，直接影响性能。
2.常见的CPU Ready 误解
有几个常见的对CPUReady 误解，其中一个是超线程对性能的影响。ESXi调度程序将启用超线程的CPU视为一个完整的核心，然而超线程核心不能提供100％的性能。一般情况下启用超线程的CPU只能提供真实物理CPU 75%的性能。在启用超线程的CPU上计算超额比需要保守点，不能按照100%去计算。在进行虚拟化平台资源规划的时候也要注意这一点。
第二个就是有很多可用的CPUMHz 或者 GHz不一定说明你的平台不存在CPU Ready的问题。
CPU活动使用量不能覆盖在一定时间内具体有多少内核被虚拟机使用或者阻止其他虚拟机使用，同样地，一个虚拟机CPU使用情况和CPU Ready的值不一定是正确的。虚拟机可能有很严重的CPU Ready，但是CPU使用率确实不高，所以为了对CPU的具体情况有更正确的了解，需要从全局关注所有CPU的使用以及CPU Ready。
还有一个问题是启用DRS能否减少CPUReady？事实上，DRS不能减少CPU Ready，原因是DRS不考虑CPU调度。DRS只监控CPU和内存的使用情况来决定是否需要进行迁移，不考虑vCPU对pCPU的争用情况。
3.怎么查看CPU Ready的值？
查看环境中有多少CPUReady很简单，在vsphereclient 选择要查看的主机，选择性能，然后再图表选项中选择就绪，就可以看出目前CPU Ready的值。
![lpkr5er8lca](/home/attachment/201812/06/336597_154405567838981.jpg)

但是，从上图可以看出CPU Ready的实际值，这个值是所有虚拟机上的所有vCPU的总和，不同的主机不同的环境很难确认出具体值为多少才能判断目前环境CPU Ready是否有问题，不同的平台或许这个值差别较大，但是具体哪个平台性能最优，很难判断。所以这个在client看到的值基本无意义。
使用esxtop根据输出里面的%RDY的值能够更好地判断CPUReady。然而，还需要考虑每个虚拟机分配的vCPU个数，下一章节会详细讲这些值得具体意义。
4.CPU Ready的值为多少才正常？
我们非常容易能看到CPU的使用情况，但是根据CPU Ready很难看出平台的CPU使用情况是正常还是异常。
VMWARE以前的版本官方建议每个vCPU的CPU Ready的值低于5%，最新的版本官方的说法是只要 CPU 就绪的时间大于 10%，就应该检查主机是否过载，或者虚拟机是否真的需要分配的所有资源。
![4pxc39n1l2k](/home/attachment/201812/06/336597_154405569371437.jpg)

如上图所示，这里需要注意的是，client端看到的值为每各20s的数据，CPU Ready计量单位为ms，计算CPU Ready的方法是将某一时刻得到的值除以于20s，上图某一时刻看到CPU Ready的值为5876，其实这是20s之内的数据，使用 5876/20000=0.29也就是29%，这个值是参考值5%的6倍，10%的将近三倍。但此时物理机CPU使用率仅为7% 。表面上看物理CPU处于正常状态，但是此时平台的CPU已存在非常严重的问题。
再详细说一点，client客户端看到的性能图标中默认的时间间隔如下：
实时：20 秒
过去一天：5 分钟（300 秒）
过去一周：30 分钟（1800秒）
过去一个月：2 小时（7200秒）
过去一年：1 天（86400秒）
计算CPU Ready百分比
要根据 CPUReady总量值计算 CPUReady百分比，请使用以下公式：
（CPU 总量值 /（<以秒为单位的图表默认更新间隔> * 1000））*100 = CPU Ready百分比
例如：
vCenter 中虚拟机的实时统计信息可能具有 1000 的平均 CPUReady总量值。使用相应的值按照公式求出 CPU Ready百分比。
（1000/（20 秒 *1000））*100 = 5% CPU Ready
计算CPU 就绪总量值
要将 CPUReady百分比转换为 CPUReady总量值，请使用以下公式进行反向计算：
（CPU 就绪百分比 /100）*<图表默认更新间隔>* 1000 = CPU 总量值
例如：如果虚拟机的 CPUReady百分比为 5，则其在实时性能图表上的 CPU Ready总量值按如下计算：
(5 / 100) * 20 秒 * 1000 = 1000 CPU Ready
5.解决CPU Ready的方式有哪些？
a.在每台主机上部署合理的虚拟机数量
b.确保pCPU没有被vCPU过多的超额分配。如果CPU确实被超额分配，那就要根据实际情况增加物理机。
c.不要使用CPU限制，CPU限制仅仅适用于在短期的测试或者进行问题分析的时候
d.不要使用CPU亲和力规则，CPU亲和力也仅仅适用于在短期的测试或者进行问题分析的时候
e.采用Fault Tolerance (FT)的时候一定要使用最佳配置，尤其是网络方面
f.要确认DRS做什么不做什么 DRS不能减少CPUReady
6.总结
在虚拟化平台维护的过程中，不要轻易相信任何一个参数，尤其是client看到的CPU利用率的大“坑”，否则你就可能已经入“坑”，有可能会坑的很惨。再次强调眼见不一定为实，不要轻易下结论，要结合多个参数一起判断，才能对平台的性能有深入的了解，最后祝大家好运，都不会入“坑”。
声明：本文是结合作者自己的理解所创作，具体环境应具体讨论，本文仅作参考，封面图片来源网络，侵权删。

VMware

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！