VPS（虚拟专用服务器）偶尔卡顿时，很多站长会先怀疑带宽（网络传输容量）或磁盘，但 CPU Steal 时间同样会让后台、编译任务和数据库响应变慢。本文想解决的不是“跑分能拿多少”，而是一个更实际的问题：如何用 vmstat 与短时压力测试判断是不是节点争抢，而不是把自身程序问题误认为“邻居噪声”。

测试环境可以很普通：2 vCPU（虚拟中央处理器）、2GB 内存、Debian 12，连续观察 5-15 分钟就能拿到第一轮证据。选购前也可以先看一眼 VPS主机 分类，再用同样命令验证新机器，结果会更有参考价值。

先给判断线：st 持续高才值得处理

CPU Steal 的 st 不是普通 CPU 使用率，而是虚拟机想运行、宿主机暂时没有分配到物理 CPU 时间片。偶发 1%-3% 通常不用紧张；连续 10 分钟多次超过 10%，并且业务响应同步变慢，才需要保留证据并联系服务商。

我一般先看四个信号：

• 空闲观察：vmstat 1 300 中 st 大多 0%-3%，通常可接受。
• 晚高峰复测：22:00-23:30 连续出现 10%-20%，更像节点争抢。
• 业务对照：后台 TTFB 从约 200ms 抖到 1s 以上，说明已影响体验。
• 自身排除：top 没有单进程吃满 CPU，才继续看宿主机层面。

这条线能减少论坛里常见的口水争论。只贴一句“机器很卡”没有意义；把时间段、命令和业务响应放在一起，才方便其他人复盘，也方便服务商查节点负载。

第一轮：用 vmstat 把 st、wa、id 分开看

vmstat 是排查 CPU Steal 最顺手的命令，因为它输出轻、间隔固定，复制到工单里也容易看懂。建议先不要跑压测，直接在业务空闲和晚高峰各采一次：

date
uptime
vmstat 1 300

看结果时重点盯最后五列：us 是用户态 CPU，sy 是内核态 CPU，id 是空闲，wa 是 I/O 等待，st 才是 CPU Steal。很多误判来自把 wa 和 st 混在一起：wa 高更像磁盘、网络存储或数据库写入卡顿，st 高才更接近宿主机 CPU 争抢。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 520000  61000 730000    0    0     0     4  220  330  5  1 93  1  0
 2  0      0 516000  61000 731000    0    0     0     8  760 1120 38 4 41  2 15

上面第二行的信号就比较明确：us 没有满，id 仍有空闲，但 st 已到 15%。如果只出现一两秒，可以继续观察；如果 300 行里几十行都接近这个水平，就要把原始输出保存下来，而不是只截一张异常瞬间的图。

第二轮：用 top 交叉确认，先排除自身负载

top 的作用不是替代 vmstat，而是确认卡顿到底来自你自己的进程，还是来自宿主机争抢。运行时重点看 CPU 汇总里的 st，再看进程列表里有没有单个进程长期占满 CPU：

top -d 1

如果 st 高，同时进程列表里没有明显“吃满 CPU”的进程，就更像宿主机层面的资源争抢。反过来，如果 php-fpm、node、mysqld 已经把 CPU 打满，st 只有 0%-2%，那就先别急着把锅甩给邻居，应该先查慢查询、任务队列和插件。

这一步最容易犯的错，是看到网站慢就直接投诉节点。实际上，缓存没开、数据库索引不对、备份任务在跑，也会让体验变差。先确认自身负载，再去看 st，顺序不能反过来。

第三轮：用 stress-ng 做短压，观察 st 是否同步上升

如果空闲观察不明显，可以做一个短时轻压。这里不建议跑太久，尤其是低价小鸡，2-5 分钟足够观察趋势。先安装工具：

apt update
apt install -y stress-ng sysstat

假设机器是 2 vCPU（虚拟专用服务器中的虚拟 CPU），可以先用 1 个 worker 做轻压：

stress-ng --cpu 1 --timeout 180s --metrics-brief

另一个窗口同时跑：

vmstat 1 180

判断时不要只看压测工具分数，要看 st 是否跟着压力同步升高。如果 us 上升到 45%-55%，st 仍保持 0%-3%，说明宿主机调度还算从容；如果 us 只有 35%，st 却长期 15%-25%，说明虚拟机拿不到应有时间片，节点争抢的概率就高了。

这类测试特别适合留证据：

• 轻压前记录：date; uptime; vmstat 1 10，证明测试开始时间。
• 轻压中记录：保留 180 行 vmstat 输出，避免只截取异常 1 秒。
• 轻压后记录：看 load average 是否快速回落，判断是否残留任务。
• 业务对照：同时访问一个静态页和一个数据库页，记录响应时间差异。

怎么区分节点争抢、磁盘等待和正常波动

“节点争抢”说白了就是宿主机分给你的 CPU 时间片不够。它和磁盘等待、内存不足、网络拥塞不是一回事。最简单的判断方法是看持续时间和复现规律：正常波动通常是短暂的，1-3 秒后恢复；节点争抢更容易在固定时段重复出现；长期拥挤则是白天、夜间、轻压、空闲都偏高。

可以这样理解：

• wa 高但 st 低，优先查存储、数据库写入或慢挂载。
• st 高但 wa 低，优先怀疑宿主机 CPU 争抢。
• st 和业务抖动同步出现，说明已经影响到用户体验。
• st 偶发上升又迅速回落，多半只是短时调度波动。

如果你写的是 WordPress（内容管理系统）站点，这个区分尤其重要。很多页面慢并不是 CPU Steal 导致，而是插件太重、对象缓存没配好，或者数据库有慢查询。先把根因分开，后面的优化才不会跑偏。

提交工单时怎么写，才更容易被认真处理

工单不要只写“机器很卡”。更有效的写法是把时间、命令、持续时长、业务影响放在一起。比如：

时间：2026-08-17 22:10-22:25 UTC+8
机器：2 vCPU / 2GB RAM / Debian 12
现象：vmstat 1 900 中 st 多次维持 12%-22%
业务影响：WordPress 后台打开时间从约 300ms 上升到 1.5s-2.3s
已排除：top 未发现单进程长期占满 CPU，wa 维持 0%-2%
诉求：请协助检查节点负载，或迁移到更空闲的宿主机

这类描述比情绪化抱怨更有用。服务商如果认真，会去看宿主机负载、同节点异常用户和调度状态；如果你反复提供相同证据仍无改善，就可以考虑换节点。对于需要中文支持和更顺畅沟通的用户，Hostease 这类服务商往往更省事，但最终仍要以实测数据为准。

如果你正在准备长期跑站、跑 API 或做跨境业务，建议把这套排查步骤固化成模板：开机后测一次，晚高峰测一次，上线后一周再测一次。数据连续、口径统一，才是判断 VPS（虚拟专用服务器）值不值得续费的可靠依据。技术教程 分类里也有不少补充命令，WordPress 相关页面则适合对照真实业务场景。如果你需要更稳定的入门方案，可以再看一眼 Hostease 的相关介绍，结合自己的观测结果再做决定。