凌晨跑压测时，吞吐降到基线六成，P99延迟翻倍，虚拟机内CPU使用率却只有七成。团队常把问题推给线程池或数据库，却可能忽略vCPU正在等待宿主机调度。本文以持续采样CPU偷取率为主线，对齐压测吞吐、延迟、上下文切换与I/O等待，区分宿主机资源争用、虚拟化性能损耗和应用瓶颈。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：servitro（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、偷取率记录的是“就绪却没跑”的时间
在虚拟机中，vCPU已经就绪却未获得物理CPU的时间通常记为steal time，可理解为“想运行却被调度器暂缓”的占比。它不是应用消耗的CPU，也没有固定上限。读取/proc/stat的steal项或mpstat的%steal时，要核对统计周期；短暂尖峰多是调度抖动，持续抬升才更指向超分配或邻居抢占。
固定并发、数据集和缓存状态，预热后连续采样5至30分钟，并保留每秒或每10秒的偷取率、吞吐与P99，不能只看总平均值，空闲窗口会稀释高压期争用。可用ServLlama持续记录并按测试阶段切分数据，减少人工抄数错位。
二、用压测基线和系统开销完成归因
先建立基线：同一镜像、参数与流量模型重复三轮，记录稳定区间的吞吐、延迟、%user、%sys、%iowait和%steal。测试时同步观察偷取率、压测曲线斜率和系统开销；只有时间同步且现象可复现，相关性才足以支撑判断。
若偷取率随并发升高，例如连续5分钟超8%，且吞吐下降、延迟抬升，而虚拟机内运行队列未显示业务线程耗尽，有权限时查看宿主机核心利用率和运行队列，更支持宿主机资源争用。若偷取率平稳但应用队列持续增长，应转查线程池、锁、GC与下游依赖。
虚拟化损耗未必伴随高偷取率。虚拟网卡、虚拟磁盘、时钟中断可能推高%sys或%iowait，即使%steal很低，尾延迟仍会抖动。与裸机或隔离环境做同负载对照，才能把设备与中断开销同业务代码分开。
常见误区包括把cgroup限流当成steal、用空闲均值代表忙时、只看CPU总量而忽略NUMA和存储等待。应用瓶颈应表现为偷取率稳定，用户态消耗或内部等待占主导，增加并发也不再提升吞吐。保留原始时序与配置，复盘才不会只剩“CPU高”的结论。
用持续性能采样定位宿主机资源争用
判断时先把CPU偷取率拆成瞬时峰值和持续平台。一次任务启动时的短暂抬升，可能只是宿主机调度延迟；只有连续多个采样窗口都明显高于该虚机的历史基线，才更像宿主机资源争用。在虚机内使用 mpstat -P ALL 1 30 观察各 vCPU 的 %steal，并同步记录吞吐、P99 延迟、上下文切换和运行队列。若延迟上升与偷取率上升同步，迁移到同规格但低负载节点后指标又明显改善，可优先怀疑物理节点过载或宿主机线程竞争。
宿主机侧应记录 CPU 利用率、运行队列长度、调度延迟、频率变化及宿主机自身的 %steal；若有权限，还要查看绑核、NUMA 节点分布、隔离线程和宿主机中断。跨节点 A/B 对照比单个节点的截图更有价值：同规格、同镜像、同并发在另一节点稳定，才能把问题从虚机内部配置中剥离出来。同一节点还应连续复测两次，并让采样覆盖完整业务周期；若偷取率只在特定时段升高，要对照宿主机备份、扫描、编译等后台任务。
校准压测基线并排除常见误判
压测必须做压测基线校准。固定镜像、规格、并发、参数和测试时段，先在空闲节点取得偷取率、CPU 频率和延迟基线，再逐级加压，并覆盖空闲、稳态、峰值三个阶段。不要套用统一的 5% 或 10% 阈值；不同云平台、虚拟化层和业务周期没有可直接照搬的标准。
最容易误判的是把 I/O wait、虚拟化性能损耗和 steal 混为一谈。%iowait 表示虚机等待设备，%st 才是 Hypervisor 报告的运行时间损失，两者不能互相替代。还要检查 vCPU 热插拔、实时迁移、绑核跨 NUMA 节点及宿主机中断风暴；不要仅凭 guest 汇总值下结论，必要时导出每个 vCPU 的原始计数，确认是否存在单个 vCPU 长期饥饿。
可执行检查清单：一，在虚机持续采样 %steal，按 vCPU 拆分并标记异常起止；二，同时采集吞吐、P99、运行队列和调度延迟，确认偷取率与性能曲线的相关性；三，在宿主机排查 CPU 饱和、NUMA、绑核、隔离线程和中断；四，固定基线后执行逐级加压及跨节点 A/B 测试；五，迁移或更换宿主机复测，保存配置、时间戳和原始日志。若偷取率恢复且业务指标同步回升，再结合宿主机资源争用、虚拟化性能损耗与持续性能采样结果定级并扩容，避免盲目调整虚机规格。
喜欢 
顶
难过
囧
围观
无聊
