VPS是否被超售：一套自己能跑完的检测流程

一、超售到底是什么：先分清三种被卖的方式

超售不是偷工减料，而是同一套物理资源被卖给超过承载能力的租户。但"卖超了"这件事在 VPS 里有三种完全不同的形态，检测方法也完全不同，混为一谈就会得出错误结论。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一种是 CPU 超售。这是 VPS 最普遍的形式：宿主机有 32 个物理核，卖出去了 80 个 vCPU 的机器。每台机器的标称核数是真的，超的是总数。当宿主机负载升高时，你的 vCPU 会被调度器临时夺走，这就是 steal time。它表现为平时跑分正常、忙时变慢、延迟抖动变大。

第二种是内存超售。这一种的严重程度取决于宿主机是否开启了内存 ballooning 或过度分配。内存超售的典型症状不是立刻 OOM，而是可用内存长期低于标称值，且无法通过重启完全恢复。

第三种是带宽与流量超售。注意带宽超售和流量额度是两回事。带宽超售指的是端口能力被多人共享，你在晚高峰跑不满标称速率；流量额度则是套餐里写明的每月 GB 数，超出后会被限速、停机或按量补款。很多用户以为"跑不满带宽"是超售，其实那只是流量额度用完后被限速的结果——限速是你的账户状态决定的，不是宿主机资源争抢。

区分这三者的意义在于：CPU 和内存超售可以找商家协商甚至换机房，属于服务质量问题；带宽跑不满要先分清是共享争抢还是你被限速，属于两个完全不同的问题。很多纠纷之所以扯不清，就是因为把限速当成了超售。

先记住一个前提：VPS 的虚拟化方式决定了超售的形态。基于 KVM 的一体化商家通常用 CPU steal 表现超售；OpenVZ/LXC 类型的容器产品共享宿主机内核，超售时可能表现为更剧烈的延迟抖动而非典型 steal 曲线；NAT 小鸡只有转发端口，超售表现为带宽争抢而不是算力不足。检测前先确认自己的产品是哪一类，指标才有可比性。

还有一个必须先分清的概念：宿主机物理超售和单台机器配置缩水是两件事。前者是这台机器本身没毛病，只是整机负载高时抢不到时间；后者是商家给你的核数或内存本身就少于标称。前者会随时间波动，后者是稳定的。所以判断时不要只测一次就下结论，而是要在不同日期、不同时段各测一轮，两轮结果差异大说明是动态争抢，两轮都稳定地差则更可能是配置本身不实。

还有一个和商家沟通时的关键点：把"你的机器 steal 高"和"你的机器带宽不够"分开表述。前者是可量化的资源争抢，属于服务质量范畴；后者在很多时候是套餐额度和限速策略的结果，属于规则范畴。混在一起提，商家通常会用后者来解释前者，最终什么也解决不了。

二、steal time：最直接的 CPU 超售信号

steal time 是衡量"有多少时间你的 vCPU 想跑但被宿主机抢走"的原生指标，它由虚拟化层直接统计，不需要跑任何第三方脚本，是所有超售检测项目里最权威的一项。

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

在 Linux 上读取 steal time 最简单的方式是 top 命令。关键看%Cpu(s)行里的st字段：

`bash

# 持续观察 steal，5 秒刷新一次

top -b -d 5 -n 12 | grep -E "^%Cpu|^top"

`

输出里的 st 就是 steal 占比。判读标准很直接：空闲时 st 长期低于 1% 基本正常；持续在 1% 到 5% 之间属于轻度争抢，你多半感觉不到；稳定在 5% 到 10% 属于明显超售；超过 10% 已经是重度，机器在高峰期会明显卡顿。

如果 top 的精度不够，用 /proc/stat 直接计算，采样 60 秒得到一个加权平均值：

`bash

# 精确采样 steal time，60 秒窗口

grep -w cpu /proc/stat | awk '{print $2,$3,$4,$5,$6,$7,$8,$9}' > /tmp/cpu_before

sleep 60

grep -w cpu /proc/stat | awk '{print $2,$3,$4,$5,$6,$7,$8,$9}' > /tmp/cpu_after

paste /tmp/cpu_before /tmp/cpu_after | awk '{

total = $8-$1; idle = $5-$2; steal = $9-$6;

printf "总 CPU 时间 %.2f s，steal %.2f s，steal 占比 %.2f%%\n", total, steal, total>0 ? steal/total*100 : 0

}'

`

