腾讯云CVM的CPU steal time升高是怎么回事？如何排查与优化

在云服务器性能调优中，CPU steal time 是一个很容易被忽略的指标。它不像 CPU 使用率那样直观，也不像内存溢出那样会直接报错，但它经常表现为一种非常诡异的现象：明明实例的 CPU 使用率没有满，业务的响应时间却偶发增加，甚至出现请求超时。要解释这个问题，需要从虚拟化调度说起。腾讯云 CVM 的不同实例规格在 CPU 调度策略上并不完全一致，因此 steal time 的实际表现也存在明显差异。

一、CPU steal time 到底在统计什么

CPU steal time 是虚拟化环境中特有的性能指标。在 Linux 系统中，内核通过 /proc/stat 文件暴露 CPU 时间分配信息，其中一列就是 steal。以 top 命令为例，输出中的 %st 表示虚拟机内的 vCPU 处于就绪状态、想要执行指令，但 hypervisor 没有把物理 CPU 调度给它，导致该 vCPU 只能等待的时间占比。这个等待时间对业务来说是有感知的，因为它会直接推迟线程执行，进而增加请求延迟。

在非虚拟化的裸金属服务器上，steal time 几乎始终为 0。但在云服务器中，同一台物理宿主机上会运行大量虚拟机。每个虚拟机的 vCPU 实际上只是宿主机上的一个线程，由 KVM 或类似的 hypervisor 调度到物理核上运行。如果宿主机上的物理 CPU 资源被多个实例争抢，某些 vCPU 线程就会被放到运行队列中等待。客户机内核会把这部分等待时间记录为 steal time，而不是 idle 或 iowait。

需要特别区分的是，steal time 与 iowait 不同。iowait 表示 CPU 空闲且系统有未完成的磁盘 I/O，通常是因为存储慢；而 steal time 表示 vCPU 本身有任务要跑，却被宿主机的调度器晾在一边。对于数据库、游戏服务器、视频转码等 CPU 敏感型业务，持续高于 5% 的 steal time 就可能导致明显的性能抖动。

二、腾讯云 CVM 不同实例规格的实测对比

为了观察腾讯云 CVM 上 steal time 的真实表现，我分别创建了一台标准型 S5 实例、一台突发型 T5 实例和一台轻量应用服务器。三台实例均为 2 核 4G 内存，操作系统使用 Ubuntu 22.04，测试工具安装 sysbench、stress-ng 和 sysstat。测试方法是同时跑满两个 vCPU，持续 30 分钟，并在另一个终端里每 5 秒采集一次 top 输出，记录 %st 的变化。

压测负载使用 stress-ng 的矩阵计算模式，目的是产生持续且稳定的 CPU 计算压力。采集命令如下：

# 启动 2 个 CPU 压力进程，持续运行 30 分钟
stress-ng --cpu 2 --cpu-method matrixprod --timeout 1800s

在另一个 SSH 会话中，用下面的循环记录 steal time 数据：

while true
do
  top -bn1 | grep '%Cpu' >> /tmp/cpu_steal.log
  sleep 5
done

从 top 输出中可以看到类似这样的内容：%Cpu(s): 45.0 us, 12.3 sy, 0.0 ni, 30.1 id, 0.0 wa, 0.0 hi, 0.1 si, 12.5 st。最后一项 st 就是本周期内的 steal time。为了更方便地观察每个 vCPU 的情况，我也会使用 mpstat -P ALL 1 30 来查看每个 CPU 核心的详细数据。

经过多轮测试，某次典型结果如下表所示：

从数据可以看出，标准型 S5 实例在 CPU 使用率接近跑满时，steal time 依然保持在很低的水平。这说明腾讯云对标准型实例的 CPU 调度有比较严格的 QoS 保障，宿主机上的资源争抢对它的影响较小。突发型 T5 实例则出现了明显的 steal time 升高，尤其在 CPU 积分耗尽之后，客户机内看到的并不是简单的 CPU 频率下降，而是调度机会被剥夺，st 指标迅速攀升。

轻量应用服务器的表现介于两者之间，但由于其底层共享程度更高，在邻居实例负载升高时，steal time 也会出现较大波动。这个结果很直观地说明了不同实例规格的 CPU 稳定性差异：如果业务需要长时间占满 CPU，选择突发型或轻量实例并不合适。

三、导致 steal time 升高的常见原因

第一种原因是宿主机 CPU 超卖。云厂商为了提升物理机利用率，往往会在一台宿主机上放置超出物理核数量的 vCPU。即使腾讯云标准型实例的 CPU 性能比突发型稳定，但在某些极端情况下，同一台宿主机上的多个实例同时跑高负载，仍然可能造成短时间的 steal time 尖峰。这种尖峰通常持续时间较短，但如果频繁出现，就需要关注。

