凌晨巡检时，一台 VPS 空闲响应很快，CPU、内存也都没满；可一跑持续压测，请求便开始超时。运维者容易把这种“空闲正常、忙时失速”归咎于套餐配置，却忽略宿主机抢占、磁盘队列争用，或测试负载已超过实例能力。空闲快照只能证明当时没忙，不能证明资源够用。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：webssss（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
VPS 的 CPU 时间通常分为来宾执行、CPU Steal（被宿主机调度器拿走）和空闲三部分。空闲态任务不足，宿主机即使超售也未必暴露问题；持续负载占满可调度时间后，Hypervisor 抢回时间片，%st 才会升高。常见信号是 %us 不高、%st 突增，吞吐下降而延迟上升，说明可用算力被宿主机分走。
磁盘是另一条链路。请求未达到磁盘上限时，%wa（IO 等待）很低；宿主共享存储队列一旦拥塞，%wa、磁盘 await 和队列深度会同步抬高。但“等磁盘”不等于“磁盘慢”：宿主 SSD 可能正处理其他租户的 IOPS，测试也可能在一秒内制造过多随机写。不能凭单个 top 截图定案。
先固定 CPU、内存、并发、读写比例和测试时长，保存压测前、中、后三组数据，再用争用态压测对照空闲态。用 top、mpstat 观察 %st、%us 与 load，用 iostat 同步看 %util、await、队列深度和 IOPS。利用率 100% 也可能只是个人 VPS 的 IOPS 配额已满。
按顺序排除：负载升高后若 %us 接近上限、%st 接近零，任务耗时明显超预期，属于自身负载不足；若 %st 持续上升，降压后回落，且面板显示宿主 CPU 仍繁忙，倾向宿主资源争用；若 %wa 与 await 同时上升、利用率贴近上限，停掉部分 I/O 后延迟仍不恢复，再对照宿主存储指标，倾向磁盘 IO 等待或共享队列争用。队列高但利用率不满，也可能是在等待设备服务时间。
常见坑是把重启后的短暂空闲当证据，或拿不同并发、缓存状态的结果硬比。测试还要排除日志刷盘、备份、定时任务和宿主机迁移；随身服务器可留存连续采样与压测时间线，避免只截瞬时曲线。归因结论应写成“在某负载区间，某指标持续异常”，而不是笼统地说机器性能差。
判断 CPU Steal 时，连续性比单个峰值更重要。短暂 steal 可能来自 hypervisor 调度或宿主机维护；只有它随业务压力升高、跨多个采样窗口持续存在，同时 guest 的 run queue 堆积，才更支持宿主资源争用。可用 mpstat 采集 %steal，并与 pidstat、loadavg 对齐。若实例已吃满自身 vCPU，不能仅凭 steal 升高断定超售。
磁盘侧的 IO 等待不能只凭 iowait 定案。虚拟块设备延迟还可能包含宿主机调度、共享存储队列、后端盘争用和网络拥塞。应同时观察 iowait、util、await、队列深度与吞吐，用 iostat -x 区分“设备饱和”和“队列抖动”，再核对宿主及存储告警。性能瓶颈归因应按“现象guest宿主”建立证据链，先排除本机配额、内存回收和限速策略；缺少宿主遥测时，只给出概率结论。
争动态压测应复现真实负载，而不是用 stress-ng 同时打满所有资源。先测空闲基线，再以固定并发逐级加压，采集 %steal、run queue、iowait、await、吞吐、P95/P99 和错误率，每级保持足够时间并重复两轮。延迟上升而 guest 利用率未满、同时 steal 增长，才形成宿主争用的强证据。
对照实验要选择相邻但未争用的时段或规格，在相同请求量下比较 P95/P99、吞吐和资源曲线；测试前后留出恢复期，避免缓存、内存填充和后台任务污染结果。压测必须设置上限并可随时中止，优先采用影子流量或生产回放；不清楚共享资源边界时，不要用 fio 写满磁盘，否则会把测试制造的争用误判为宿主问题。
最终检查清单：①连续采样 %steal，并确认 run queue；②用 iostat -x 同看 iowait、util、await 和队列；③对齐业务延迟、吞吐、错误率及压测时间线；④核对 CPU、磁盘配额及云厂商宿主与存储告警；⑤在安全上限内做固定并发对照；⑥记录置信度与恢复结果，再决定迁移规格、调整并发或优化应用。