这个脚本的判读方式：跑分时段要有真实负载，否则 steal 会接近 0，什么也测不出来。所以正确的用法是让机器满载 60 秒，同时采样 steal：

`bash

# 一边压满 CPU，一边采样 steal

( for i in $(seq 1 4); do dd if=/dev/zero of=/dev/null & done; sleep 60; kill %1 %2 %3 %4 2>/dev/null ) &

grep -w cpu /proc/stat | awk '{print $2,$3,$4,$5,$6,$7,$8,$9}' > /tmp/cpu_before

sleep 60

grep -w cpu /proc/stat | awk '{print $2,$3,$4,$5,$6,$7,$8,$9}' > /tmp/cpu_after

paste /tmp/cpu_before /tmp/cpu_after | awk '{printf "steal 占比 %.2f%%\n", ($9-$6)/($8-$1)*100}'

wait

`

算出来的数字可以直接折算成损失。以 4 核机器为例：steal 5% 时等效 3.80 核，每月被偷走 144 核·小时，相当于满负荷 2880 核·小时中的 5%；steal 8% 时等效 3.68 核，每月损失 230.4 核·小时；steal 10% 时等效 3.60 核，每月损失 288 核·小时；steal 12% 时等效 3.52 核，每月损失 345.6 核·小时；steal 25% 时等效只有 3.00 核，每月损失 720 核·小时，相当于白白少了整整一个核的满负荷时间。

这里有一个重要的量级感：steal 5% 在日常使用中几乎无感，因为你的应用本来也用不满 4 核；但在编译、批量任务、爬虫这类突发负载下，它会让"4 核"变成"3.8 核"的真实差异，而且这个差异在你交年费的时候是按 4 核计价的。

三、CPU 跑分对比：和同配置基准机比，别和跑分榜比

steal time 告诉你"被抢了多少"，CPU 跑分告诉你"你实际拿到的算力有没有缩水"。两者结合，才能区分"被抢"和"本来就少"。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

跑分的关键不在于跑出多高的绝对分，而在于和一台同配置的正常机器做对比。没有基准机时的替代方案是：同一商家不同机房的同款配置互相比，或者同一台机器在不同时段对比（夜间 vs 晚高峰），后者尤其能暴露争抢。

跑分工具的选择上，Geekbench 的闭源性质决定它对商家有天然的偏好，Passmark 和 sysbench 这类开源工具更中立一些。实际操作时，两个工具都跑一遍更有说服力。

`bash

# 用开源工具做多轮 CPU 跑分，取中位数而非单次最高值

for i in 1 2 3 4 5; do

sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=20 run 2>/dev/null \

done

`

判定时用"达成率"这个概念：达成率等于实测分数除以标称配置应有的基准分。4 核机器跑分达成 65%，等效只有 2.60 核；2 核机器达成 57.5%，等效 1.15 核；8 核机器达成 77.5%，等效 6.20 核。

这里必须提醒一个陷阱：单核跑分和多核跑分要分开看。有些 VPS 的多核扩展效率很差，标称 4 核但多核跑分只有单核跑分的 1.8 倍而不是接近 4 倍，这种情况下加钱升级核数是无效的，因为瓶颈在共享调度上。所以每次跑分都要记录两个数：单线程得分和多线程总得分，两者一起看才能判断问题出在哪。

判读阈值可以这样定：单线程达成率低于 60% 且多线程达成率也低于 65%，判定为算力不足；只有多线程低而单线程正常，判定为超售争抢或调度受限；两者都正常但 steal 高，判定为纯粹的宿主机争抢。

还要注意 CPU 频率的影响。有些 VPS 商家的标称核数是按满速基准频率算的，而实际分配给你的 CPU 在竞争激烈时会被降频执行。这时候 steal time 可能并不高，但跑分依然偏低。所以完整的三元组应该是：单线程分数、多线程分数、steal 百分比。三者的组合能区分三种不同的问题——steal 高是抢占，单线程低是降频或弱算力，多线程低且单线程正常是核数不实或扩展效率差。

另外跑分时务必固定变量：同一个版本、同一组参数、同一时段、同一台机器上重复 5 次取中位数。取最高分是自欺欺人，超售机器的特征恰恰是波动大而非峰值低，所以中位数比峰值更能反映真实水平。

四、4K 随机写 IOPS：磁盘是不是在共享

内存和 CPU 的问题用软件就能测出来，磁盘超售只能靠 IOPS 测试暴露。这类问题最阴险，因为表现是"慢慢变慢"而不是"突然崩"，用户往往几个月后才发现自己开的数据库越来越慢。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

