云服务器响应突然变慢，top 里用户态CPU并不高，CPU行的 st 却持续上升，这通常说明虚拟机本来可以运行，但部分CPU时间被虚拟化层用于其他工作。top把它描述为被hypervisor从当前虚拟机拿走的时间，因此它与普通的应用CPU占用不是一回事。
一次看到5%或10%不能马上断定宿主机过载。采样间隔、实例类型、CPU配额、突发积分、维护迁移和同宿主机争用都可能影响读数。排查重点是持续时间、影响范围和业务延迟是否同步，而不是追求某一秒的st归零。
先连续采样确认趋势
先记录时间、运行时长和多组CPU数据：
date
uptime
top -b -d 1 -n 10 | grep '%Cpu'
vmstat 1 10
mpstat -P ALL 1 10top 的 st、vmstat 的 st 和 mpstat 的 %steal 表示同一类时间，但显示周期和取整方式不同。单个工具的一次快照容易被瞬时调度影响，至少连续采样几分钟，并覆盖业务慢的时间窗口。
查看每个vCPU也很重要。所有CPU同时升高，常见于实例整体受限或宿主机竞争；只集中在少数vCPU，要继续检查应用线程亲和性、虚拟中断和虚拟化平台的调度方式。
从proc数据理解steal
Linux在 /proc/stat 中累计各CPU状态的时间，其中steal字段表示虚拟化环境下被其他操作系统运行占用的时间。可以读取原始值做两次差分：
grep '^cpu' /proc/stat
sleep 5
grep '^cpu' /proc/stat
getconf CLK_TCK原始数字是累计tick，不能直接当百分比。监控工具通过相邻采样的steal增量除以总CPU时间增量得到比例。机器运行很久后的累计总量也不能代表当前故障，所以应保存时间序列，而不是只截一行 /proc/stat。
物理机上通常不会出现有意义的steal值。先确认机器确实运行在虚拟化环境，并记录hypervisor类型：
systemd-detect-virt
lscpu | grep -E 'Hypervisor|Virtualization'容器里观察到的是宿主虚拟机的CPU视角，不能据此判断某个容器独自造成steal。容器CPU限额还会产生节流，需要另行查看cgroup指标。
把steal与业务延迟对齐
steal真正值得处理的信号，是它持续升高时应用延迟、队列长度或任务完成时间同步恶化。把相同时间段的请求P95/P99、负载、CPU运行队列和错误率放在一起看。
sar -u 1 60
sar -q 1 60
pidstat -u 1 20高steal会让虚拟机得到的实际CPU执行时间减少，应用线程可能排队，负载平均值和响应时间随之上升。但负载高也可能来自不可中断I/O等待；看到load上升不能自动归因于steal。
如果业务延迟升高而steal接近零，应转向应用CPU、磁盘、网络和锁竞争。反过来，steal明显但业务仍有足够余量，可以先监控趋势，避免在没有影响证据时仓促迁移。
采样工具本身的时间口径也要统一。监控面板按一分钟平均，命令行按一秒刷新时，峰值大小一定不同。比较处理前后数据时应使用相同聚合周期，并保留原始序列，避免把平均值与瞬时值放在一起下结论。
排除本机CPU与I/O瓶颈
steal高并不意味着本机没有问题。同一时间可能既有宿主机争用，也有进程跑满CPU。先看用户态、内核态、I/O等待和运行队列：
mpstat -P ALL 1 10
pidstat -u -w 1 10
iostat -xz 1 10us 或 sy 长期接近可用CPU上限时，需要定位本机热点进程；wa 与磁盘延迟同步上升时，应排查存储。虚拟机CPU不足导致任务积压，也会让进程CPU百分比看起来不高，因为进程没有获得足够运行时间。
不要通过降低业务进程优先级来修复steal。nice只影响虚拟机内部进程之间的调度，无法要求hypervisor给这台虚拟机更多物理CPU时间。
频率变化也可能干扰直觉判断。虚拟机看到的CPU型号或频率未必等于稳定可用性能，不能用一次 lscpu 或 /proc/cpuinfo 的MHz字段证明宿主机是否超售。应以完成相同任务所需时间和平台指标为准。
检查实例配额与突发性能
部分云实例采用可突发CPU模型，低负载时积累额度，高负载时消耗额度。额度耗尽后，平台可能限制可持续CPU性能。具体指标名称和规则取决于云服务商，应查看实例规格与控制台监控。
先记录实例型号、vCPU数、购买类型和近期配置变化：
nproc
lscpu
cloud-init query ds 2>/dev/null不要只凭操作系统里的steal判断一定是邻居争抢。实例CPU配额、宿主机调度和平台维护都在虚拟化层，操作系统能看到结果，却未必能分辨根因。云平台的CPU credit、throttling、宿主机健康或维护事件是关键旁证。
若故障总在持续高负载一段时间后出现，并在低负载后恢复，突发额度尤其值得检查。若无论业务负载高低都随机出现，则更需要平台侧核查宿主机。
还要确认监控采集代理没有被CPU短缺拖慢。采样间隔出现明显空洞、时间戳跳跃或多项指标同时缺失时，不能把缺失段简单当成零值；应结合系统日志与平台侧监控补齐证据。
区分cgroup节流与steal
应用运行在Docker或Kubernetes中时，容器CPU限额用尽会产生cgroup节流，这与steal是两条不同链路。cgroup v2可查看：
cat /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.maxnr_throttled 和 throttled_usec 持续增长，说明该cgroup因配额被限制。宿主虚拟机steal高则表示虚拟机层面没拿到预期CPU时间。两者可以同时出现，因此应把容器指标、虚拟机指标和应用延迟放在同一时间轴。
取消容器限额可能让单个服务挤占整台机器，不能作为默认处理。先确认限额设计与工作负载是否匹配，再做小范围调整和容量测试。
准备平台工单所需证据
持续高steal且影响业务时，通常需要云平台从宿主机侧确认。提交工单前准备实例ID、区域、精确时间范围、时区、连续采样、业务影响和已排除项。只有一张top截图，平台很难定位已经结束的事件。
sar -u -f /var/log/sa/saDD
journalctl --since '2026-08-16 10:00' --until '2026-08-16 10:30' --no-pager采集历史数据前确认sysstat已启用；没有历史记录就从现在开始采样，不要伪造缺失区间。说明是否重启、迁移或调整过规格，因为这些操作会改变证据链。
测试CPU性能时使用固定线程数、固定数据集和固定持续时间，并先评估对线上业务的影响。随手运行高强度基准可能进一步挤压请求，也可能消耗突发额度，使现场变得更难解释。
需要对比实例规格时，可以在 萤光云 建立同区域隔离节点，或在按小时计费的 LightNode 上运行脱敏基准。不同平台和型号不能做绝对性能排名，只能用相同工作负载验证现象是否随实例迁移而消失。
选择迁移、升配还是优化应用
平台确认宿主机异常时，迁移实例通常比在系统内调参更直接。迁移前确认公网IP、磁盘、快照、停机窗口和授权信息是否受影响，并先做可恢复备份。
业务长期把vCPU用满，steal只是放大了已有容量不足，应该评估升配或横向扩容。只有在本机热点明确时，代码优化、缓存和任务错峰才会直接减少CPU需求。三种措施解决的是不同层次，不能互相替代。
紧急止血可先降低非核心批处理并发，把容量留给在线请求；但这不会消除虚拟化层争用。操作后继续采样，确认业务指标改善幅度。
修复后怎样验收
迁移、升配或平台处理后，用相同采样周期和相近业务负载复测。至少比较steal、运行队列、请求延迟、吞吐和错误率，单看st下降不足以证明业务恢复。
mpstat -P ALL 1 60
vmstat 1 60观察跨过一个真实高峰，并确认监控告警能够识别持续异常而非单点毛刺。合格的结论应说明steal在什么负载下升高、对业务造成多大影响，以及采取措施后相同负载是否恢复。
告警阈值可同时设置持续时间和业务条件，例如steal连续多个采样周期偏高且请求延迟恶化时升级处理。这样既不会漏掉真实容量问题，也能减少短暂调度抖动造成的误报。阈值应依据实例基线定期复核，不能在所有规格上照搬同一个数字。
常见问题
CPU steal偶尔升到10%需要立即迁移吗？
不一定。先看持续时间、采样间隔和业务影响。短暂尖峰与长期稳定偏高的处理优先级不同。
重启虚拟机能解决steal高吗？
重启可能暂时改变调度状态，但不保证迁移到其他宿主机，也不能修复实例配额或长期容量不足，应先保存证据。
top里CPU使用率不高，为什么应用仍然慢？
虚拟机没有获得足够CPU时间时，进程能实际执行的时间减少，内部统计未必呈现为普通用户态CPU跑满，需要结合steal和运行队列判断。
