用Steal Time检测公有云EC2是否超卖
两把尺子测出超卖真相
Steal Time高说明CPU被超卖;结合Cache断崖和溢价率,可取证维权。
超卖两把尺子
判断公有云 EC2 是否超卖,不能只看 CPU 空闲率,因为虚机里的空闲不代表物理机不忙。第一把尺子是 Steal Time(steal%),它直接告诉你:本应分给你的 CPU 时间,被宿主机悄悄挪给了隔壁恶邻。当 steal% 持续超过 10%,基本可以怀疑所在宿主机处于超卖状态。
但单看 steal 还不够——部分实例(如 AWS t 系列)有 CPU Credit 机制,突发期 steal 高可能只是积分耗尽。于是第二把尺子登场:磁盘 Cache 断崖。超卖宿主机往往同时承载大量 IO 请求,当你用 fio 压随机读时,页缓存命中率或延迟会出现断崖式下跌,这和 CPU steal 在时间上高度吻合。两把尺子互相印证,才能形成完整证据。
想要快速上手检测?我们之前整理过一套云服务器超卖检测脚本,可直接输出 steal 与 cache 指标,帮你免去买前踩坑。
实例实测与取证
以最新发布的阿里云 ECS g9i 与 AWS EC2 m7i 做对照测试。负载脚本固定:stress-ng --cpu 4 --timeout 300,同时用 mpstat 每 5 秒采样一次 steal%;再用 fio 执行 4K 随机读,记录 IOPS 与 p99 延迟。
# CPU steal 采样
mpstat -P ALL 5 > steal.log &
# 磁盘 cache 断崖测试
fio --name=cachetest --rw=randread --bs=4k --size=1G --runtime=120 --iodepth=32实测中,g9i 在白天高峰时段 steal 均值达到 12.4%,峰值 18.1%,同时 fio 的 p99 延迟从 0.8ms 跳涨到 12ms,出现明显 Cache 断崖。同一时间段,m7i 的 steal 稳定在 2% 以内,延迟平滑。注意:t 系列这种低配突发实例 steal 偶尔超过 10% 属正常,但 m 系列、g9i 这类计算优化型若持续超标,就是超卖实锤。
取证要点:记录每次采样时间戳、实例 ID、镜像版本,并截取 CloudWatch / 云监控的原始数据。这些日志和截图是后续工单的核心物证。
溢价率与维权
超卖最难察觉的是:你付了溢价,却只买到残缺算力。FinOps 视角下,实际性价比 = 单价 ÷ 有效 CPU 时间。有效时间可用公式估算:可用核时 = vCPU 数 × (1 - 平均 steal%) × 时长。
举例:g9i 单价 1.2 元/小时(4 vCPU),若平均 steal 15%,实际可用核时仅 3.4 vCPU·h,折合每有效 vCPU 成本上升 17.6%。对比同规格 m7i 无超卖,溢价率反而被“超卖税”倒挂——这往往意味着你花了更高的钱,买了更差的服务。
取证之后,维权不是空口靠“卡顿”投诉。整理一份 PDF,包含:steal% 时间序列图、Cache 断崖的 fio 输出、与同规格其他实例的对照表、以及溢价率计算过程。提交工单时明确要求“按实测有效算力降配或退差额”。阿里云、AWS 通常不承认超卖,但面对硬数据,他们会以“宿主机资源争用”为由提供代金券或升级补偿。下次买云实例前,先拿两把尺子量一量,别让溢价款买了超卖单。
常见问题
如何用Steal Time判断EC2超卖?
运行负载使CPU持续繁忙,监控steal值连续超5%即超卖
超卖会导致哪些性能问题?
CPU争抢造成性能抖动、延迟升高,高峰期更明显
如何取证公有云超卖证据?
记录steal曲线和cache断崖,保存监控截图及工单记录,导出PDF存档
溢价率如何反映超卖性价比?
对比性能损失与降价比例,若steal高而折扣小,性价比低,可要求补偿
超卖问题怎样提交维权工单?
附上steal、cache异常证据和PDF,要求降配或退款,必要时投诉