技术帮助 · 发布时间：
高峰时虚拟机变慢，不一定是分配的CPU核心数不够，也可能是多台虚拟机同时争用同一批物理处理器。识别虚拟化计算实例的CPU超售风险，应把主机调度指标与业务响应情况放在同一时间轴上观察，而不是仅凭配置表里的vCPU数量下结论。
先分清“超售”与“资源不足”
CPU超售通常指分配给虚拟机的vCPU总量超过宿主机可用的物理处理器核心数。常用的粗略比例是“已分配vCPU数÷物理核心数”，但它不是风险判定线：轻载、错峰的实例可以承受较高比例；持续繁忙、对延迟敏感的实例，即使比例不高，也可能发生调度等待。
还要区分物理核心与硬件线程。支持超线程的处理器可提供更多逻辑处理器，但逻辑处理器不等同于同等数量的物理核心，实际吞吐受处理器型号、指令负载和并发情况影响。判断虚拟化计算实例的CPU超售风险，要看高峰期真正能否及时获得CPU。
高峰期重点观察四类信号
- 主机CPU利用率：看繁忙时段是否长时间接近满载，并观察是否有足够余量应对突发任务。持续高利用率是警示信号，但单个采样点偏高不能单独定性。
- CPU Ready：在 VMware vSphere 中，它反映虚拟机准备运行却等待物理CPU调度的时间。若高峰期间持续升高，且同时出现响应变慢，说明存在争用的可能。百分比会受统计口径和虚拟机vCPU数量影响；常见的5%左右只能作为排查提示，不是通用故障阈值。
- steal time：在支持该统计的虚拟机系统中，它表示虚拟CPU因宿主机调度而未能运行的时间。持续升高可作为旁证，但不同平台的呈现方式、采样周期并不完全相同。
- 运行队列与业务延迟：关注宿主机可运行任务排队情况，并对照应用响应时间、任务完成时间或吞吐量。只有性能变化与调度等待在时间上相互印证，结论才更可靠。
按同一时间窗口完成排查
- 选取可比时段。至少覆盖一次正常负载和一次业务高峰，使用相同采样间隔记录主机CPU利用率、虚拟机CPU Ready或steal time，以及业务侧延迟。采样间隔可先设为1至5分钟；突发很短的负载需要更细的监控。
- 从虚拟化平台定位主机。在 vSphere 查看主机和虚拟机的CPU利用率、Ready等性能图表；在 KVM 环境可结合宿主机监控与虚拟机指标检查调度等待。不同工具的字段名称和统计口径可能不同，应先核对平台说明。
- 比较同主机实例。若多台虚拟机在相近时段同时出现等待，而其他主机上的同类负载正常，优先检查该主机的资源分布、实例密度与调度设置。若只有单台实例异常，还需排查它自身的线程并发、软件锁等待或突发任务。
- 做小范围验证。选择低风险实例迁移到有余量的主机，或暂时减少同一主机上的并发负载，再观察相同指标。性能随争用缓解而改善，能增强超售判断；变更前应确认迁移条件和业务影响。
- 据证据调整。可降低高峰期同时运行的CPU密集型任务、将关键实例分散到不同主机，或增加宿主机计算能力。单纯给虚拟机增加vCPU可能扩大调度压力，尤其是多vCPU实例，应验证调整前后的延迟与Ready变化。
不要用单一比例代替判断
vCPU与物理核心比例适合做容量盘点，不适合单独作为告警依据。批处理、编译等间歇性计算负载通常可以利用错峰特征安排；持续计算或延迟敏感负载则需要保留更多余量。对虚拟化计算实例的CPU超售风险，建议建立高峰基线，并把“调度等待上升、业务性能下降、迁移或降载后改善”作为联合判断链条。
常见问题
CPU利用率不高，也会有CPU争用吗？
可能。采样平均值会掩盖短时拥塞；还应查看更细粒度的等待指标，并确认监控范围是否覆盖相关宿主机和虚拟机。
CPU Ready略高就要扩容吗？
不必。先核对统计口径、持续时间和业务影响，再与正常时段或其他主机比较，避免仅凭一个数值扩容。
增加vCPU能解决超售吗？
不一定。增加vCPU能提高并行能力，但也会增加调度需求；若瓶颈在宿主机争用，应先优化分布或增加可用计算资源。
