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

你可能感兴趣的:(虚拟化技术)