Linux 云服务器 CPU steal 高怎么排查？虚拟化争用与负载判断

CPU steal 表示虚拟 CPU 本可运行却在等待宿主调度。单次尖峰不能直接证明宿主拥塞；只有 steal 持续升高并与延迟、吞吐下降同步，才应进入实例规格和宿主层排查。

先给结论

CPU steal 表示虚拟 CPU 本可运行却在等待宿主调度。单次尖峰不能直接证明宿主拥塞；只有 steal 持续升高并与延迟、吞吐下降同步，才应进入实例规格和宿主层排查。

steal time 到底表示什么

Linux 在 /proc/stat 中记录 steal 时间，表示虚拟机等待物理 CPU 调度的时间。它与 user、system、iowait 属于不同维度：iowait 更偏向等待 I/O，steal 更接近虚拟化调度争用。

应用 CPU 使用率不高但响应变慢时，如果 steal 持续升高，可能说明 vCPU 获得的实际运行时间不足。不过负载、锁竞争、GC 和存储延迟也会造成相似现象，不能只看一个指标。

如何采样而不是看瞬时值

使用 mpstat -P ALL 1 60 连续采样一分钟，同时记录 uptime、应用延迟和吞吐。按每个 vCPU 观察，避免平均值掩盖单核热点。

监控系统应保存至少分钟级趋势，并与正常时段比较。一次 1% 或短暂尖峰没有统一故障阈值；不同业务的可接受范围取决于延迟目标和并发模型。

先排除实例内部原因

检查单线程热点、运行队列、上下文切换、软中断、CPU 绑核和容器限额。若某核 user/system 已接近饱和，即使总体平均值不高，也可能是应用自身无法利用更多核心。

突发性能实例还需检查 CPU 积分或基线限制。积分耗尽与宿主 steal 是不同机制，应从云平台监控指标分别核对，不能仅凭操作系统负载猜测。

如何判断宿主或规格因素

在同一业务负载下比较多个时间窗口、多个实例和多个可用区。若只有单实例 steal 持续异常，而应用、镜像和流量模式一致，才更支持宿主调度因素。

可在具备回退条件时迁移或停止再启动实例，并比较迁移前后指标。该操作可能改变宿主且会造成停机或 IP 变化，执行前必须确认云盘、实例存储、弹性 IP 和维护窗口。

扩容为什么不一定解决

增加 vCPU 能缓解真实 CPU 饱和，但如果应用单线程、锁竞争或授权限制，扩容后吞吐可能不变。规格升级还会增加费用，应该先通过单核使用、运行队列和压测证明瓶颈。

如果 steal 来自短时邻居争用，换宿主可能比长期升配更直接；如果所有时段都接近 CPU 上限，则应优化应用、调整并发或选择更合适的实例族。

验证和工单证据

修复后在相同流量窗口复测 steal、p95/p99 延迟、吞吐和错误率。至少比较变更前后两个同长度窗口，避免把自然流量下降当成修复效果。

需要提交云厂商支持时，提供实例 ID、区域/可用区、准确时间、mpstat 采样、平台 CPU 指标和业务影响，不提供密码、私钥或长期 API 密钥。

排查与验收表

操作边界

生产环境变更前必须记录资源 ID、时间窗口、影响范围和回退方法。命令示例需要按实际接口、区域和实例替换参数；涉及重启、迁移、网络规则或日志费用时，先在最小范围验证。

采样命令与结果核对

使用 mpstat -P ALL 1 60 连续观察每个 vCPU 的 steal、user、system、iowait 和 idle，同时保存 uptime 与 /proc/stat。执行前确认已经安装 sysstat；这些命令只读取指标，不会修改系统配置。

不要只截取最高的一秒。保存完整 60 秒输出，并与同一时间段的请求延迟、吞吐和云平台 CPU 指标对齐。如果只有某个 vCPU 长期繁忙而 steal 很低，优先检查单线程热点；如果多个 vCPU 的 steal 同步升高而 user/system 并未饱和，再评估宿主争用。

变更前后的对照方法

迁移、重启或更换规格前后使用相同采样周期与近似业务负载。至少记录平均值、峰值持续时间和 p95/p99 延迟。业务流量差异过大时不能直接比较；受控压测必须限定并发并避开生产高峰。

记录与复核要求

排查记录应包含准确时间、环境、资源或接口标识、执行命令、原始结果、采取的变更和变更后的独立验证。对比数据必须来自相同口径与相近负载；无法复现时应明确标记观察条件，而不是把暂时恢复写成根因已经确认。

任何涉及重启、迁移、规则、内核参数或日志保留的调整，都要先保存原值并准备回退路径。最终结论应能由另一名运维人员根据记录复核。

官方资料

• Linux Kernel：/proc/stat
• sysstat mpstat 手册