网站响应变慢、SSH 操作卡顿，打开 top 却没有找到明显占满 CPU 的进程，这时可以留意 CPU 汇总行中的 st。
st 与程序自身的 CPU 占用不同。它反映的是虚拟机在 CPU 调度方面的等待情况。不过，看到某一秒 st 偏高，还不足以判断故障原因。
本文介绍 Linux 中 st 的含义，以及怎样通过连续采样、每个 vCPU 的数据和业务表现进行排查。
1. top 中的 st 是什么意思？
st 是 steal time，通常译为 CPU 窃取时间。
在虚拟机环境中，vCPU 需要由虚拟化平台调度到物理 CPU 上运行。当虚拟机有任务需要执行，却没有获得相应的 CPU 运行时间时，这部分等待可能计入 steal time。
因此，st 偏高意味着虚拟机存在 CPU 调度等待，可能影响应用响应速度。它不是某个进程的 CPU 使用率，也不表示某个程序正在“偷用”服务器。
不同虚拟化平台的支持和统计方式可能存在差异。例如，KVM 的相关说明明确指出，vCPU 自身处于空闲状态的时间不计入 steal time。
2. 分清 st、wa 与 sy，避免查错方向
在 top 的 CPU 汇总行中，常见字段可以这样理解：
| 字段 | 含义 | 排查时关注什么 |
|---|---|---|
us | 普通用户态程序使用的 CPU 时间 | 哪些应用进程正在消耗 CPU |
sy | 内核态使用的 CPU 时间 | 系统调用、内核处理等活动 |
id | 空闲时间 | 当前采样窗口内的 CPU 空闲情况 |
wa | I/O 等待相关时间 | 是否存在 I/O 等待，并结合其他指标检查 |
st | 虚拟化环境中的 CPU 调度等待时间 | 虚拟机是否持续等待获得 CPU |
这些字段描述的是不同类型的 CPU 时间，不能混为一谈。比如，sy 高与 st 高，后续需要检查的方向就不一样。
还要注意：wa 不是磁盘使用率，也不能单凭它判断硬盘故障。 Linux 内核文档对 iowait 的统计局限有专门说明，需要结合实际 I/O 和业务情况判断。
3. 先连续观察，再查看每个 vCPU
以下安装命令适用于 Debian、Ubuntu。如果相关工具已经安装，可以跳过；使用 root 登录时，可去掉命令前面的 sudo。
sudo apt-get update
sudo apt-get install -y procps sysstat其中，procps 提供 top、vmstat 等工具，sysstat 提供 mpstat。
先执行：
top观察 CPU 汇总行中的 st，连续看几个刷新周期。
在 top 界面按数字键 1，可以切换查看每个 CPU 的状态；按 q 退出。不要只保存一张截图就结束观察。
接着执行：
LC_ALL=C mpstat -P ALL 1 10这条命令每隔 1 秒输出一次数据，共输出 10 次。LC_ALL=C 用于保持输出字段和数字格式一致，便于对照说明。
重点看：
%steal：当前采样窗口的 CPU steal 比例。all行：所有 CPU 的平均情况。- 各 CPU 行：判断问题是集中在部分 vCPU，还是普遍存在。
只看平均值可能掩盖单个 vCPU 的异常，因此要把 all 与各 CPU 的数据一起看。
这十秒钟的数据适合初步观察。如果卡顿间歇出现，应在故障发生时继续采样。
4. 用 vmstat 交叉检查，别漏掉内存和 I/O
执行：
LC_ALL=C vmstat -t 1 11这条命令带时间输出 11 份报告，间隔 1 秒。
第一份报告中的 CPU 数据是开机以来的平均值，后面的报告才反映对应采样间隔。 因此，排查刚刚发生的卡顿时，应重点看后续十份报告。不要把第一份 CPU 数据理解成“上一秒的状态”。
可以重点查看以下字段：
| 字段 | 含义 |
|---|---|
r | 正在运行或等待运行的任务数量 |
b | 等待 I/O 的阻塞任务数量 |
us、sy | 用户态、内核态 CPU 时间 |
wa、st | I/O 等待与 CPU steal |
si、so | 每秒换入、换出的内存量 |
注意，vmstat 中的 si 指 swap 换入，top CPU 汇总行中的 si 指软件中断时间，两者不是同一个指标。
再查看内存：
free -h不要只看 free 列。available 是系统对“不需要发生交换就能供新应用使用的内存”的估计，包含部分可回收缓存。
据此，可以形成几个排查方向：
st持续升高，并与卡顿时间吻合：进一步检查虚拟化调度情况。us或sy持续升高：继续定位应用进程或内核活动。wa、b同时异常：补充检查存储和 I/O。- 可用内存紧张，且
si、so持续活跃：进一步检查内存压力。
这些是定位线索，需要结合业务表现验证。若主要问题是应用自身消耗 CPU，可以参考本站的 Linux服务器CPU占用100%排查教程。
5. st 多高才需要处理？
实际排查时，不建议套用“超过某个百分比就一定异常”的统一结论。
更有价值的是回答三个问题：
- 持续多久？ 是偶尔跳高一秒，还是连续多个采样周期偏高？
- 是否偏离平时水平？ 同样业务负载下，正常时段的数据是什么样？
- 是否影响业务？ 网站响应、接口耗时或任务完成时间有没有同步恶化？
例如，某一秒 st 突然升高，但业务没有明显变化，可以继续观察；如果卡顿期间持续出现较高 %steal，而正常时段明显降低，就有必要保留完整记录进一步核查。
同样，st 为零只表示该窗口没有记录到 steal time，不能据此证明服务器不存在其他性能瓶颈。
6. 保存一分钟采样日志
为了方便核对故障时间，可以在服务器上一个有写入权限的目录中执行：
report_file="cpu-steal-$(date +%Y%m%d-%H%M%S).log"
{
date -Is
uname -r
LC_ALL=C mpstat -P ALL 1 60
} | tee "$report_file"命令会持续采样约一分钟，然后自动结束，并在当前目录生成日志文件。终端同时显示采样内容；如果提前按 Ctrl+C，保存的采样时间会相应缩短。
日志中包含服务器时间、时区偏移、内核版本，以及每个 vCPU 的采样结果。
同时记录以下信息，后续核对会更方便：
- 卡顿发生的准确时间和持续时长。
- 当时正在执行的业务或任务。
- 网站响应变慢、接口超时等具体表现。
- 正常时段同样命令采集的数据。
正常与异常时段使用相同的采样方法，才更容易看出差异。 不要只截取最高的一个数值。
7. 根据结果处理，并验证业务是否恢复
如果数据主要指向应用自身占用 CPU，应继续检查繁忙进程、定时任务、批量作业和程序处理逻辑，确认是否需要调整并发或错开执行时间。
如果 %steal 持续偏高，并且与业务变慢的时间吻合，可以将日志交给云服务商或虚拟化管理员，请其核查对应时段的宿主机 CPU 负载、vCPU 调度和资源分配情况。
虚拟机内部的数据能够提供线索，但不能单独确认宿主机上的具体原因。Red Hat 的相关文档也将减少资源争用、调整虚拟机资源分配等列为宿主机侧的处理方向。
调整后，在相近的业务负载下重新采样，同时比较：
%steal是否回落。- 接口响应时间是否改善。
- 原本缓慢的任务是否恢复正常。
- 卡顿是否还会在相同时段出现。
如果希望持续记录网站可用性和访问响应时间，可以参考本站的 Docker搭建Uptime Kuma网站监控。它可以帮助观察网站访问表现；CPU steal 等系统指标仍需要使用系统工具或相应监控方案采集。
8. 结语
Linux top 中的 st 高，说明需要关注虚拟机的 CPU 调度等待情况。排查时，先分清 st、wa 和 sy，再通过 mpstat 查看各个 vCPU，用 vmstat 和内存信息补充判断。
保留连续采样记录，对照业务变慢的时间，并在调整后重新验证，比只看一张截图更容易找到问题所在。
如需准备 Linux 云服务器用于网站部署和运维实践，可以通过莱卡云官网查看配置，并根据实际业务选择 CPU、内存与存储容量。
查看官网购买链接： https://www.lcayun.com
9折优惠码：bloglcayun
