凌晨值班，一台4核VPS只跑两项服务，CPU却贴近100%，请求延迟从80毫秒跳到数秒。重启无效，线程也不忙。此时归因“配置不足”很容易误判：vCPU可能正等宿主机调度，共享磁盘或网络也可能被其他租户挤占。
系统繁忙可能是业务吃满自己的算力，也可能是宿主机超售引发CPU、内存带宽、磁盘队列或网络端口争用。应把系统计数器、压力测试与性能指标关联放在同一时间轴，不能只看一次跑分。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：vpsdime（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
vCPU只是宿主机调度入口，/proc/stat中的steal表示虚拟机等待物理处理器的时间。若steal持续增加，而本机进程消耗未同步升高，算力更像被其他租户抢占。CPU steal监控应按相邻采样差值计算占比；这是识别宿主机超售的线索，但累计值不能独立定案。
负载队列深度比load average更可靠：可运行任务是已就绪却未拿到CPU，D状态任务可能卡在磁盘或网络。同步记录两类任务数、steal增量、切换次数和I/O等待；若队列变长且steal上升，CPU争用更可信。
内存超限会触发回收和抖动，共享存储繁忙常表现为高iowait、吞吐下降及尾延迟上升。还要排除任务偏慢、锁竞争和测试线程过多，避免把内部瓶颈误判成宿主机争用。
先建资源争用基线：空闲采样60秒，记录steal增量、运行队列、D状态任务、内存回收和磁盘延迟。再做固定时长、递增加载压测，每档留冷却时间，避免一次压满造成“自己制造队列”。
保存同一时间基准下的吞吐、P95/P99延迟、错误率和计数器。若CPU先升高，队列与延迟随后恶化，而steal稳定，多半是VPS自身算力不足；若steal先抬升，队列、节流或I/O等待随后变差，降到基线仍未恢复，更像宿主机超售或共享资源争用。
磁盘可用低风险读写复核队列、await与尾延迟，网络结合重传、丢包和出口流量。锁竞争会让CPU和系统调用上升，但steal通常不跟涨。测试应避开生产目录和高峰时段。
常见误判有缓存预热、平均值掩盖尖峰、采样间隔过长，以及把load average中的D状态全算作CPU排队。ServLlama可汇总计数器和压测时序。结论应写成“某负载区间内steal与队列同时越过基线”，而非笼统说机器差。
CPU steal监控反映的是 vCPU 已就绪却等待宿主机调度的时间。计算相邻两次采样的 steal 增量，再除以虚拟 CPU 总时间增量，得到争用占比。它比 guest CPU 使用率更接近宿主层压力，但持续上升也不能单独证明超售：宿主机迁移、暂停、虚拟化故障和突发备份都会制造尖峰。应在相同负载下重复观测，并保存秒级原始值，避免五分钟均值把短时剧烈争用抹平。
负载队列深度需要拆分可运行队列与阻塞队列。可运行线程持续堆积，通常说明算力供给不足；阻塞线程增加，则先检查共享存储、网络和锁等待。load average 还包含不可中断睡眠，不能直接当作队列长度。PSI 的 cpu.some、cpu.full、io.some 更适合确认任务是否因资源不足而停顿，其中 full 表示非空闲任务几乎全部受阻，比 some 更能反映严重争用。
性能指标关联必须使用同一时间轴。若 steal、cpu.full、运行队列同时抬升，业务 p99 延迟和上下文切换随之恶化，才形成较强的宿主机超售识别证据；若 cgroup 的 nr_throttled、throttled_usec 增长，更可能是配额限流；若 IO PSI 与磁盘 await 同步上升，应转向共享存储排查。固定并发、固定数据量与预热时间，至少连续采样十五分钟，并设置对照 VPS 或历史资源争用基线，避免拿不同业务负载直接比较。
基线应描述典型负载下的分布，而不是空闲时的漂亮数字。除平均值外，至少记录吞吐、错误率、p50、p95、p99、队列峰值、上下文切换和 IO await；每组测试重复三轮，并覆盖低、中、高负载及业务高峰。重启、扩容、宿主迁移后重新建立基线，防止环境变化被误判为资源改善。
可执行检查清单：①记录 vCPU、内存、cgroup 限额、邻居负载、宿主机迁移和平台维护事件；②每秒运行 mpstat -P ALL 1、vmstat 1、pidstat -u -d -w 1，同时保存 /proc/stat、/proc/pressure/* 与 cgroup v2 的 cpu.stat；③计算 steal 占比，以及 runnable、blocked 的 p95 和峰值；④将业务 p99、吞吐、IO await、网络重传按秒对齐；⑤在三个负载档各重复三轮，并与对照实例或历史基线比较；⑥当 steal 连续超过百分之五、cpu.full 抬升且 p99 明显恶化时先标记预警，核对迁移日志后再复测。阈值是排查触发器，不是所有业务的统一判定标准。
常见坑包括只看平均值、在低利用率时段抽样、把宿主机一次抖动直接等同于超售，以及忽略 cgroup 限流。还要排除应用 GC、锁竞争、磁盘限速和突发重传；若各指标方向矛盾，应标记为待观察，不要强行归因。
最终交付应包含原始 CSV、采样命令、指标时间线、归因结论与复测结果。只有超售迹象、队列堆积和业务退化在多个窗口稳定共现，才能确认共享资源争用，并据此决定迁移、扩容、调整限额或继续观察。