随机写 IOPS 是衡量磁盘真实能力的标准指标。用 fio 测 4K 随机写，指定块大小 4 KB、队列深度 32、随机写模式：

`bash

# 4K 随机写 IOPS 测试，写 8 GB，输出 JSON 便于对比

fio --name=randwrite --ioengine=libaio --direct=1 \

--filename=/tmp/fiotest --size=8G --bs=4k --iodepth=32 \

--rw=randwrite --runtime=120 --time_based \

--group_reporting --output-format=json > /tmp/fio.json 2>/dev/null

grep -E '"iops"|"latency"' /tmp/fio.json | head -6

`

判读时要做达成率换算，因为不同商家标称的磁盘类型不同。以 NVMe 为例，标称 15000 IOPS 的机器实测 8200，达成率 54.7%；标称 20000 实测 11000，达成率 55%；标称 30000 实测 14000，达成率 46.7%；标称 50000 实测 46000，达成率 92%，这个数字说明磁盘本身没问题。

达成率低于 60% 有两种可能：磁盘被换成低速盘（机械盘或共享的云盘），或者磁盘确实在共享。这两者要靠另一个指标区分：看 await（平均请求等待时间）的劣化倍数。await 从 1.5 毫秒劣化到 12 毫秒是 8.0 倍，从 2.0 劣化到 16.0 也是 8.0 倍，从 3.0 劣化到 25.0 是 8.3 倍。当 IOPS 和 await 同时按接近的倍数劣化，说明是持续性的资源争抢；如果 IOPS 低但 await 正常，说明磁盘本身是慢的而不是被抢的。

还有个更直接的判据：磁盘队列深度。看 /proc/diskstats 的 aqu-sz 或者用 iostat 的 avgqu-sz：

`bash

# 观察磁盘队列深度与利用率，空闲时应接近 0

iostat -x 1 10 | awk '/Device|disk|sda|vda|nvme/ {print}'

`

写入高峰期 avgqu-sz 长期高于 1 且 %util 接近 100，而你的业务写入量并没有那么大，就是磁盘被别的租户占住的典型信号。

五、晚高峰带宽：为什么你必须在 20:00 到 23:00 测

带宽检测必须踩在晚高峰，否则测出来的永远是虚标。国际出口和骨干链路在 20:00 到 23:00 承担绝大部分国内用户的出境流量，这个时段的拥塞程度和凌晨完全是两个世界。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

测法很简单：找一个大文件做持续下载，用 curl 记录传输速率。

`bash

# 下载 500 MB 测试文件，观察平均速率

curl -o /dev/null -w "平均速率 %{speed_download} B/s，耗时 %{time_total} s\n" \

-s "https://speedtest.example.com/500mb.bin"

`

测速要选对目标。用商家自带的测速文件不行，因为那通常是本地内网，不走公网出口。应该用几个不同的海外测速源分别测，取中位数，避开单一目标的网络抖动。

判读方法是看达成率而不是绝对值。10000 Mbps 端口的机器，晚高峰跑到 1200 Mbps 是端口能力的 12%，同一台机器夜间能跑 8600 Mbps 是 86%；2000 Mbps 端口的机器晚高峰 240 Mbps 是 12%，夜间 1700 Mbps 是 85%；500 Mbps 端口的机器晚高峰 62 Mbps 是 12.4%，夜间 430 Mbps 是 86%。

这里有一个非常值得注意的规律：三组数据在晚高峰都掉到了约 12%，而在夜间都能跑到 85% 到 86%。这种整齐一致的下降比例，指向的是共享出口的统一拥塞，而不是某一台机器被特殊对待。同时也要注意另一个可能性：如果你的月流量额度已经用满，商家会直接做端口限速，这时无论什么时间测都是同一个值。所以测试前一定要先查流量用量。

丢包率要和带宽一起看，它对建站的影响是独立于带宽的。一次 HTTP 请求大约涉及 5 个往返，丢包 0.5% 时每个请求期望额外重传 0.03 次，1000 并发请求每秒会多出 25 次重传；丢包 2% 时期望额外重传 0.10 次，1000 并发下每秒多 100 次；丢包 5% 时期望额外重传 0.25 次，每秒多 250 次。这些额外重传不仅拖慢响应，还会吃掉你本就不宽裕的带宽额度。

测丢包用连续的 ping 采样，看丢包比例和抖动：

`bash

# 晚高峰连续 ping 300 个包，统计丢包与延迟抖动

ping -c 300 -i 0.2 目标IP | tail -3

`

