4. CPU性能问题诊断实战

CPU性能问题在虚拟化环境里往往不是“CPU不够快”这么简单。虚拟机看到的vCPU是物理核心的调度份额，中间隔着ESXi的CPU调度器、就绪队列、NUMA拓扑和资源池限制。同一台宿主机上，可能出现A虚拟机CPU使用率只有30%却卡顿，B虚拟机跑满100%却流畅的情况——差别就在就绪时间、争用和NUMA本地性这些“看不见”的指标上。本节围绕三类典型问题展开：CPU就绪时间高、CPU争用严重、NUMA跨节点访问，并给出esxtop、vCenter性能图表、vRealize Operations三件工具的组合诊断路径。

先理解三个核心指标的含义

CPU就绪时间（%RDY）表示虚拟机已就绪、等待物理CPU调度的时间占比。它反映的是“虚拟机想跑但排不上队”。经验阈值：单vCPU虚拟机持续超过5%、多vCPU虚拟机持续超过10%就值得关注；若达到20%以上，通常已能感知到明显卡顿。注意%RDY是相对单个vCPU的百分比，多vCPU虚拟机的%RDY会被放大，需要结合vCPU数量判断。

CPU争用（%CSTP，Co-Stop）只对多vCPU虚拟机有意义，表示虚拟机内某个vCPU已就绪、但因同一虚拟机的其他vCPU未同时被调度而被迫等待的时间。%CSTP高说明vCPU之间“步调不一致”，常见于vCPU数量超过物理核心可同时调度的场景。

NUMA跨节点访问不直接体现在%RDY上，而是通过内存访问延迟影响性能。当虚拟机的vCPU和内存被分散到不同NUMA节点，跨节点访问内存的延迟可能是本地访问的1.5～2倍。esxtop的NUMA相关字段和vRealize Operations的NUMA本地性指标可以暴露这一问题。

用esxtop定位就绪时间高

esxtop是ESXi主机上最直接的实时诊断工具。SSH登录主机后执行esxtop，按c切换到CPU视图，按f打开字段选择，确保%RDY、%CSTP、%MLMTD、NUMA相关字段已显示。按V可以切换到虚拟机视图，只关注目标虚拟机。

观察时不要只看瞬时值，建议连续观察30～60秒。如果某虚拟机的%RDY持续在15%以上，同时宿主机物理CPU的%CORE UTIL（核心利用率）接近100%，说明物理CPU资源确实不足。此时可以按P按CPU使用率排序，找出消耗最大的虚拟机，判断是“个别虚拟机占用过多”还是“整体资源不足”。

一个常见误区是只看虚拟机的CPU使用率。假设一台8vCPU虚拟机CPU使用率只有40%，但%RDY高达25%，说明它虽然“不想跑满”，但每次想跑都要排队。这种情况下，减少vCPU数量反而可能降低%RDY——因为调度器需要同时找到8个物理核心的难度远大于2个。

用vCenter性能图表做趋势与对比

vCenter性能图表适合回答“什么时候开始出问题”和“哪些对象同时受影响”。在vSphere Client中选中集群→监控→性能→高级，添加“CPU就绪时间”和“CPU争用”指标，时间范围选最近24小时或7天。如果发现某台主机的就绪时间在每天上午9点后明显上升，而其他主机平稳，说明问题集中在单台主机，可能是该主机上虚拟机密度过高或存在“吵闹邻居”。

对比视图很有用：同时选中多台虚拟机，叠加显示它们的就绪时间曲线。如果只有一台虚拟机曲线突出，问题在它自身（vCPU过多或资源池限制）；如果多台虚拟机同步上升，问题在宿主机或集群层面。vCenter图表还支持导出CSV，便于做容量分析。

用vRealize Operations做关联根因分析

vRealize Operations（vROps）的价值在于跨对象关联。当就绪时间告警触发时，vROps会自动关联同一主机、同一集群、同一数据存储上的其他异常指标。例如，它可能同时显示“主机CPU就绪时间高”和“该主机上某虚拟机NUMA本地性低”，帮助快速定位是NUMA问题而非单纯资源不足。

在vROps中，可以创建自定义仪表板，把“CPU就绪时间”“CPU争用”“NUMA本地性”“vCPU数量”放在同一视图中。对于NUMA问题，重点关注“NUMA本地性”指标，低于90%通常意味着跨节点访问比例偏高。vROps的“异常检测”功能还能在指标偏离基线时提前告警，而不是等到阈值被突破。

NUMA跨节点访问的识别与处理

NUMA问题的典型场景是：虚拟机vCPU数量超过单个NUMA节点的物理核心数。例如，一台双路服务器每个CPU有16个核心，共2个NUMA节点。如果创建一台24vCPU的虚拟机，它必然跨越两个NUMA节点，部分vCPU访问远端内存。此时即使%RDY不高，应用性能也可能下降。

识别方法：在esxtop中按m进入内存视图，查看NUMA相关字段；或在vROps中查看虚拟机的NUMA本地性。处理方式包括：将虚拟机vCPU数控制在单NUMA节点核心数以内；在虚拟机高级设置中配置numa.vcpu.preferHT或numa.nodeAffinity；或通过DRS规则将虚拟机绑定到特定主机组。需要注意的是，强制NUMA绑定可能降低DRS的调度灵活性，应权衡使用。

一个完整的诊断示例

假设某数据库虚拟机（8vCPU）在业务高峰期响应变慢。vCenter图表显示该虚拟机就绪时间从平时的2%升至18%，同时宿主机CPU使用率约75%。esxtop确认%RDY为17%，%CSTP为5%，NUMA本地性为82%。分析：宿主机CPU使用率75%不算饱和，但%RDY高说明调度排队；%CSTP为5%说明8个vCPU步调不一致；NUMA本地性82%说明存在跨节点访问。综合判断，问题不是物理CPU总量不足，而是该虚拟机vCPU过多导致调度困难和NUMA跨越。调整方案：将vCPU从8降至4，观察%RDY和NUMA本地性是否改善。调整后%RDY降至4%，NUMA本地性升至96%，应用响应恢复正常。这个示例说明，CPU性能诊断不能只看使用率，就绪时间、争用和NUMA本地性才是关键判据。