核心要点
- CPU steal time 只在虚拟化环境中有实际意义，物理机上通常为 0。
- 在
top命令里，st字段就是 steal time，表示虚拟 CPU 等待真实 CPU 的时间百分比。 - 如果
st长时间超过 10%，例如连续 20 分钟，就需要介入分析。 - 多台同类虚机同时负载高，更像业务自身负载问题；只有单台
st明显高，更像宿主机资源争抢。 - 处理方式通常是优化或升配业务、重启迁移虚机，或联系云厂商协助迁移到更空闲的宿主机。
据说有些云厂商会超卖，宿主有 96 个核心，结果卖出去 100 多个 vCPU，如果这些虚机负载都不高，大家相安无事，如果这些虚机同时运行一些高负载的任务，相互之间就会抢占 CPU，对应用程序有较大影响，我应该如何查看我的 CPU 是否被抢占了呢？
什么是 cpu steal time？
如果你在物理机上查看这个指标，这个指标必然是 0，只有虚拟机才需要关注这个指标。我们看一下 CPU steal time 的定义（来自 ibm.com）：
Steal time is the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing another virtual processor.
虚拟机毕竟是被虚拟出来的，虚拟机要用到 CPU，最终还是要通过宿主机的 CPU 来完成，如果宿主机的 CPU 正在为其他虚拟机服务，那么当前虚拟机就会等待，这个等待的时间就是 steal time。
CPU 跟内存不一样，内存是可以做到硬限制的，如果云厂商超卖，CPU 抢占确实有可能会影响到你的应用程序，所以，我们需要关注这个指标。具体如何查看呢？
如何查看 cpu steal time？
使用 top 命令即可：
上图中，st 就是 steal time，这个指标是百分比，如果是 10，就是 10%。我这个环境是 0%，说明非常健康。
可以把 st 理解成虚拟机“想跑但没拿到真实 CPU”的时间比例。它不是应用进程自己主动空闲，也不是单纯的系统态 CPU 开销，而是虚拟化调度层面的等待时间。
何时需要关注 cpu steal time？
如果这个值长时间（比如连续 20 分钟）超过 10%，就需要介入处理。
| 观察结果 | 含义 | 建议动作 |
|---|---|---|
st 长期为 0 或很低 |
虚拟 CPU 基本没有明显等待 | 持续监控即可 |
st 短时间尖刺 |
可能是宿主机瞬时竞争或业务瞬时高峰 | 结合业务流量和其他主机对比 |
st 连续 20 分钟超过 10% |
虚拟 CPU 长时间等待真实 CPU | 需要排查自身负载或云厂商宿主机竞争 |
如何应对 cpu steal time 过高？
有两种情况，可能都会引起这个值变高，一个是你自己的程序本身负载比较高，你需要优化程序或升配，一个是云厂商超卖，需要迁移虚机到空闲宿主机上（重启虚机，或者直接联系云厂商解决）。如何区分这两种情况呢？
比如你有个 web 程序，部署在 4 台虚机上，4 台虚机负载都高，那大概就是情况一，如果只有一台虚机 st 高，其他虚机都很低，那就是情况二。
FAQ
CPU steal time 高一定是云厂商超卖吗？
不能直接下这个结论。它说明虚拟 CPU 在等待宿主机真实 CPU，但还需要结合多台虚机的负载、业务流量、实例规格和历史趋势判断。只有单台虚机异常高，而同类业务其他虚机正常时，才更像宿主机资源竞争。
物理机需要关注 st 吗？
一般不需要。文章中的判断主要面向虚拟机，物理机上这个指标通常为 0。
业务自身负载高和宿主机争抢怎么区分？
看同一业务的多台虚机。如果多台同时 CPU 使用率和业务负载都高，优先按业务自身负载处理；如果只有一台 st 长时间高，其他机器正常，可以考虑迁移虚机或联系云厂商。
小结
CPU steal time 是判断虚拟机 CPU 是否被宿主机调度竞争影响的重要信号。用 top 看 st 字段即可开始排查，但不要只凭单个瞬时值判断超卖。更稳妥的做法是持续监控趋势，并和同业务、同规格、同时间段的其他虚机对比。
