VPS CPU steal time过高怎么办？用mpstat分清宿主机争用与自身负载
在VPS里，应用响应变慢而进程CPU占用并不高，可能不是代码突然变慢，而是虚拟机想运行却拿不到物理CPU。Linux统计里的steal time（常显示为st或%steal）表示虚拟CPU被虚拟化平台暂时“拿走”的时间。它和应用主动等待磁盘I/O、cgroup CPU throttling不是一回事。
先确认指标口径
在问题发生时保存短时间窗口，而不是只看一次top：
mpstat -P ALL 1 10
vmstat 1 10
top -H -b -n 2
cat /proc/stat | headmpstat的%st持续升高且多个vCPU同步变化，才有理由怀疑宿主机争用。单个进程的CPU高、%st接近零，更像应用自身计算瓶颈。
| 现象 | 更可能的方向 | 下一步 |
|---|---|---|
| %st持续升高，业务整体变慢 | 宿主机超卖或邻居争用 | 按小时记录并与云监控对照 |
| %st低，cgroup throttled升高 | 配额或容器限制 | 检查cpu.stat、quota和period |
| %st低，单线程满载 | 应用计算或锁竞争 | 做线程级采样和代码剖析 |
| %wa升高 | 磁盘或网络I/O等待 | 结合iostat、PSI和队列排查 |
把steal与配额限流分开
如果服务跑在容器或systemd资源控制组中，先查看本组的CPU统计：
cat /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max
systemctl show example.service -p CPUQuota -p CPUAccountingcgroup v2中的nr_throttled和throttled_usec增长，说明任务被本机配额限制；这时调高配额或减少并发才是方向。反过来，配额没有触发而%st明显升高，改应用参数通常不能根治。
如何建立可交涉的证据
记录同一时间轴
每分钟保存mpstat、业务延迟、运行队列、容器配额和云平台CPU监控。至少覆盖正常时段和故障时段，避免用单次尖峰下结论。
做低风险对照
在维护窗口降低非关键任务并观察%st是否仍高；不要在生产环境用无节制压测“证明”争用。若同一宿主机或同套餐多台实例同时出现steal升高，把时间戳、实例ID和指标截图交给服务商核查。
临时缓解与长期处理
短期可以降低后台批处理并发、错峰执行或迁移非关键作业。长期应让服务商确认宿主机容量、CPU保证和迁移方案；更换套餐前先核对是否改变了vCPU配额、独享程度和计费边界。
验收标准
- 故障时段的%steal、%usr、%sys、%wa均有记录；
- cgroup throttling与宿主机争用结论互不混淆；
- 应用延迟和系统指标使用同一时区、同一采样窗口；
- 迁移或套餐调整后，用相同脚本复测，而不是只看“负载变低”。
CPU steal是VPS独有的可见线索，但它只能说明虚拟CPU等待物理资源，不能单独证明服务商违约或线路故障。把它与配额、I/O和应用指标放在同一时间轴上，才能得到可复核的结论。
