steal time 是什么
%st（steal time）统计的是虚拟机想运行、但宿主把物理 CPU 分配给了别的租户、自己只能排队等待的时间。它不在客户机内部产生可优化的负载，因此典型症状是“应用响应变慢、CPU 使用率却不高”。top 的 %st、vmstat 的 st 列、sar -u 的 %steal 来自同一份内核统计，只是呈现方式不同。
基本信息
| 适用平台 | 虚拟化客户机（KVM/Xen/云主机；容器内看到的是宿主层面数据） |
|---|---|
| 查看方式 | top 的 %st、vmstat 的 st 列、sar -u 的 %steal、mpstat 按核 |
| 单位 | 百分比（占单个 CPU 时间的比例） |
| 判读经验 | 长期 0-2% 属正常；业务高峰持续大于 5% 需关注；长期大于 10% 说明宿主资源紧张 |
| 权限要求 | 读采样值普通用户即可 |
典型使用场景
- 云主机“卡但各项指标都不高”时的第一道排查：先排除宿主争抢再查应用
- 采购或选型时对比不同规格实例的实际争抢程度
- 业务高峰期间留证据，用于与云厂商沟通或申请迁移
- 同类实例在不同宿主上的表现差异，作为换宿主或换可用区的依据
- 容器/虚机混部环境的宿主侧排查：结合运行队列与 PSI 判断谁在抢资源
常用示例
常用示例
top -b -n 1 | head -n 5 # CPU 汇总行里看 %st
top -b -n 1 | head -n 5 | tail -n 1 # 同一行的 us/sy/id/wa/st 一起看，便于区分自身与争抢
vmstat 1 5 # st 列=被宿主抢走的时间；r 列=运行队列长度
sar -u 1 5 # %steal 列，适合留存时间点作为证据
mpstat 1 5 | head -n 5 # 按核查看，确认是全部核心还是个别核心被抢
vmstat 1 60 | awk 'NR>2 {print $15, $1}' >> /tmp/steal-$(date +%F).log # 连续采样与业务高峰对齐相关指标对照
| 指标 | 来源 | 怎么读 |
|---|---|---|
| %st / st | top、vmstat、sar -u | 被宿主抢占的时间占比，持续偏高说明物理 CPU 争抢激烈 |
| r 运行队列 | vmstat、sar -q | 大于 CPU 核数说明自身也在排队，需与 st 一起判断 |
| PSI /proc/pressure/cpu | 内核 4.20 起 | 量化“因为等 CPU 而卡住”的时间比例，比使用率更贴近体感 |
| %us / %sy | top、sar -u | 客户机自身消耗；与 st 分开看，别把等待时间算成自己的负载 |
| nr_throttled（cpu.stat） | 容器 cgroup | 被 cgroup 限流次数，属于配额问题而非宿主争抢 |
steal 对客户机不可优化：能做的只有换规格或换宿主、减少对延迟敏感的同步调用、把批处理挪到低谷时段；在容器里观察到的 st 反映宿主整体争抢，与容器自己的 CPU 配额被限流是两件事。
突发性能型实例（CPU 积分制）耗尽积分时表现为被限速，指标上并不会出现 steal 上升；把这类限速当成宿主争抢会让排查方向完全跑偏。