VPS（虚拟专用服务器）跑分忽高忽低，很多人第一反应是带宽（网络传输容量）或磁盘 I/O 出问题，但真正拖慢网站、编译任务和数据库响应的，常常是 CPU Steal 时间。本文教你如何用 vmstat、top 和短时压力测试，把“邻居噪声”与自身程序负载区分开，避免只凭一次跑分就误判服务商。

先说结论：CPU Steal 不是普通 CPU 使用率，而是虚拟机想运行、却被宿主机暂时拿不出物理 CPU 时间片时产生的等待。偶发 1%-3% 不一定严重；连续多分钟高于 10%，并且伴随响应时间抖动，才值得重点追查。如果你正在选型，也可以先看 VPS主机 分类里的基础方案，再用同一套方法验证稳定性。

TL;DR：先用三条线判断，不要只看单次跑分

我通常用三条线判断 VPS（虚拟专用服务器）的 CPU Steal 是否影响业务：空闲观察、轻压观察、业务时段复测。空闲时 st 已经长期偏高，说明宿主机层面可能拥挤；轻压时 st 跟着飙升，说明争抢更明显；只有压测高、业务无感，则可能只是短时资源竞争。这个判断比“UnixBench 跑了多少分”更接近日常体验。

• 空闲 5 分钟：st 大多在 0%-3%，通常可接受。
• 晚高峰连续 10 分钟：st 多次超过 10%，要记录证据。
• 压力测试期间：us、sy 没满但 st 高，优先怀疑宿主机争抢。
• 业务验证：页面 TTFB 或数据库查询从 100ms 抖到 800ms，才算真实影响。

下面用一台 2 vCPU、2GB 内存、Debian 12 的小鸡做示例。命令本身不依赖某个品牌，适用于多数 KVM 或类似虚拟化环境。

CPU Steal 到底是什么，为什么论坛里经常吵

CPU Steal 时间可以理解成“虚拟机排队等 CPU”。在虚拟化环境里，VPS（虚拟专用服务器）看到的是 vCPU，但底层仍要落到真实物理核心。宿主机上同一时间如果有多个租户做编译、视频转码、数据库批处理，你的虚拟机就可能拿不到足够时间片，于是 Linux 把这段等待记到 st。

它和普通 CPU 高占用不同。普通高占用往往是你自己的进程把 CPU 用满，比如 php-fpm、mysqld 或爬虫脚本；CPU Steal 高则表示虚拟机想跑但宿主机调度不过来。前者可以优化程序，后者更多依赖节点拥挤程度、服务商资源分配和邻居负载。

这也是为什么同一台 VPS（虚拟专用服务器）白天感觉正常，晚上就卡。晚高峰时，其他租户跑备份、批处理、建站任务，宿主机争抢增加，你的 st 可能从 1% 突然上到 15%。如果你还同时用 WordPress、数据库和缓存插件，这种抖动会直接反映到后台加载速度。

第一步：用 vmstat 看 st，不要被 wa 和 id 带偏

vmstat 的好处是轻量、持续、容易复制给工单。建议先跑 1 秒间隔、持续 60 次，把输出保存下来：

vmstat 1 60

重点看最后几列：us 是用户态 CPU，sy 是内核态 CPU，id 是空闲，wa 是 I/O 等待，st 就是 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 492000  64000 720000    0    0     0     4  210  320  4  1 93  1  1
 2  0      0 489000  64000 722000    0    0     0     8  880 1250 45 4 35  1 15

上面第二行就值得关注：CPU 不是完全跑满，st 却到 15%。如果这种状态只出现 1-2 秒，可能只是瞬时调度；如果连续几十秒出现，跑分和站点响应都会抖。你可以同时打开 技术教程 分类里其他优化文章，对比自己的测试习惯。

第二步：用 top 交叉确认，不要把自身进程问题推给邻居

top 的第一行 CPU 摘要里也会显示 st。运行：

top -d 1

如果 st 高，同时进程列表里没有单个进程长时间占满 CPU，就更像宿主机争抢。反过来，如果 php-fpm、node、mysqld 已经把 CPU 打满，st 只有 0%-2%，那先别急着投诉邻居，应该先查自身应用。

这张表的价值在于减少无效争论。论坛里经常看到“某某 VPS（虚拟专用服务器）很卡”的帖子，但没有时间、命令、截图和业务指标，很难判断是超售、程序问题还是磁盘 I/O。把证据结构化，服务商也更容易复现。

第三步：用 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 秒后恢复；邻居噪声可能集中在某些时间段，比如每天 22:00-23:30；宿主机长期超售则更稳定地糟糕，白天、夜间、轻压、空闲都能看到偏高 st。

第五步：提交工单时怎么写，才不像情绪投诉

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

时间：2026-08-07 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%
诉求：请协助检查宿主机 CPU 争抢，或迁移到负载较低节点

这类描述比“邻居太吵”更容易得到处理。服务商如果认真，会查看宿主机负载、同节点异常用户和调度状态；如果多次提交证据仍无改善，就可以考虑迁移。对于重视中文沟通和跨境线路的用户，Hostease 这类带中文支持的服务商沟通成本会低一些，但最终仍要以实测数据为准。

常见误判：这些情况不一定是 CPU Steal

为了避免把所有卡顿都归因于邻居噪声，下面几类问题要单独排查。尤其是 WordPress 站点，插件、缓存、数据库慢查询对响应时间的影响，往往比 2%-3% 的 st 更明显。

• 磁盘慢：wa 高、iostat -x 1 中 await 偏高，优先查存储。
• 内存不足：free -m 可用内存低且 swap 频繁读写，先减插件或加内存。
• 网络拥塞：Ping/MTR 抖动明显，但 st 正常，去查线路和丢包。
• 数据库慢：单个 SQL 超过 1 秒，CPU Steal 只是放大器，不是根因。

我的建议：用连续证据决定是否迁移

总结一下，CPU Steal 时间不是越低越好到 0 才能用，而是要看它是否持续、是否可复现、是否影响业务。对于普通博客、小型企业站，偶发 3%-5% 通常不用紧张；对于电商、后台系统或高峰 API，连续 10% 以上就应该保留证据并沟通节点迁移。

推荐的执行顺序是：先空闲观察 5 分钟，再晚高峰观察 10-15 分钟，最后用 stress-ng 做 3 分钟轻压。三轮里只要有两轮出现明显 st 异常，并且业务响应同步变差，就不要再被单次高跑分迷惑。反过来，如果 st 长期正常，就把精力放到缓存、数据库和应用优化上，问题大概率不在邻居噪声。

如果你需要长期稳定跑 WordPress、跨境电商或小型 API，建议把这套命令作为验收清单：开机后测一次，晚高峰测一次，上线后一周再测一次。数据连续、口径统一，才是判断 VPS（虚拟专用服务器）值不值得续费的可靠依据。