TL;DR：VPS（虚拟专用服务器）出现卡顿时，单看 load average（平均负载）很容易误判。先用 vmstat 1 10 观察 st，再用固定时长的 CPU 压力测试复测；如果业务进程拿不到应有的计算时间，且测试期间 st 持续升高，才有理由怀疑宿主机上的邻居噪声。本文给出一套不依赖服务商后台数据的排查方法，帮助你区分 CPU 配额、进程自身阻塞和底层资源争用。
先搞懂 CPU Steal 是什么
CPU Steal time（被偷取时间）是虚拟化环境里的一个统计值：你的虚拟机本来想运行，但虚拟机监控器把物理 CPU 时间分给了其他虚拟机，于是这段等待时间被记为 st。它不是 CPU 使用率，也不是 iowait（等待磁盘 I/O 的时间）。同样是页面响应变慢，st 指向的排查方向与磁盘、内存完全不同。
在 Linux 中，top 的 CPU 行通常会显示 st，vmstat 的最后一列也会显示 steal。这个数值应当结合时间序列看，不能凭单次刷新下结论。短暂的 1% 到 3% 可能只是调度波动；在业务高峰或压力测试期间持续超过 5%，并且应用延迟同步上升，才值得继续取证。不同平台的 CPU 调度策略不同，阈值只能作为经验起点，不能当成服务等级承诺。
第一轮：用 vmstat 建立基线
先不要急着安装压测工具。在问题发生时保存 10 秒基线：
date
uptime
vmstat 1 10
mpstat -P ALL 1 5vmstat 输出中，r 是等待运行的进程数，us 和 sy 分别是用户态与内核态 CPU 时间，wa 是 I/O 等待，st 是被虚拟化层拿走的时间。若 r 很高而 us 也高，可能只是自己的程序在消耗 CPU；若 r 不高但 st 连续增加，则更像虚拟 CPU 没有及时得到调度。
mpstat -P ALL 用于观察每个虚拟 CPU。若只有一个 vCPU，重点是时间序列；若有多个 vCPU，可以比较各核的 st 是否同步。同步升高更接近宿主机调度或配额问题，单核异常则还要检查进程亲和性、单线程程序和应用自身的锁竞争。
第二轮：把邻居噪声与自身负载分开
只看监控截图无法证明“邻居”存在。更稳妥的做法是把测试分为三段，每段至少 60 秒，并记录开始和结束时间：空闲观察、轻量业务负载、独立 CPU 压力测试。压力测试只应使用临时测试机或维护窗口，生产环境不要直接运行未知脚本。
可以使用发行版仓库中的工具。例如 Debian/Ubuntu 环境先安装 stress-ng，然后运行：
sudo apt-get update
sudo apt-get install -y stress-ng
vmstat 1 60 > vmstat-before.txt
stress-ng --cpu 1 --timeout 60s --metrics-brief
vmstat 1 60 > vmstat-during.txt如果是多 vCPU，可以先从一个 worker 开始，避免测试本身把整台 VPS 打满。对照 vmstat-before.txt 与 vmstat-during.txt：自己的 us 上升是预期现象；若 st 在压力期间明显高于空闲期间，且重复两次仍出现同样趋势，证据才比较有价值。测试输出中的 bogo operations 只适合比较同一实例、同一时间段的相对变化，不能拿来跨平台宣称固定性能。
怎样判断是配额、超售还是磁盘问题
CPU Steal 高不等于服务商一定超售。先把几个容易混淆的现象分开：
| 现象 | 更可能的方向 | 验证方法 |
|---|---|---|
st 持续高，wa 正常 | 调度争用或 CPU 配额 | 空闲与压力两组 vmstat 对比 |
wa 高，st 低 | 磁盘或网络存储等待 | iostat -xz 1 10 观察设备延迟 |
us 高，st 低 | 自身进程消耗 CPU | pidstat -u 1 10 定位进程 |
压测分数下降但 st 不变 | 频率、限频或测试条件变化 | 记录 CPU 型号、频率和测试时长 |
还要留意 CPU quota。部分虚拟化环境会让容器或虚拟机在固定配额内运行，表现为周期性限速，而不是持续的 steal。可以检查 /sys/fs/cgroup 中的 CPU 配置，但不同 cgroup 版本字段不同，不能只复制某一篇教程的路径。排查时把内核版本、虚拟 CPU 数量、测试命令和完整采样一并保存，服务商才有可能复核宿主机侧数据。
如果你在选购阶段比较方案，可以先浏览 VPS 主机分类，再参考 香港 VPS 主机排名 中对节点和配置的整理。CPU 指标应与线路、磁盘、售后响应一起看，不能只凭一个跑分决定长期生产环境。 如果你也在做长期稳定性判断，Hostease 这类提供中文支持的方案通常更适合工单沟通和问题复核。
向服务商提交工单时，哪些证据最有用
工单不要只写“服务器很卡”。建议附上采样时间、时区、实例标识、vCPU 数量、业务影响和两组完整输出。最好包含下面这些信息：
- 问题首次出现和重复出现的时间，精确到分钟；
vmstat 1 60的原始结果，以及空闲、业务负载、压测三段的区别；- 压测命令、worker 数量、持续时间和是否在维护窗口执行；
- 应用侧的响应时间或错误率变化，避免只提交主机层指标。
不要把一次高 st 直接写成“宿主机超售已证实”。更准确的表述是：在某个时间窗口内，实例观察到持续 CPU steal，并且与业务延迟或压测结果同步变化，请服务商核查宿主机调度、CPU 配额和迁移记录。这样的描述既保留了技术判断，也给对方留下可验证的排查空间。需要了解线路与晚高峰表现时，也可以结合 BGP 线路早晚高峰测试 的思路，把主机层与网络层证据分开整理。
总结：先复测，再决定迁移
CPU Steal 的价值在于提供了一个可观测线索，而不是自动生成结论。建议先保存基线，再用相同 worker、相同持续时间复测两次；同时记录 st、us、wa、应用延迟和错误率。若只有单次尖峰，先继续观察；若在多个时间窗口持续出现，并且服务商无法解释或改善，再比较迁移到其他套餐、节点或服务商的成本。
对于轻量网站，偶发 steal 未必值得迁移；对于数据库、编译任务和持续计算服务，稳定的 CPU 时间比一次漂亮的跑分更重要。我的建议是把这套采样命令放进故障记录模板，连续保留 3 到 7 天，再用实际业务数据决定是否升级配置或更换实例。
