当前位置: 代码迷 >> 综合 >> VMWare vSphere - CPU性能分析与监控之就绪时间(ready time)分析
  详细解决方案

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

热度:76   发布时间:2024-02-07 19:42:16.0

介绍
简单描述,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时间和整体性能的下降。转载至—明辰智航
  相关解决方案