第二种原因是突发型实例的 CPU 积分机制。腾讯云的 T 系列实例有基准性能和突发性能两个概念。以 T5 为例，它的 CPU 基准性能通常只有 20% 左右，当实例长期高于基准性能运行时，CPU 积分会被不断消耗。积分耗尽后，实例的 CPU 性能会被限制。但从客户机内部看，这种限制并不表现为内核频率降低，而是表现为 vCPU 线程经常得不到调度，因此 %st 会显著升高。

第三种原因是热迁移。云平台在运维过程中可能会对虚拟机进行热迁移，比如宿主机维护、硬件替换或者负载均衡。在热迁移的短暂窗口内，实例的 vCPU 状态需要同步，这会带来一次明显的 steal time 尖峰。这类尖峰通常几十秒内会恢复，但如果是敏感业务，也可能触发告警。

第四种原因是同一实例内部 vCPU 与宿主机物理核的绑定关系。在超线程架构下，两个 vCPU 可能恰好被调度到同一个物理核心的两个逻辑线程上。如果应用内部有大量线程切换或锁竞争，就会放大这种拓扑带来的性能损耗。不过这种情况更多表现为 user 或 system 时间增加，steal time 只是间接受到影响。

排查时可以先使用 top 或 htop 观察整体 %st，再用 mpstat -P ALL 1 30 查看每个 vCPU 的 steal time 分布。如果只有个别 vCPU 的 st 很高，而其他 vCPU 正常，可能说明调度绑定不均。如果所有 vCPU 同时升高，则大概率是宿主机层面的资源争抢或实例自身 CPU 限制。

还可以通过 sar -u ALL 1 30 采集历史数据，sar 的好处是输出格式固定，便于后续用脚本解析。下面是一个简单的采集脚本，可以每 5 秒记录一次平均 steal time：

#!/bin/bash
while true
do
  top -bn1 | awk '/%Cpu/{print $NF}' >> /tmp/st.log
  sleep 5
done

需要说明的是，腾讯云 CVM 的控制台监控默认不直接展示 steal time。用户如果需要长期监测，可以在实例内安装云监控 agent 并上报自定义指标，或者在实例内用 cron 定时执行采集脚本，把结果写入日志系统。

四、降低 steal time 的实例选型与优化策略

如果业务对 CPU 延迟非常敏感，最直接的办法是选择 QoS 更有保障的实例规格。腾讯云的标准型 S5、S6 以及计算型 C5、C6 实例，在 CPU 调度上通常比突发型 T 系列稳定得多。已经运行在突发型实例上的业务，可以观察一段时间内的 CPU 积分余额和 steal time 趋势。如果积分长期处于耗尽状态，说明当前规格已经不适合业务负载，应该考虑升级到标准型或计算型。

对于预算充足、且对性能稳定性要求极高的场景，可以使用腾讯云的专用宿主机 CDH 或者裸金属云服务器。专用宿主机可以整机独享，不需要与其他租户共享物理 CPU，自然也就没有来自邻居实例的 steal time 影响。裸金属云服务器则直接提供物理机，完全不涉及 hypervisor 层的 CPU 调度。不过这两种方案的成本较高，适合金融交易、大型数据库等关键业务。

在应用层面，也可以通过调整架构来减少对单实例 CPU 的依赖。比如把定时任务、批处理任务从在线服务实例中拆出来，避免业务高峰期跑满 CPU。使用消息队列削峰填谷，也能降低瞬时 CPU 压力。还可以通过弹性伸缩在后端实例 CPU 持续超过阈值时自动扩容，避免单个实例长时间满载运行。

监控和告警是避免 steal time 影响业务的重要环节。建议在实例内设置一个轻量级脚本，当最近 5 分钟内的平均 steal time 超过 10% 时发出告警。下面是一个简单的判断逻辑：

ST=$(top -bn1 | awk '/%Cpu/{print $NF}' | cut -d'%' -f1)
if [ "$ST" -gt 10 ]
then
  echo "steal time too high: ${ST}%"
fi

如果已经选择了标准型或计算型实例，并且业务负载没有明显变化，却频繁出现 steal time 异常升高，建议及时提交腾讯云工单。技术支持人员可以结合宿主机状态、邻居实例负载和热迁移记录，帮助定位具体原因。对于多数普通业务来说，只要选择合适的实例规格，并建立基本的监控机制，CPU steal time 通常不会成为瓶颈。

腾讯云CVMCPU steal time虚拟化性能修改时间：2026-10-06 17:52:25