📚 课程目录第3章 CPU性能指标深度解析

3. CPU性能指标深度解析

在vSphere环境中，CPU性能问题往往不是“CPU不够快”，而是“CPU没有被有效利用”。要判断一台ESXi主机或虚拟机的CPU是否健康，必须把使用率、就绪时间、等待时间、超额订阅、核心共享和NUMA调度放在同一张图里理解。它们分别回答不同问题：使用率回答“忙不忙”，就绪时间回答“想跑却排不上队”，等待时间回答“在等什么”，超额订阅回答“资源承诺是否超过物理能力”，核心共享回答“多个vCPU如何争抢物理核”，NUMA调度回答“内存访问是否跨节点”。

一、CPU使用率：最直观但最容易误读的指标

在vSphere中，CPU使用率通常以MHz或百分比表示。主机层面看的是物理CPU的消耗，虚拟机层面看的是虚拟CPU的消耗。例如一台虚拟机配置4个vCPU、每个vCPU 2.5GHz，则其CPU资源上限约为10000MHz。若某时刻使用率为2500MHz，则使用率约为25%。但使用率低并不代表没有性能问题：如果虚拟机在等CPU调度，使用率可能不高，就绪时间却很高。

采集方法上，可通过vSphere Client的“性能”选项卡查看，也可用esxtop按c进入CPU视图，关注%USED、%RUN、%RDY、%CSTP等字段。PowerCLI也可批量采集：

Get-VM | Get-Stat -Stat cpu.usage.average -Realtime -MaxSamples 1 |
  Select-Object Entity, Value, Timestamp

二、就绪时间（Ready Time）：CPU争抢的核心信号

就绪时间表示虚拟机已具备运行条件、但物理CPU正被其他虚拟机占用而被迫等待的时间。它反映的是调度竞争，不是虚拟机自身计算慢。esxtop中%RDY表示就绪时间占虚拟机总可调度时间的百分比。经验上，单vCPU虚拟机持续超过5%、多vCPU虚拟机持续超过10%就值得关注；若超过20%，通常已出现明显卡顿。

就绪时间高常见于：主机CPU超额订阅严重、虚拟机vCPU数量过多、CPU限制（Limit）设置过低、或NUMA跨节点调度。排查时应先看主机整体%USED，再看单台虚拟机的%RDY，最后结合%CSTP（协同停止时间）判断多vCPU是否因等待所有vCPU同时调度而受阻。

三、等待时间（Wait Time）：区分“等CPU”与“等I/O”

等待时间常被混淆。在esxtop中，%WAIT表示虚拟机处于等待状态的时间比例，其中包含空闲等待和I/O等待。真正需要区分的是：虚拟机是在等CPU调度（就绪），还是在等存储/网络I/O。若%RDY高而%WAIT不高，问题在CPU竞争；若%WAIT高且%RDY低，则更可能是I/O瓶颈。因此，等待时间必须与就绪时间、磁盘延迟、网络丢包一起看，不能单独下结论。

四、超额订阅与核心共享：vCPU与物理核的比例关系

超额订阅指虚拟CPU总数超过物理逻辑核数量。例如一台主机有16个逻辑核，运行20台4vCPU虚拟机，则vCPU总数为80，超额订阅比为5:1。适度超额订阅可提高利用率，但比例过高会推高就绪时间。核心共享则指多个vCPU共享同一物理核的时间片。vSphere通过CPU调度器按时间片轮转，若虚拟机vCPU数超过物理核数，调度器需要“协同调度”所有vCPU，容易产生%CSTP。

实践建议：对延迟敏感的数据库或交易类虚拟机，vCPU总数与物理核比例建议控制在2:1以内；对开发测试类可放宽到4:1～6:1，但必须持续观察%RDY。

五、NUMA调度：跨节点访问的隐性代价

现代物理CPU多为NUMA架构，每个节点有本地内存。若虚拟机vCPU和内存跨NUMA节点分配，远程内存访问延迟明显增加。vSphere默认启用NUMA调度，尽量让虚拟机落在同一节点。当虚拟机vCPU数超过单节点核心数时，会跨节点调度。可通过esxtop的NUMA视图或numastat观察本地/远程内存命中比例。若远程访问比例持续偏高，应考虑减少vCPU数量或调整虚拟机分布。

六、把指标串起来：一次典型排查示例

假设某主机16逻辑核，运行VM-B（8 vCPU）后，用户反馈业务卡顿。采集到：主机%USED约75%，VM-B的%RDY为18%，%CSTP为6%，%WAIT为12%，NUMA远程内存访问约35%。判断路径如下：

主机使用率75%未满，但VM-B就绪时间18%已超阈值，说明存在调度竞争。
VM-B为8 vCPU，超过单NUMA节点核心数（假设每节点8核），触发跨节点协同调度，%CSTP升高。
远程内存访问35%进一步拉长单次执行时间，形成“等CPU+等内存”叠加。
处理方式：将VM-B降为4 vCPU，或将其迁移到空闲主机；若必须保留8 vCPU，则开启NUMA亲和性并避免与其它大vCPU虚拟机同节点。

注意：不要仅凭CPU使用率低就判断CPU无瓶颈。就绪时间、协同停止时间和NUMA远程访问比例，往往才是延迟敏感型业务的真正瓶颈来源。

七、采集与观察建议

日常监控建议至少保留以下数据：主机%USED、每台虚拟机%RDY、%CSTP、%WAIT、vCPU数量、NUMA本地/远程内存比例。使用esxtop时可按c查看CPU、按m查看内存、按n查看NUMA，并用Shift+W保存配置。PowerCLI可定期导出CSV，便于趋势对比。只有把“使用率—就绪—等待—超额订阅—核心共享—NUMA”作为一组关联指标持续观察，才能准确判断CPU性能问题的真实根因。