带宽测试还有一个容易忽略的前提：测试本身要避开缓存命中。测速节点和你的机器之间如果经过 CDN 或者有本地镜像缓存，测出来的速率反映的是缓存而不是你的端口能力。选测速源时优先选没有 CDN 缓存的独立对象存储或直连地址。

带宽和流量额度之间还有一个必须算清的账。以公开年付套餐里的一条洛杉矶产品线为例，LAX-STARTER 的端口是 2000 Mbps、月流量额度 5000 GB，用满这 5000 GB 额度需要持续占用 15.4 Mbps，只占端口能力的 0.8%。LAX-MEDIUM 是 10000 Mbps 端口配 20000 GB 额度，用满需要持续 61.7 Mbps，占端口 0.6%。LAX-LARGE 是 10000 Mbps 配 40000 GB，用满需要持续 123.5 Mbps，占端口 1.2%。

这组数字说明一件事：流量额度和端口带宽根本不是一回事，端口标称 10000 Mbps 看着很大，但你的月度额度其实只够你以平均 123.5 Mbps 的速度跑满一整个月。反过来，如果你真的以端口满速跑，LAX-STARTER 只能跑 5.56 小时就超额度，LAX-MEDIUM 是 4.44 小时，LAX-LARGE 是 8.89 小时。看到端口数字就以为"可以随便跑"的人，往往在月中被限速。

六、内存实际可用量：别被标称内存骗了

内存是最容易被误导的指标，因为标称内存和实际可用内存之间存在三个扣减来源：宿主机保留、宿主机自身开销、以及分配给你的内存里没被释放的部分。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

先看裸数据怎么读：

`bash

# 三种方式交叉验证内存可用量

free -m

cat /proc/meminfo | grep -E "MemTotal|MemAvailable|Cached|Buffers"

# 排除内核缓存后的真实可用

awk '/MemTotal/{t=$2}/MemAvailable/{a=$2}/^Cached:/{c=$2}END{printf "标称 %.0f MB，可用 %.0f MB，扣除缓存后约 %.0f MB\n", t/1024, a/1024, (a)/1024}' /proc/meminfo

`

判读标准：可用率 87.9% 属于正常范围；83% 处于可接受但偏低；73.2% 就明显偏低了。以 2 GB 机器为例，标称 2048 MB 实测可用 1700 MB 是 83.0%，缺口 348 MB；实测可用 1500 MB 就是 73.2%，缺口 548 MB。4 GB 机器实测可用 3400 MB 是 83.0%，缺口 696 MB；实测可用 3000 MB 是 73.2%，缺口 1096 MB。

注意内存超售有一个特征和 CPU 超售不同：CPU 超售是动态的（忙时抢、闲时不抢），内存超售是静态的（一直少）。所以内存只要在多次不同时刻测量都低于标称的 85%，基本可以判定，不需要挑时间。

还要区分两种内存超售的成因。第一种是宿主机物理内存不够，触发了 swap 或内存回收，这是全局性的，表现为所有机器一起变慢。第二种是这台机器被分配了超过宿主机单机能承载的份额，通常表现为你的机器内存占用莫名其妙地高但你并没有开多少服务。

`bash

# 观察 swap 活动与内存回收压力

vmstat 1 10

grep -E "pswpin|pswpout" /proc/vmstat

# pswpin/pswpout 持续增长 = 宿主机在换页，你的机器会被拖慢

`

七、两项以上异常即可判定：完整的判定规则

单独一项指标异常可能有各种偶然原因，判定超售的可靠规则是看多项指标的一致性。把前面的数据综合起来，可以用加权评分法：CPU 维度权重 0.4，内存维度 0.3，磁盘维度 0.3。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

按这个方法算三组典型数据：轻度场景 steal 5%、内存可用 90%、IOPS 达成 75%，综合得分 87.5 分，属于轻度争抢；中度场景 steal 8%、内存 83%、IOPS 55%，综合得分 78.2 分，属于明显超售；重度场景 steal 12%、内存 73%、IOPS 47%，综合得分 71.2 分，属于重度超售。

最终判定规则建议这样定：任意两项核心指标同时异常，判定为超售；核心指标是 steal time 超过 5%、CPU 跑分达成率低于 65%、4K 随机写 IOPS 达成率低于 60%、内存可用率低于 85%、晚高峰带宽达成率低于 30%。任意两项落在阈值外就可以去和商家交涉，理由充分。

