很多人遇到 VPS 变慢时，第一反应都是一样的：
- CPU 不够了
- 机器太垃圾
- 商家超售了
- 要不要赶紧升级配置
问题是，VPS 变慢并不一定等于“资源真的跑满了”。
有时候你看到的不是正常饱和，而是另一种更难判断的情况：throttling（被限制、被压速、被卡在某个上限）。
比如：
- CPU 一开始能冲很高，过一会儿突然掉到一个固定水平
- 磁盘测试无论怎么加压，IOPS 都死活上不去
- 网络标称 1Gbps，但 iperf3 永远卡在某个整齐的数值
- 业务很轻，延迟却突然变差，监控又看不出明显 CPU 满载
这类问题最麻烦的地方在于：
如果你把 throttling 误判成普通性能不足，就会在错误的方向上浪费很多时间和钱。
这篇文章就专门讲清楚这件事：怎么区分“真的跑满了”和“被平台或宿主层 throttle 了”，以及 CPU、磁盘、网络三层分别该怎么看。
很多排查一开始就跑偏，是因为把这两种情况混为一谈。
| 情况 | 你真正遇到的是什么 |
|---|---|
| Normal Saturation（正常饱和） | 业务真的把资源用满了 |
| Throttling（限速/限制） | 平台、配额、credits、QoS 或宿主层把你卡在某个上限 |
最直观的区别是：
- 正常饱和：资源占用会随着负载上升而线性逼近瓶颈
- throttling：性能会在某个阈值附近突然“撞墙”，并表现出很整齐的上限
- 你的业务越压越高，资源指标也同步升高，最后顶满 → 更像正常饱和
- 你的业务还想继续上去，但性能被卡在一个固定值 → 更像throttling
这也是整篇文章的核心：
先证明你是被限制了，再决定要不要升级、迁移或投诉商家。
下面这些信号，值得优先怀疑 throttling：
比如：
- CPU 长时间卡在某个固定 baseline
- 磁盘 IOPS 每次都停在差不多的上限
- 网络吞吐长期卡在某个固定档位
“整齐”本身就是一个很强的信号。
这很像 credits 用完后的表现：
- 前面有 burst
- 后面被打回 baseline
比如：
- CPU 使用率看起来不高
- 但响应时间开始抖
- 队列变长
- 系统卡顿感明显
这时不能只盯着 %cpu，要看 steal、iowait、credit 和吞吐上限。
正常抖动不会每次都这么整齐。反复撞在同一上限，通常说明限制是“规则性的”。
CPU 是最常见、也最容易误判的一层。
在虚拟化 VPS 场景里，steal time 是一个非常关键的信号。
它表示的是：
- 你的虚拟 CPU 本来想运行
- 但宿主机把时间片拿去给别的 VM 了
这通常意味着宿主层争用，而不是你的程序自己把 CPU 用满。
top
vmstat 1
mpstat -P ALL 1
重点看：
st/%st
%st接近 0：通常正常%st持续明显偏高：说明你在等宿主机让出 CPU
如果你的业务不算重，但 %st 一直高，这就不是“优化代码”能完全解决的问题。
AWS T 系列、Azure B 系列这类机器，本来就不是“永远全速”，而是：
- 平时攒 credits
- 需要时爆发
- credits 用完后回到 baseline
这时最典型的误判是：
“为什么前 10 分钟压测很猛，后面突然不行了？”
这未必是机器坏了，而可能是你把 burst 用完了。
- 开始阶段性能正常甚至很好
- 持续压力后掉到固定水平
- provider 监控里 credits 逼近 0
- 业务并没结束，但 CPU 上限已经像被盖住一样
us/sy很高- 负载上去时吞吐也上去
- 只是最后被真实算力顶住
这时候更像“机器不够用”，不是“平台在卡你”。
磁盘层最容易让人误会，因为很多人只看一个数：磁盘 MB/s。
但实际瓶颈经常不是顺序吞吐，而是：
- IOPS
- 延迟
- 队列深度
- 随机读写能力
常用命令：
vmstat 1
iostat -x 1
重点看：
%wa%utilawait
iowait 高，不等于一定是 throttling。
它只说明：
- CPU 在等 I/O
至于为什么在等，可能是：
- 盘真慢
- 队列太长
- 存储延迟高
- IOPS 被配额卡住
- 你继续加压，IOPS 却不再增长
- 延迟开始明显上升
%util很高，但吞吐不上去- 多次 fio 结果撞在同一个上限
fio --name=randwrite-test --ioengine=libaio --direct=1 --rw=randwrite --bs=4k --size=1G --iodepth=64 --numjobs=4 --runtime=120 --time_based --group_reporting
你要看的不是“单次跑了多少”，而是：
- 当
iodepth、numjobs提高后，IOPS 是否继续增长 - p95 / p99 延迟是否突然恶化
- 是随机读写卡住，还是顺序吞吐卡住
如果你不断加压，结果始终卡在一个相似阈值，就很像 I/O 配额或存储层限速。
网络层的误判最多。
很多人一看到“速度慢”，就直接归因到线路绕路、丢包、晚高峰。
这些当然常见，但还要考虑另一种可能：
- 平台本身对端口、实例、月流量、某类协议做了限制
## 服务端
iperf3 -s
## 客户端
iperf3 -c <server_ip> -R
如果你怀疑单流不准，可以再测多流。
- 单流卡在固定上限
- 多流也突破不了这个上限
- 不同时段多次测试都撞在同一档位
- 标称 1Gbps，但实测长期像被封顶在更低值
- 路由差
- 丢包
- 晚高峰拥塞
- 目标端本身慢
- 本地 ISP 问题
所以网络层一定要分两步看：
- 路径质量
- 吞吐上限是否规则性撞墙
如果只是高峰期波动，那更像拥塞；如果任何时候都卡在同一档位，更像限制。
有些不是实例层 throttle，而是业务策略限制，比如：
- 超过月流量后被限速
- 特定端口 / 特定协议被卡
- 邮件场景默认封锁 25 端口出站
这种就不是“宿主机抢占”，而是服务商策略层的限制。
如果你的应用真的把 CPU 顶满了，那叫资源饱和，不叫 throttling。
链路差、晚高峰、丢包、目标端慢，都可能让你感觉“像限速”。
也可能只是宿主存储本来就很忙，或者你的访问模式本身不友好。
跑分只是现象，不是结论。你必须结合：
- 指标
- 时间线
- 配额模型
- 多次复现结果
一起判断。
如果你现在就怀疑 VPS 被 throttle，可以按这个顺序来：
看：
- CPU 使用率
- load
- 内存
- iowait
- 网络吞吐
如果业务本身就很重，先别急着怪平台。
重点看：
- CPU 是否掉到固定 baseline
- IOPS 是否撞墙
- 吞吐是否总卡在固定档位
重点看：
- steal time
- credits
- provider 监控面板
- CPU：看持续压测后的表现
- 磁盘：用 fio
- 网络：用 iperf3
不是只跑一次，而是：
- 不同时段跑
- 换压力档位跑
- 看是否总撞同一上限
如果确认是 throttling，再考虑：
- 升实例规格
- 换非 burstable 机型
- 迁移商家/机房
- 联系服务商拿证据沟通
- 检查是否是 credits 用尽
- 换非 burstable 机型
- 避免长期高 CPU 任务跑在共享突发实例上
- 看当前盘类型和 IOPS 模型
- 检查是否需要更高规格存储
- 避免把高随机写数据库塞进低配共享盘
- 看套餐说明有没有流量/带宽/端口策略
- 区分线路差和规则限速
- 高吞吐业务尽量别跑在“便宜但网络策略很多”的套餐上
保留证据再提工单。
不要只说：
- “我感觉变慢了”
而要带上：
- 时间段
- 监控截图
- fio / iperf3 / vmstat / iostat 输出
- 多次复测结果
这样服务商才更难用模板回复把你打发掉。
下面这些业务特别容易被“看起来不大，实际很受伤”的限制坑到：
- 数据库服务
- 下载站
- 代理/网关/中转业务
- 高并发 API 服务
- CI/CD 构建节点
- 视频转码和批处理任务
因为这些场景对下面这些指标都很敏感：
- 稳定吞吐
- 尾延迟
- 持续 CPU 能力
- 随机 I/O
不是说它们一定会被 throttle，而是：
一旦被 throttle，体感会非常明显。
可能。比如 steal time 高、credits 用尽、I/O 等待严重时，体感会很差，但你看到的 CPU 使用率未必高得离谱。
看是否存在规则性上限。真正的饱和更像线性撞墙；throttling 更像被卡在某个整齐阈值。
不能。跑分只是线索，不是结论。要结合 steal、credits、iowait、fio/iperf3 复测结果一起判断。
先保留证据和监控结果，再决定是升级、换机型、迁移，还是拿着数据去找服务商沟通。
VPS 被 throttle 最难的地方，不是“怎么解决”，而是怎么证明你遇到的不是普通性能瓶颈。
整篇文章其实只想帮你建立一个判断框架：
- CPU 层：看 steal time、看 credits、看持续压测后的掉速
- 磁盘层：看 iowait、看 IOPS 是否撞墙、看延迟是否异常抬升
- 网络层：看吞吐是否规则性卡顶、看是否存在套餐或端口策略限制
一句话总结就是：
先分清“资源真跑满了”还是“平台把你卡住了”，再决定优化、升级还是迁移。
如果你现在已经怀疑自己的 VPS 被限速，别急着只跑一次测速脚本。真正有用的不是“我觉得它慢”，而是你能不能拿出一组足够清晰的证据，证明它慢得很有规律。