介绍
简单描述，CPU就绪时间参数(ready time)是虚拟机想要运行，但无法获取CPU资源的总等待时间(准确讲，为虚拟机能够调度到物理CPU运行之前，处于read-to-run状态的总时间)。它是是虚拟化环境下，分析虚拟系统性能的重要性能参数。本文重点介绍通过esxtop分析和定位和此参数相关的CPU性能问题。
如何获取就绪时间参数
可以通过esxtop和vCenter获取此参数，但两种方式获取参数形式不同。esxtop以百分比的形式显示此参数，如5%意味着VM在采样间隔内花费了%5的时间来等待获取CPU资源。vCenter用具体的时间来度量此参数，其采样间隔为20,000ms。此意味着，vCenter1,000ms的就绪时间，在esxtop中显示为5%。对于该参数的详细介绍，可参考 ESX3 Ready Time.pdf。
在交互模式下，使用esxtop来查询VM的CPU信息，你可以看到%RDY的相关参数。
esxtop有个使用技巧，在CPU显示界面下，按r键，可以按照%RDY值由大到小进行排序，可以快速查找就绪时间异常的VM。
如何解析ready时间参数
一个最参见的问题就是，对于就绪时间，什么情况下可能导致问题。然而，此问题并不容易回答，本文提供一些关于可接受参数范围的指导。Ready时间参数不应该作为系统性能的最终测量参数，而用户体验和延时才是应该考虑的因素。在某些情况下，ready时间参数为0，但是用户的体验确非常的糟糕。例如，此类问题可能是由于存储阵列的不当配置导致的。偶尔，我们可能也会遇到过度整合的宿主机，ready值很高，但却能满足用户的需求。因此，关于ready参数，没有一个绝对的参考值。
需要注意的是，ready时间值是针对每个vCPU的。esxtop显示的每个VM的ready参数值，是将其所有vCPU参数值的累加。如果某VM配置为2个vCPU，如果其每个vCPU的ready值为5%，那么此VM级的参数值为10%。
我们可以将ready参数值划分为下列几种情况：
1. %RDY == 0: 这种情况不会发生。由于客户机操作系统与真实硬件之间的虚拟化层VMM的存在，任何操作情况下，此值都不可能为0. 但是一个健康的系统，这个值非常小，以至于终端用户感知不到他们的业务是在虚拟化环境下运行的。
2. 0 < %RDY <= 5%: 这个是ready值的正常区间。非常小ready值意味着对用户体验非常小。如果系统存在性能问题，并且ready值在此区间，应为其它问题导致。
3. 5% < %RDY <= 10%: ready值进入此区间，就非常值得你去关注了。大多数系统功能在此区间内可以正常工作。
4. %RDY > 10% : 尽管有些系统能够继续满足性能期望，但此时多数情况下需要你采取些措施来解决性能问题。
原因及处理措施
通常有两类问题导致过高的ready值：
主机负载过高
最常见的原因就是在硬件能力不足的情况下，试图进行高负荷的工作。为了便于理解，举一个仅有一个物理CPU的系统。如果有两个满负载运转单vCPU的VM在此系统上运行，每一个都想获得整个CPU的资源；但由于仅有有个CPU供调度运行，ESXi在调度VM时，采用平均分配的方式，那么每个VM仅能获得50%的物理CPU资源。结果，每个VM都要花费50%时间来等待CPU资源。因此，在esxtop中看到的ready时间值为50%（为简单考虑，此处没有考虑ESXi本身运行对CPU资源的消耗）。
这种情况非常容易观察到，这时ready时间和主机CPU利用率都非常高。解决这种问题的唯一办法就是降低系统的负载。VM迁移出高负载的主机或增加主机的CPU资源。
SMP的过度使用
ESX 2.5版本中，SMP客户机要求在同一时刻进行协同调度(co-schedule)。对于有两个vCPU的客户机，在准备就绪执行时，仅有一个物理核(physical core)可供使用；此时，客户机不能被调度直到能获取第二个核。这无疑增加了ready时间。在ESX 3.0及后续版本中，尽管引入了松散的协同调度方式，即虚拟机的部分vCPU可以先于其它的vCPU调度执行。但是，客户机仍然要求某种程度的协同调度。因此松散调度不是绝对的。简而言之，增加客户机的vCPU的个数，会增加调度器的负荷；并且协同调度会导致ready时间的增加。因此，VMware官方建议仅给客户机配置必要的vCPU，避免协同调度带来的过高的ready时间和整体性能的下降。转载至—明辰智航
来源：oschina
链接：https://my.oschina.net/u/4271891/blog/4478845