VMWare vSphere - CPU性能分析与监控之就绪时间(ready time)分析

介绍

简单描述，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 

 3:22:44pm up 32 days  6:17, 326 worlds; CPU load average: 0.31, 0.29, 0.29
PCPU USED(%):  12.2  11.6  24.1  24.8  35.8  34.4  37.7  33.6 AVG:  26.8
PCPU UTIL(%):  20.4  19.6  38.6  39.5  59.0  56.9  61.9  55.8 AVG:  43.9

     ID    GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
   1218   1218 VMA                 3    2.81    4.47    0.03  299.29    0.49   96.54    0.09    0.00    0.00    0.00 
   1331   1331 VMB                 3    1.92    3.03    0.00  300.00    1.11   97.40    0.20    0.00    0.00    0.00 

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时间和整体性能的下降。