还需要排除三类假阳性，否则容易白折腾：其一是测量时段不对，带宽必须在晚高峰测；其二是本机负载异常，先确认没有其他进程在抢资源再测；其三是宿主机层面的临时维护，间隔 24 小时再测一次，如果数值大幅回升，说明是短期波动。

一个实用的技巧是把检测脚本挂到定时任务里，连续采集一周，形成趋势曲线。单次超售可能是偶然，两次超售是运气，七天的曲线才能看出真实水位：

`bash

# 每 6 小时采集一次超售指标，一周后查看趋势

cat > /tmp/oversell_probe.sh <<'EOF'

#!/bin/bash

TS=$(date +%F' '%T)

ST=$(grep -w cpu /proc/stat | awk '{print ($9-$3)}')

MEM=$(awk '/MemTotal/{t=$2}/MemAvailable/{a=$2}END{printf "%.2f", a/t*100}' /proc/meminfo)

echo "$TS steal_raw=$ST mem_pct=$MEM" >> /var/log/oversell.log

EOF

chmod +x /tmp/oversell_probe.sh

(crontab -l 2>/dev/null; echo "0 */6 * * * /tmp/oversell_probe.sh") | crontab -

`

八、检测脚本：一条命令跑完全套指标

把前面的方法整合成一个脚本，可以在买下机器后第一时间跑完，直接输出判定结论。这个脚本需要 root 权限读取完整的 /proc/stat。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

`bash

#!/bin/bash

# oversell-check.sh —— VPS 超售综合体检

# 用法：bash oversell-check.sh

CPU_LOG=$(grep -w cpu /proc/stat)

sleep 60

CPU_LOG2=$(grep -w cpu /proc/stat)

STEAL=$(paste <(echo "$CPU_LOG") <(echo "$CPU_LOG2") | awk '{if (($8-$1)>0) printf "%.2f", ($9-$6)/($8-$1)*100}')

MEM=$(awk '/MemTotal/{t=$2}/MemAvailable/{a=$2}END{if(t>0) printf "%.2f", a/t*100}' /proc/meminfo)

CORES=$(nproc)

echo "===== VPS 超售体检报告 $(date +%F' '%T) ====="

echo "核数: $CORES"

echo "steal time: ${STEAL}% $([ "${STEAL:-0}" -gt 5 ] 2>/dev/null && echo '[异常]' || echo '[正常]')"

echo "内存可用率: ${MEM}% $(awk -v m="${MEM:-100}" 'BEGIN{print (m<85)?"[异常]":"[正常]"}')"

if command -v fio >/dev/null 2>&1; then

fio --name=rw --ioengine=libaio --direct=1 --filename=/tmp/_fio \

--size=4G --bs=4k --iodepth=32 --rw=randwrite --runtime=60 \

--group_reporting 2>/dev/null | grep -E "IOPS|await" | head -4

else

echo "fio 未安装，跳过磁盘测试（apt install fio / yum install fio）"

fi

echo "当前磁盘队列:"; iostat -x 1 3 2>/dev/null | tail -4 || echo "iostat 未安装（apt install sysstat）"

echo "结论：任两项异常即判定超售，请保留本报告作为与商家沟通的依据"

`

判读输出的方式：先看 steal 和内存两项，这两个是纯软件读取，零干扰，是最可信的证据。磁盘和带宽的部分需要机器上确实有压力才准，所以脚本里的 fio 只跑 60 秒，是保守估计值；正式判定前应当在自己有真实负载时再跑一次。

需要说明的是，脚本给出的是测量值而不是判决值。steal 超过 5% 只说明宿主机在抢你的 CPU 时间，至于是"轻度争抢"还是"重度超售"，要结合跑分达成率和业务的实际表现来判断。把检测报告留档，是你后续要求换机或退款时最有力的证据。

九、超售了怎么办：分场景的处置动作

检测出超售之后，处置方式取决于超售的类型和你的议价空间。盲目发工单要求赔偿通常收效甚微，因为商家会说"这是共享资源的正常波动"。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一种情形是轻度争抢，steal 在 5% 到 8% 之间，但你的业务跑得动。这时候最优解往往不是换商家，而是调整业务本身：给关键服务加 CPU 亲和性绑定、降低并发、把重计算任务挪到非高峰时段执行。这样做不需要换机，而且对多数建站和 API 业务是够用的。

`bash

# 给关键进程绑定到独立 CPU 核，减少被调度器迁移和抢占的次数

taskset -c 0,1 /usr/bin/your-service

# 持久化：对 systemd 服务添加 CPUAffinity

systemctl edit your-service

# [Service]

# CPUAffinity=0 1

`

