VPS的CPU使用率明明很低，为什么系统还是卡

跑top看CPU使用率，加起来还不到20%，系统却依然卡得像便秘，敲个命令都要愣一下才有反应。这种情况下大部分人会怀疑是自己的程序有问题，或者VPS的网络不行，其实真正的凶手可能一直藏在top输出的最右边，一个几乎没人会去看的数字里——%st。

那个被所有人忽略的列

top命令第三行会显示一串CPU相关的百分比，us（用户进程）、sy（系统进程）、id（空闲）、wa（等待IO）……最后还有一个st，绝大多数教程和攻略压根不提这个字段，因为它平时确实一直是0，久而久之大家都习惯性忽略它。

st是Steal Time的缩写。VPS本质上是一台物理服务器切出来的一小份，多台VPS共享同一颗物理CPU，虚拟化层（Hypervisor）负责给每台VPS轮流分配CPU时间片。st这个数字，说的是：你的VPS想用CPU的时候，物理CPU正忙着伺候同一台宿主机上的另一台VPS，你只能干等着——这段被迫等待的时间占总时间的比例，就是Steal Time。

也就是说，top里显示的CPU使用率20%，那是你的程序实际拿到CPU、真正在干活的时间；而st那个数字，是你的程序想干活但抢不到CPU的时间。两者加起来才是完整的真相——如果st常年飘在30%、40%甚至更高，就算你自己的程序看起来清闲得很，系统照样会感觉卡顿迟滞，因为大把时间都耗在排队等CPU上了。

这说明了什么

这个指标本质上是在揭超售的老底。VPS服务商在一台物理机上塞进去的VPS数量越多，单台VPS能实际抢到的CPU时间就越碎，st也就越容易被推高。低价VPS参数表上写着"2核4G"看着挺唬人，如果背后这台物理机被塞了几十上百台同规格的VPS，你写在纸面上的"2核"，实际能用到的可能连半核都不到。

怎么看这个数字

直接跑top，看第三行最后的st值，观察一段时间（至少看个几分钟，最好是业务负载高峰期看，闲时看基本都是0，看不出问题）：

top

想要一个更精确、可以脚本化记录的数字，直接从/proc/stat里算：

grep "cpu " /proc/stat | awk '{steal=$9; total=$2+$3+$4+$5+$6+$7+$8+$9; printf "Steal: %.2f%%\n", steal*100/total}'

判断标准

业内比较公认的参考线：Steal Time长期低于10%，基本不用担心，这是共享云主机的正常代价；如果持续超过10%、甚至维持半小时以上都下不来，说明这台VPS所在的物理机已经明显超卖，性能会实打实受影响。

还有个很实用的排查思路：如果你在同一家服务商开了不止一台VPS，st同时在所有机器上普遍升高，说明是你自己业务负载确实上来了，该加配置了；但如果只有某一台VPS的st异常飙高，别的都正常，那问题不在你，是这台机器所在的物理宿主机被商家超卖得特别狠，换一台机器（甚至换个数据中心）往往比自己排查半天更有效。

顺带一提

判断一台VPS靠不靠谱，st只是其中一个信号，结合VPS网络测速用什么工具最好里提到的带宽和路由测试、还有买之前用推荐几个IP工具查一下IP质量，三个维度放一起看，比单看跑分或者商家宣传页面上的参数表靠谱得多——毕竟纸面参数谁都能写得很好看，实际能不能用得起来，得靠这些藏在角落里的真实数字说话。