凌晨告警显示，某台VPS的steal time从2%升到12%，P99延迟随即翻倍。运维容易判定“宿主机抢CPU”，但实例任务突增、虚拟化暂停误分类或采样偏移也会产生相似曲线。跳过基线核对，迁机或重启只会暂时藏起症状。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：vultr（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
steal time不是实例“没用到的CPU”，而是vCPU应执行时未获得宿主机物理CPU、被其他宿主任务占用的时间。系统通常以虚拟CPU时钟差值除以采样窗口。12%表示窗口内约12%的时间存在调度等待；它说明vCPU缺少执行机会，却不能单独证明宿主长期超卖。宿主资源争抢、高负载和虚拟化调度延迟都可能反映其中。
排查先保留三个基线：正常期steal均值与峰值、vCPU数量和利用率、请求延迟分布。ServLlama可按固定间隔记录这些字段，确认12%是台阶还是尖峰。steal升高时vCPU若已接近100%，实例自身也在排队；若利用率低而延迟同步升高，调度等待更可疑，但仍需排除宿主争抢和监控误差。
宿主机资源争抢通常伴随宿主CPU利用率、运行队列或调度延迟一起抬升；实例内load可能升高，用户态和系统态却未吃满额度。多台相邻VPS同一分钟同向变化，比单台尖峰更支持共享宿主争抢，迁机后异常消失也是强证据。无宿主权限时，应索取对应时段记录并用业务结果复核。
实例自身过载的关键是额度不够：进程运行队列拉长，用户态、system和上下文切换增加，CPU性能基线下降。此时steal即使为个位数，延迟也会恶化，两者也可并存。监控采样误差多见于采集暂停、计数器回绕、缺失值补零、停机时钟跳变或混拼统计周期。应更换采样间隔，对照云监控与top中的%st，并用pidstat和独立探针复核CPU与请求耗时；系统工具与平台长期不一致且业务延迟未同步变化时，先修采集链路。
不要用单个steal阈值定责。统一时间窗后，按“vCPU是否用满宿主队列是否拥塞业务是否受损监控源是否一致”逐层排除，才能区分虚拟化调度延迟、宿主机资源争抢、实例自身过载与监控采样误差。
steal time 表示虚拟 CPU 已就绪，却因 hypervisor 把物理 CPU 调度给其他任务而未运行。它不同于 guest 的空闲、磁盘等待和网络等待。因此，高值首先指向虚拟化调度延迟与宿主机资源争抢，不能直接等同于应用计算性能差。
持续升高常见于宿主机 CPU 超售、运行队列过长、宿主机高优先任务或同机租户突发负载；瞬时尖峰还可能来自虚拟化迁移、维护操作和频率调节。应将 guest 的 load、runnable 数量、steal 增量与宿主机 CPU 利用率、运行队列按同一时间轴对齐。若 guest 并不繁忙，而 steal 与宿主机负载同步升高，才更像平台侧争抢。排查中不要盲目增加 vCPU：更多可运行线程可能让宿主机排队更严重。
CPU 性能基线必须控制变量：在相同实例规格、镜像、配置、负载和时段下先预热，再跑至少三轮，记录吞吐、P95/P99 延迟、steal 比例及其分位数。最好选取同规格对照实例，并保存未聚合的原始计数器。判断“变慢”时，先确认负载和参数未变，再比较基线，避免把应用发布、缓存失效或流量变化误算成 steal 问题。
监控链路也会制造假异常。低频抓取会漏掉短峰，失败抓取可能被补零或沿用旧值，Exporter 计算 rate 又依赖相邻样本；聚合后的平均值会抹平尖峰，max、sum、rate 的口径也可能不同。还要检查采集端负载、时钟偏差、数据队列积压和实例迁移记录。这些都属于监控采样误差，应先修正，再讨论宿主机责任。
可执行检查清单：①以 1～5 秒粒度对齐 guest 与宿主机指标，保留原始 steal 计数；②确认 guest 是否 runnable、是否存在应用限速；③固定负载做三轮以上对照，记录吞吐、P95/P99 与 steal；④比较不同 vCPU 数或可用区时，每次只改一个变量；⑤核查宿主机超售、迁移和维护记录；⑥验证无应用瓶颈后，迁移实例或改用独享、预留型规格；⑦若仍异常，整理实例 ID、节点、时间戳及原始指标提交服务商。
最终不要用“steal 超过某阈值就扩容”作为结论。只有在基线稳定、采样可靠、guest 无自身瓶颈，且能找到同时间段的宿主机调度证据时，才应把问题归因于虚拟化层，并优先调整实例落点或资源保障。