第二种情形是明显超售，任意两项指标异常且业务已经受影响。这时应该带证据联系商家，要求换机或换机房。证据要具体到数字和时间，比如"20:00 至 23:00 期间 steal 持续 8% 至 12%，4K 随机写 IOPS 达成率 55%，已持续一周"。给商家一个可执行的选项（换到另一个机房或另一个节点）比单纯索赔更容易达成。

第三种情形是重度超售，steal 超过 12%、IOPS 达成率低于 50%，或者机器直接不稳定。这种情况下唯一理性的动作是迁移走，并要求退款或按剩余周期折算。不要试图在一台已经被证明不稳定的机器上抢救业务。

第四种情形是发现问题的根源是流量额度而非超售。比如晚高峰带宽只有 12%，但夜间能到 86%，同时流量用量显示已用超过 80%。这时候真正该做的是换更大的流量套餐，或者联系商家调整限速策略，而不是投诉超售。判断方法是查流量用量：

`bash

# 通过商家提供的面板接口或本地统计查看已用流量

cat /proc/net/dev | awk 'NR>2 {rx+=$2} END {printf "本次开机累计接收 %.2f GB\n", rx/1024/1024/1024}'

vnstat --oneline b 2>/dev/null || echo "建议安装 vnstat 做流量统计（apt install vnstat）"

`

还可以用一条命令把检测结果直接汇总成一行，方便每天记录并横向对比：

`bash

# 一行汇总：核数 | steal% | 内存可用% | 磁盘队列 | 时间

printf "%s | cpu=%s | steal=%s%% | mem=%s%% | load=%s\n" \

"$(date +%F' '%T)" "$(nproc)" \

"$(vmstat 1 2 | tail -1 | awk '{print $16}')" \

"$(awk '/MemTotal/{t=$2}/MemAvailable/{a=$2}END{printf "%.1f", a/t*100}' /proc/meminfo)" \

"$(cut -d' ' -f1 /proc/loadavg)"

`

只要把这行输出按天追加到一个文件里，一周后你就有了自己机器的水位基线。以后再出现"感觉变慢了"，把这个文件调出来对比，问题出在 CPU、内存还是磁盘一目了然。

十、常见问题

steal time 多少算超售？ 空闲时持续高于 1% 属于正常范围；1% 到 5% 是轻度争抢，多数业务无感；5% 到 10% 属于明显超售；超过 10% 是重度超售，机器在高峰期会明显卡顿。关键是要在有真实负载时采样，空闲时的 steal 几乎为零，测不出任何东西。

VPS超售检测一定要用 fio 吗？ 不一定。steal time 和内存可用率这两项用 /proc 直接读取，是零干扰、最可信的证据。fio 会产生真实的磁盘写入，在没有业务负载时结果只能作参考。预算有限时，先把 CPU 和内存两项测准，就已经能支撑"两项异常即判定"的结论了。

为什么我的跑分比评测文章里的低？ 三个常见原因：一是跑分时段不同，晚高峰会有明显掉分；二是评测用的机器配置和你的不同，达成率才有可比性，绝对分数意义有限；三是共享宿主机与独享物理机的基线差异。正确做法是找同商家、同配置、同地线的机器横向对比，而不是跟榜单数字比。

内存显示少了 300 MB 是不是被超售了？ 不一定。系统内核、缓存和基础进程本身就会占用一部分，2 GB 机器实测可用 1700 MB 属于 83.0% 的正常水平。可用率低于 85% 才需要警惕，低于 75% 基本可以判定。要区分是"内存被超售"还是"你自己开的服务占的"，用 free -m 加上进程级 RSS 排序对照就能看出来。

晚高峰带宽跑不满，但评测说能跑满，是骗人吗？ 要先确认三个可能：流量额度是否已用完（用超速会被限速）、测速源是否走公网（商家自带的测速文件是内网结果）、以及是否处于拥塞时段。排除这三点之后，晚高峰能跑到端口 30% 以下才算异常，需要注意的是夜间测试通常不能反映真实可用能力。

超售能要求退款吗？ 取决于商家的服务条款和退款窗口，多数商家对"性能不达标"的处理方式是换机或换机房而非全额退款，因为超售是行业普遍做法而非欺诈。谈判时的关键证据是持续多日的检测数据（第七节的定时采集脚本），单次截图的说服力很有限。付了年费的话，退款窗口通常已过，这时换机往往比退款更容易谈成。