监控告警与压测结合更适合排查CPU超售

监控中的CPU使用率只有百分之四十，并不代表没有CPU超售风险。虚拟机或容器可能同时受到宿主机调度、同节点其他租户和突发任务影响，表现为请求延迟上升、任务执行时间拉长，却没有明显的平均利用率峰值。因此，CPU超售风险排查更适合把持续监控与可控压测结合起来，先发现异常，再验证异常是否能够稳定复现。

先确定要观察的信号

单看总CPU利用率容易误判。Linux环境中，应同时观察用户态、内核态、空闲时间、运行队列和调度等待。虚拟机还应关注steal time，它表示虚拟CPU等待物理CPU的时间比例；该指标在业务低负载时持续升高，往往比总利用率更能提示CPU争用。

容器场景还要检查cgroup的CPU limit、CPU throttling和实际分配的CPU时间。如果容器被限制为1个vCPU，即使节点还有空闲资源，达到配额后也可能被节流。Windows系统则可结合处理器队列长度、每处理器运行时间和应用响应时间进行交叉判断。关键不是追求某个固定阈值，而是比较正常时段、业务高峰和压测时段的变化。

建议采集的指标

业务层：请求量、P95或P99延迟、超时率、队列长度和错误码。
系统层：CPU使用率、运行队列、上下文切换、负载、steal time和节流时间。
虚拟化层：vCPU数量、物理核或线程映射、同宿主机实例数量，以及迁移或调度事件。
压测层：并发数、实际吞吐、每个请求的服务时间和测试持续时间。

用告警缩小CPU超售风险排查范围

告警不宜只设置“CPU超过百分之八十”。更实用的做法是使用组合条件：例如延迟超过业务基线，同时steal time连续升高；或者运行队列增长、吞吐量下降，而进程本身没有明显的锁等待和内存回收压力。连续时间可以按5至15分钟设置，具体取值应根据业务波动和采样周期调整。

告警还需要保留对照维度。至少按实例、可用区、宿主机或节点池、时间段进行聚合。如果只有同一节点上的部分工作负载异常，CPU争用的可能性较高；如果所有节点都在相同时间变慢，则应优先检查数据库、网络、依赖服务或发布变更。这样设计能避免把普通业务增长误判为CPU超售风险。

判断原则：CPU利用率说明“用了多少”，steal time和调度延迟说明“等了多久”，业务延迟则说明“用户受到了什么影响”。三类信号需要放在同一时间轴上。

通过压测验证是否存在超售

压测的目的不是单纯把CPU打满，而是在接近真实请求模型的条件下观察性能是否随并发增长出现异常拐点。测试前应固定版本、数据规模、请求比例和运行时长，并记录测试对象所在的节点或实例信息，否则结果难以比较。

可执行的测试步骤

建立基线。在低并发下运行约10至15分钟，记录吞吐、P95延迟、CPU利用率、steal time和节流时间。
逐级增加并发，例如每次增加约20%至30%，每个梯度保持5至10分钟，避免瞬时突发掩盖调度问题。
重复测试至少两轮，并尽量安排在不同时间段。若业务允许，可分别观察工作日高峰和低峰。
将压测曲线与监控告警对齐，检查延迟拐点是否伴随steal time、运行队列或节流时间上升。
在条件允许时，把同一镜像部署到独享资源或较低超售比例的资源池中做对照，比较相同并发下的延迟和吞吐。

如果压测中应用CPU仅中等使用，但延迟在某个并发区间突然增加，同时steal time明显升高，通常更接近虚拟化调度竞争。若应用CPU接近配额上限且throttling同步增加，则可能是容器限制过低，不能直接归因于宿主机超售。若CPU指标稳定而数据库连接池、磁盘延迟或网络重传异常，则应停止CPU超售风险排查，转向对应资源。

如何处理确认后的风险

确认问题后，处理方式取决于业务对延迟稳定性的要求。对在线交易、实时接口等尾延迟敏感的服务，可优先迁移到独享或超售比例更低的资源池；这通常更稳定，但成本和资源利用率可能较高。对批处理、离线计算或可重试任务，可以保留共享资源，同时错开高峰并限制并发。

如果问题集中在容器配额，应重新评估requests与limits，避免把limit设置得过低；调整前要确认节点可分配容量，防止只把节流问题变成节点资源不足。云环境中还应核对实例类型、突发积分或供应商提供的vCPU说明，但不能仅凭实例名称推断实际性能。

常见问题

CPU使用率不高，为什么仍可能有风险？

因为平均值会掩盖等待。虚拟CPU可能在等待物理CPU，或容器已达到自身配额，业务延迟因此上升。

压测多久才有参考价值？

通常每个并发梯度至少保持5至10分钟；对有缓存预热、周期任务或连接池变化的系统，应延长到能覆盖一个完整业务周期。

steal time达到多少就一定异常？

不存在适用于所有环境的固定值。应结合基线、业务延迟和持续时间判断，短暂波动与连续升高的含义不同。

是否必须使用独享资源？

不必须。低峰运行、可重试或对延迟不敏感的任务可以使用共享资源，但应保留告警、压测和回退方案。

最终，CPU超售风险排查应形成“监控发现、压测复现、对照验证、资源调整”的闭环。只有把调度指标与真实业务结果放在一起，才能区分单纯负载增长和持续性的CPU争用。