凌晨业务高峰，VPS 的 CPU 使用率突然冲到 90%，接口延迟从 20ms 升到 300ms；重登、看门狗重启都不见效。更棘手的是，监控面板里“负载高”“磁盘忙”“宿主机慢”同时出现，值班者很容易把访客自己的流量误判成资源争抢。仅凭一个高 CPU 数字迁机，可能只是换了故障入口。要先回答：被延迟的是访客任务、存储请求，还是宿主机上的其他租户。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：novproxy（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
CPU Steal Time 表示虚拟处理器已经就绪，却被 Hypervisor 调度出去的时间。它不同于访客进程实际消耗的 user 和 system CPU； steal 持续升高，意味着宿主机上的其他任务、虚拟机或管理进程正在争夺物理 CPU。不过，steal 只能说明虚拟机获得了较少 CPU 时间，不能单独解释慢请求究竟卡在计算还是存储。
运行队列延迟记录任务从进入可运行队列到真正获得 CPU 的等待时间。若负载自然增加，队列变长通常伴随访客内部 user、system 占用上升，steal 却可能保持稳定；若 steal 与调度延迟同步升高，才更像宿主机资源争抢。I/O 等待则指向存储路径：进程因磁盘响应而处于不可中断等待时，CPU 可能并不忙，但应用请求仍会超时。三者必须放在同一时间轴上观察。
先做瞬时抖动排除。以 1 秒为原始采样，观察 30 秒、60 秒和 10 分钟三个窗口；steal 只出现一个短峰，运行队列延迟随后回落，且应用延迟同步恢复，通常是宿主机调度或后台任务引起的瞬时抖动，不应立即迁机。ServLlama 可汇总并保留这些时间窗口，便于把重启前后的曲线对齐。
再做访客负载识别。若 user 加 system 已接近 vCPU 上限、运行队列持续增长，但 steal 长期接近零，说明是访客自身的计算需求过载，迁到另一台宿主机未必改善，应先限流、扩容或检查进程。若 steal 连续多个窗口超过约 5%，同时运行队列延迟明显上升，并在排除宿主机超售、宿主机备份或宿主机存储任务后仍有相同趋势，才可判定为 Hypervisor 资源争抢。阈值只是复核起点，裸金属、共享型和突发型业务的基线并不相同。
最后分离I/O 故障。当 iowait 明显升高，而 steal 不高时，应检查虚拟磁盘队列、宿主机磁盘利用率和延迟，不要把存储阻塞归咎于 CPU 争抢。若三项指标同时恶化，迁机前先做数据备份和磁盘一致性检查，再切换至宿主机负载较低的新实例，并在切换后继续观察至少三个性能采样窗口；若延迟再次随 steal 升高，迁移结论才更可靠。
进一步判断时，不能只看 CPU Steal Time 的高低，还要确认等待发生在哪一层。来宾线程可能先被宿主调度器延迟，再被来宾内核延迟；两者叠加后，进程响应会出现调度抖动，但未必都能反映在 steal 统计中。可同时读取 /proc/pressure/cpu 的 some avg10、avg60、avg300：短窗口用于捕捉尖峰，长窗口用于确认持续压力；再结合 vmstat 的 r 列、mpstat 的 %steal 与 perf sched 得到的调度延迟交叉验证。若 steal 上升而宿主仍有余量，应优先检查Hypervisor资源争抢、突发迁移与超售；若来宾的运行队列延迟长期累积，则先排查 vCPU 数量、线程绑定、锁竞争及内存回收。
宿主没有暴露监控时，可通过对照实验缩小范围：在相同业务负载下比较普通共享实例、具备 burst 能力的实例或独占核心实例，并记录试验时间、实例规格、宿主区域和 vCPU 配置。不要把一次 top 截图当结论，也不要只比较平均 CPU；应关注 p95、p99 延迟以及任务是否在固定周期出现长尾。
最容易踩的坑是性能采样窗口设置错误。1 秒采样容易把迁移、宿主机维护或邻居突发误判为常态；10 秒适合观察突发，60～300 秒更能反映持续争抢。固定平均值会掩盖短时严重抖动，因此要保留峰值、持续时长和发生时间，并让采样窗口覆盖一次完整业务周期。嵌套虚拟化、不同 hypervisor 的 steal 计数口径也可能不同，甚至出现漏计；发现数值为零时，不应直接认定没有争抢。
执行检查可按以下顺序：①保存空闲基线，并确认监控代理自身没有占用；②在故障时段同时采集 vmstat 1 10、mpstat -P ALL 1 10、PSI、磁盘等待和网络重传；③对照业务日志标记尖峰，检查 steal、运行队列和调度延迟是否同步上升；④做可重复压测，分别调整并发、vCPU 与绑定策略；⑤若怀疑宿主争抢，升级工单并索取宿主机调度、迁移和邻居负载数据；⑥设定告警时同时使用阈值、连续时长和采样窗口，避免单点抖动触发。
最终结论应是可复现的因果链：负载升高导致运行队列堆积，宿主争抢使 steal 与调度延迟同步上升，切换资源方案后长尾随之消失。只有时间对齐、指标互证且实验可重复，才能把“感觉慢”判定为真正的VPS虚拟化争抢性能问题。
