韩国VPS性能实测方法

来源: 飞翔小编 2026/11/5 13:54:28 浏览量：0

一、为什么官方跑分不能作为购买依据

商家页面上写的"10 Gbps 端口"、"NVMe 硬盘"、"7 vCPU"，这三个数字里没有一个能直接换算成你的实际体验。

端口速率不等于你拿到的速度。 "10 Gbps"通常指宿主机交换机的端口能力，分配到你的 VPS 上可能是共享峰值的一部分。同机房的邻居如果同时在跑传输，你的实际吞吐会被瓜分。只有晚高峰实测的持续吞吐才接近真实值。

vCPU 数量不等于性能。 超线程带来的"两个核"里有一个是物理核的影子线程，同时做整数运算时两个线程的合计性能大约只有 1.2 到 1.3 倍，而不是 2 倍。另外还要看 CPU steal time——宿主机超售时你的虚拟核会被抢走，这一项在繁忙时段能到 5% 到 20%。

NVMe 不等于磁盘快。 你拿到的可能只是共享了一部分 IOPS 通道的虚拟设备。

查 justg 在售套餐与库存

所以测试必须在你自己的网络、自己的时间窗口、自己的业务负载下做。这篇讲的就是这套流程。

二、测试前的准备工作

第一步：准备测试文件。 下载站和 API 服务需要不同的测试对象。

# 在服务器上生成 1 GB 测试文件（用 /dev/zero 会命中压缩，实际磁盘上是稀疏文件不真实）
dd if=/dev/urandom of=/tmp/test1g.bin bs=1M count=1024 oflag=direct

# 生成 100 MB 小一点的文件，方便测单次下载
dd if=/dev/urandom of=/tmp/test100m.bin bs=1M count=100 oflag=direct

# 校验一下不是稀疏文件
du -h --apparent-size /tmp/test1g.bin
du -h /tmp/test1g.bin

两个数字应该接近。如果 du 显示的实际占用远小于 --apparent-size，说明文件是稀疏的，测出来的磁盘速度会虚高。

第二步：把测试脚本装上。 常用的测试工具：

apt-get update && apt-get install -y sysbench curl mtr traceroute iperf3 vnstat

第三步：记录机器的基础信息，作为报告的表头。

echo "=== 基础信息 ==="
cat /etc/os-release | head -3
nproc                                    # vCPU 数
free -h                                  # 内存总量
df -h /                                  # 磁盘总量
lscpu | grep -E "Model name|MHz|CPU\(s\)"   # CPU 型号
cat /proc/cpuinfo | grep "model name" | head -1

第四步：确认磁盘类型和控制器。

lsblk -d -o NAME,SIZE,ROTA,MODEL       # ROTA=0 是 SSD/HDD，1 是机械盘
cat /sys/block/sda/queue/rotational

第五步：确认是不是独立 IP（这决定了很多业务能不能做）。

ip addr show | grep inet
curl -s ifconfig.me; echo

两个 IP 一致才是独立 IP。不一致就是 NAT 转发。

第六步：装一个持续采集的监控，让测试数据自动沉淀。 单次测试最大的问题是没有历史对比。vnstat 能把网卡流量按天和按小时记下来，sar 能保留系统级历史：

# 安装并启动 vnstat（守护进程，自动记录）
apt-get install -y vnstat
systemctl enable --now vnstat

# 看按天的历史
vnstat -d -m
# 看按小时的分布，能直接看出晚高峰的流量曲线
vnstat -h
# 看实时速率
vnstat -l

vnstat 特别适合做端口利用率的长期判断。 如果某个时段的历史出站流量明显高于其他时段，而你并没有对应的业务，那多半是有外部流量在走这台机器——这在排查"莫名变慢"时非常有用。

第七步：设置一个基线快照，把当前状态存档。 这样后面任何改动都可以对比：

mkdir -p /root/baseline
# 系统信息
sysbench cpu --cpu-max-time=30 --threads=$(nproc) run > /root/baseline/cpu.txt 2>&1
sysbench memory --memory-block-size=1K --threads=8 --time=30 run > /root/baseline/mem.txt 2>&1
sysbench fileio --fileio-mode=randwr --fileio-size=1G --threads=16 --time=30 run > /root/baseline/disk.txt 2>&1
# 网络基线
ping -c 30 -i 0.3 目标IP > /root/baseline/ping.txt 2>&1
mtr -r -c 100 目标IP > /root/baseline/mtr.txt 2>&1
# 清理测试文件
rm -f sysbench-fileio* testfile* 2>/dev/null

vpckr 官网机型与实时报价

为什么要留基线？ 因为商家回复工单说"我们这边一切正常"时，你需要一个不带情绪的对比数据。同样一台机器，重装系统前后的数字差 30%，这是硬证据。

三、CPU 性能怎么测，看哪个数字

测试命令：

# 单线程性能（看单核能力）
sysbench cpu --cpu-max-time=30 --threads=1 run

# 多线程性能（看整体能力）
sysbench cpu --cpu-max-time=30 --threads=$(nproc) run

看 sysbench 输出里的三个关键行：

events per second:  这就是每秒能处理的事件数，单线程和多线程各记一次
total number of events: 30 秒内完成的总事件数

判读标准（相对于你能拿到的参照物）：

1. 多线程 ÷ 单线程的比值。 这个比值应该接近物理核数。如果是 4 核机器但比值只有 2 左右，说明 hypervisor 给你的 vCPU 实际上是共享的，或者宿主机 CPU 已经很满。

2. 和另一台同价位机器对比。 这是最靠谱的判据。sysbench cpu --threads=1 run 的 events per second 是个稳定的绝对值，你可以拿自己已有的任何一台 VPS 跑同样的命令做基准线。

3. 单核 events per second 的绝对参考值。 现代主流 x86 单核在 sysbench cpu 默认配置下大约在每秒 2000 到 3500 个事件；E5-2630 V2 这类 2012 年的服务器 CPU 大约在每秒 1200 到 1800；5120 和 6248 这类更新的型号大约在每秒 2000 到 2800。低于 1000 就要警惕了。

必须同时看的另一个指标——CPU steal：

# 每秒采样，看 st（steal）这一列
vmstat 1 10

判读标准：

steal 时间	含义	处置
0% 到 1%	正常，独占或轻超售	无需处理
1% 到 5%	轻度共享，可接受	继续观察
5% 到 10%	明显超售	考虑换机或换商家
持续高于 10%	严重超售	立刻换机器

查看 zji 当前月价与库存

测试时间点很关键。 一定要在晚高峰（晚 8 点到 10 点）跑一次 vmstat 1 10，如果这时的 steal 比凌晨高出明显一截，说明超售是动态的——白天没事只是因为没人抢。

四、内存性能怎么测

测试命令：

sysbench memory --memory-block-size=1K --threads=8 --time=30 run

判读重点： 看 transferred 这个数字（每秒传输的字节数）。现代 DDR4 单通道大约在每秒 5 GB 到 8 GB，双通道能到 10 GB 到 15 GB。

但对绝大多数 VPS 用户来说，内存性能测试的意义远小于另外两项测试。 因为 VPS 的内存分配几乎总是虚拟化的，测出来的带宽受宿主机影响很大，而且你的业务是访存密集（数据库查询、缓存命中）还是带宽密集（大文件扫描）差异巨大。

真正对你有用的是内存测试之外的七个维度：

第一，内存的"可用量"而不是"总量"。

free -h

看 available 那一列。VPS 的 total 里有很大一部分是宿主机预留给页缓存和内核结构的，你的实际可用量通常是 total 的 85% 到 95%。

第二，内存是否被正确分配。 这是个常见坑：有些超售的 VPS，你买的是 4 GB 但系统里只看到不到 4 GB。

# 对比 total 和物理内存
free -b | grep Mem
sudo dmidecode -t memory | grep -i size

第三，实际业务的内存谷值。 跑一周你的服务，然后看空闲时的内存占用。谷值超过 70% 就该升配了，因为一旦有个内存尖峰就会触发 OOM。

第四，Swap 有没有配。 没有 Swap 的机器，遇到内存尖峰会直接 OOM 崩溃；有了 Swap 至少能撑住（虽然会变慢）。

swapon --show
# 如果没有，建 2 GB
fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

第五，内存回收压力。 这是最容易被忽略、但对共享型 VPS 最要命的一项。看这两个值：

# 看有多少内存被拿去做页缓存，以及回收压力指标
grep -E "^(MemAvailable|Cached|Buffers|SReclaimable|SUnreclaim)" /proc/meminfo
# 重点看 SReclaimable（可回收的 slab）
# vmstat 里的 si/so 列：非 0 说明正在换入换出
vmstat 1 10

判读： vmstat 输出里的 si（swap in）和 so（swap out）两列，如果稳定期非 0，说明系统已经在用 Swap 换内存——这时候你的可用内存是假的。在共享型 VPS 上，如果宿主机内存吃紧，你的页缓存会被回收、你的 Swap 会被触发，表现就是"明明配置够但就是卡"。

第六，NUMA 与超线程的隐藏影响。 内存带宽不足时，跨 NUMA 节点访问的延迟是本地的 1.5 到 2 倍。虽然大多数 VPS 不会暴露 NUMA 拓扑，但 lscpu 里的 NUMA node(s) 字段可以确认。如果显示多于 1 个节点而你的应用没做绑定，性能会有折损。

# 看 NUMA 拓扑
lscpu | grep -i numa
# 看当前 CPU 频率是否被降频
cat /proc/cpuinfo | grep "MHz" | head -4

第七，内存一致性检查的实操价值。 大多数新手不需要跑 memtest86，但如果你怀疑机器有问题，一个更实用的检查是"写入—校验"往返：

# 写 2 GB 随机数据，再读回校验内容是否一致
dd if=/dev/urandom of=/tmp/memtest.bin bs=1M count=2048 conv=fsync
md5sum /tmp/memtest.bin
sync
dd if=/tmp/memtest.bin of=/dev/null bs=1M
rm -f /tmp/memtest.bin

查看恒创科技当前月价与库存

这测的不是内存条，而是存储路径的完整性——如果读回的内容和写入的不一致，问题在磁盘控制器或虚拟化层，而不是内存。

五、磁盘性能怎么测，怎么区分 SSD 和 HDD

测试命令：

# 顺序读写（看磁盘的"上限速度"）
sysbench fileio --fileio-mode=seqrd --fileio-size=1G --threads=1 --time=30 run
sysbench fileio --fileio-mode=seqwr --fileio-size=1G --threads=1 --time=30 run

# 随机写（这是最能区分 SSD 和 HDD 的指标）
sysbench fileio --fileio-mode=randwr --fileio-size=1G --threads=16 --time=30 run

# 随机读
sysbench fileio --fileio-mode=randrd --fileio-size=1G --threads=16 --time=30 run

判读标准：

测试项	SATA SSD	NVMe SSD	机械硬盘
顺序读	400 到 550 MB/s	1500 到 7000 MB/s	140 到 220 MB/s
顺序写	350 到 500 MB/s	1000 到 6000 MB/s	100 到 200 MB/s
随机写（16 线程）	20 到 80 MB/s	200 到 1500 MB/s	2 到 15 MB/s
随机读（16 线程）	30 到 100 MB/s	300 到 2000 MB/s	1 到 5 MB/s

查看 hostkvm 当前月价与库存

看 lsblk 的 ROTA 列确认介质类型：0 是 SSD/HDD（固态或虚拟盘），1 是机械盘。云途的机型数据里明确区分了 SSD 和 SAS HDD 两类存储，选型时要对得上。

随机写是最关键的指标。 差距在 10 倍以上。这就是为什么大文件顺序下载场景下 HDD 够用，而日志写入、数据库、小文件场景下必须用 SSD。

注意测试时的清理。 sysbench 的 fileio 测试默认在当前目录下创建测试文件，跑完记得清掉，否则占着你的流量和磁盘：

rm -f /tmp/testfile* sysbench-fileio* 2>/dev/null

同时看延迟分布，而不只看平均值：

iostat -x 2 3

关注 await（平均等待时间）、r_await、w_await 三个字段。SSD 的 await 通常在 0.1 到 1 毫秒；HDD 在随机读写下 await 会到 10 到 30 毫秒。这个数字比吞吐更能反映你的真实体感。

文件系统层面的坑比硬件更常见。 磁盘本身没问题但性能上不去，通常是这三个原因：

第一，磁盘没挂上或者挂错了。 这是最常见也最容易忽略的问题：

# 确认根分区和 /data 分区分别挂在哪里
df -hT
# 确认挂载参数（relatime 会拖慢元数据操作）
mount | grep -E "ext4|xfs"

判读： 如果 df -hT 显示的挂载点是 /dev/sda1 但你的数据在 /dev/sdb1 上，说明你把文件写到了系统盘。系统盘通常只有 20 到 40 GB，写满了会导致整机异常。

第二，没有禁用 atime。 Linux 默认每次读文件都更新访问时间（relatime 模式下每个小时才更新一次，但仍会产生额外的元数据写入）：

# 永久关闭 atime，改用 noatime
mount -o remount,noatime /
# 或者在 /etc/fstab 里改
# /dev/sda1 / ext4 defaults,noatime 0 1

对读多写少的场景，noatime 能减少 10% 到 30% 的元数据写压力。

第三，inode 耗尽。 症状很隐蔽：磁盘还有空间但就是写不进去，报错是 "No space left on device"。

# 看 inode 使用率
df -i

判读： 使用率接近 100% 就是 inode 满了。成因通常是小文件太多（缓存、邮件队列、session 文件）。处置： 找出占用最多的目录：

# 找出 inode 占用最多的目录
for d in /*; do echo "$(find "$d" -xdev -printf '%i\n' 2>/dev/null | wc -l) $d"; done | sort -n | tail -10

第四，vps 的磁盘是网络存储还是本地盘。 这一条对性能影响极大，而且商家往往不主动说。可以这样间接验证：

# 连续多次小随机写，看延迟是否稳定
for i in 1 2 3 4 5; do
  dd if=/dev/zero of=/tmp/t$i.bin bs=4k count=100 oflag=direct 2>&1 | tail -1
  rm -f /tmp/t$i.bin
done

判读： 本地 NVMe 的写入延迟通常在 0.1 到 0.5 毫秒且波动极小；如果是网络存储（SAS 阵列或分布式存储），延迟会在 0.5 到 3 毫秒之间明显波动，而且偶尔会出现几毫秒的尖刺。波动大就说明你的"随机写速度"数字有一部分是在等网络，不是在等磁盘。

六、网络到韩国的延迟和路由怎么测

第一层：基础延迟和丢包。

# ping 测试，看平均延迟和丢包率
ping -c 30 -i 0.3 你的服务器IP

# 路由追踪
traceroute -T -p 443 你的服务器IP
mtr -r -c 100 你的服务器IP

判读标准：

- 国内主要城市到首尔的物理延迟参考值： 北京到首尔约 30 到 45 毫秒，上海到首尔约 40 到 55 毫秒，广州到首尔约 55 到 75 毫秒，成都到首尔约 60 到 80 毫秒。超过这个范围 50% 以上，说明路由绕路了。

- 丢包率： 白天低于 0.5% 算正常；晚高峰低于 2% 算可接受；持续高于 5% 说明这条线在晚高峰是拥塞的。

- mtr 输出里的关键行： 看倒数第二跳和倒数第三跳。如果出现某个 IP 段的时延突然从 40 毫秒跳到 150 毫秒并伴随丢包，那就是拥塞点。

第二层：路由质量（哪些骨干网）。 在 mtr 输出里找这些标识：

- 59.43.x.x —— 中国电信 CN2 骨干

- 219.158.x.x —— 中国联通骨干（AS4837）

- 9808 —— 中国移动骨干（AS9808）

- CMIN2 相关段 —— 移动新一代骨干

第三层：反向测试。 从服务器上测回国内。这条路径往往比去程更重要，因为下载和 Web 访问的响应数据都走回程。

# 在服务器上执行
mtr -r -c 100 你的国内客户端IP

如果去程很快但回程绕路，体验一样会很差。 这是"离得近但感觉很慢"的最常见原因。

第四层：多地延迟对比。 用公共测速节点做横向比较：

# 在服务器上
iperf3 -c 测速节点IP -P 10 -t 10

第五层：丢包的性质要分清。 mtr 输出里丢包的位置比丢包率更重要：

# 逐跳统计丢包，-w 是宽字符报告
mtr --report --report-cycles 100 你的服务器IP

判读要点：

- 只有最后一跳丢包。 这是最常见的良性情况——中间路由器对 ICMP 限速，而你的 TCP 流量正常。不需要处理。

- 连续多跳丢包，且丢包从某一跳开始。 这是真的链路拥塞点。需要处理。

- 从第一跳就丢包。 说明你本地网络或运营商出口有问题，跟商家无关。先自查本地网络。

区分"ICMP 限速"和"真实丢包"的办法是直接测 TCP 层：

# 用 TCP 模式测，绕开 ICMP
mtr --tcp --port 80 -r -c 100 你的服务器IP

第六层：TCP 重传率——最真实的健康指标。 这个指标直接反映链路的实际损耗：

# 看网卡统计里的重传数
nstat -az | grep TcpRetransSegs
nstat -az | grep TcpOutSegs

判读：重传率 = TcpRetransSegs ÷ TcpOutSegs。 低于 0.1% 是优秀，0.1% 到 1% 是正常范围，高于 2% 说明链路质量明显有问题，需要换线路或者换商家。这一项比 ping 的丢包率更可靠，因为它统计的是真实业务流量的重传。

第七层：MTU 探测。 很多"慢"的问题最后查出是 MTU 不匹配导致的大包丢失：

# 二分查找实际可用的 MTU
ping -M do -s 1472 -c 3 目标IP    # 1472 + 28 = 1500，标准 MTU
ping -M do -s 1464 -c 3 目标IP    # 1472 + 28 = 1500，如果这个通就说明 MTU 正常

如果 1472 不通但 1464 通，说明路径上存在 MTU 黑洞。处置： 在接口上把 MTU 调到 1400 左右：

ip link set dev eth0 mtu 1400

第八层：回程路由的独立验证。 服务器上主动测你本地：

# 在服务器上执行，测试回程路径
mtr --tcp --port 22 -r -c 100 你的客户端IP

查 vollcloud 在售套餐与库存

这是判断"回程绕路"的关键一步。 前面的 traceroute 测的是去程，而用户的实际体验由回程决定。

七、带宽实测：怎么测出真实的持续吞吐

方法一：测单连接速度（最接近用户体感）。

# 从客户端拉取 1 GB 文件
curl -o /dev/null -w "速度: %{speed_download} B/s\n" \
  http://你的域名/test1g.bin

# 换算成 MB/s
curl -o /dev/null -w "速度: %{speed_download} B/s\n" \
  http://你的域名/test1g.bin | awk '{printf "%.2f MB/s\n", $2/1048576}'

判读标准：

端口标称	单连接合理区间	说明
1000 Mbps	60 到 110 MB/s	单线程打满 TCP 窗口约 100 MB/s
2000 Mbps	70 到 180 MB/s	单连接受窗口限制打不满
10000 Mbps	100 到 400 MB/s	必须多连接才能吃满

查看 kdatacenter 当前月价与库存

单连接打不满 10 Gbps 是正常现象，不是机器的问题。 TCP 单连接的窗口限制决定了这一点。要测端口上限，必须用多连接。

方法二：多连接测端口上限。

# 客户端：开 10 条连接并行下载
for i in $(seq 1 10); do
  curl -s -o /dev/null -w "%{speed_download}\n" http://你的域名/test1g.bin &
done | awk '{s+=$1} END {printf "总速度: %.2f MB/s\n", s/1048576}'

判读标准： 多连接总速度 × 8 应该接近标称端口速率。如果只有标称的三分之一以下，说明端口被共享或者宿主机有限速。

方法三：用 iperf3 测纯带宽（需要另找一台机器做服务端）。

# 服务端
iperf3 -s -p 5201

# 客户端
iperf3 -c 服务器IP -p 5201 -P 10 -t 30

看 Receiver 的 Sum 那一行。这个值就是链路的真实吞吐，不受你的应用层影响。

方法四：测端口利用率。

# 服务器上
sar -n DEV 1 10

看那个网卡的 rxkB/s 和 txkB/s。端口利用率（实际速率 ÷ 标称速率）超过 60% 就该升配了。

方法五：测持续吞吐而不是瞬时峰值。 上面四种测的都是"一段时间内的平均"，但真正决定用户体验的是在长时间压力下能否维持住。端口速率的瞬时峰值和 30 分钟后的稳定值可能差很多——共享端口尤其如此。

# 在服务器上持续 10 分钟接收数据，观察速率是否衰减
iperf3 -c 客户端IP -p 5201 -P 10 -t 600 -i 10

-i 10 表示每 10 秒打印一次中间结果。重点看曲线：如果速率从开始的 800 Mbps 一路滑到 300 Mbps，说明端口在被逐步挤占；如果从 200 Mbps 起步就没变过，说明你本来就分不到带宽。 这两种情况的处置完全不同——前者是共享争抢，后者是端口配额限制。

方法六：单连接与多连接的差值。 这两者的比值直接告诉你端口的"深度"：

# 单连接
curl -o /dev/null -w "%{speed_download}\n" http://你的域名/test1g.bin
# 8 连接并行
for i in $(seq 1 8); do curl -s -o /dev/null -w "%{speed_download}\n" http://你的域名/test1g.bin & done

判读： 如果 8 连接的总速度是单连接的 8 倍左右，端口是"浅"的（单连接就能占满，没有富余）；如果 8 连接只有单连接的 3 倍，说明单连接已经打到了某个限制（通常是 RTT × 窗口的 TCP 带宽时延积），端口本身可能还有余量。

第七步：把测速结果换算成用户体感。 单连接速度的实际计算是：速度 = 带宽时延积 ÷ RTT。从韩国到国内主要城市的 RTT 大约在 30 到 80 毫秒，一个常见的 TCP 初始窗口在 4 MB 到 64 KB 之间（取决于内核版本和是否启用窗口缩放）。

# 查当前系统的 TCP 参数
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.core.rmem_max net.core.wmem_max
# 查是否启用了窗口缩放（重要）
cat /proc/sys/net/ipv4/tcp_window_scaling

如果你能调大 TCP 缓冲，单连接速度能明显提升：

# 临时生效
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
# 写进配置永久生效
echo "net.core.rmem_max = 16777216" >> /etc/sysctl.conf
echo "net.core.wmem_max = 16777216" >> /etc/sysctl.conf
sysctl -p

这个调整在下载站和大文件传输场景下效果明显，几十行的配置改动能换来 30% 到 100% 的单连接速度提升。

八、晚高峰对比：这一步才能分辨真伪

同一台机器，在三个时间点跑同一套测试，结果差异大就是有问题。

必须测的三个时间点：

- 凌晨 3 到 4 点（低谷）

- 上午 10 到 11 点（平峰）

- 晚上 8 到 10 点（高峰）

重点观察四个指标的晚高峰劣化幅度：

指标	正常劣化	异常劣化	含义
平均延迟	上升 10% 到 30%	上升 50% 以上	回程线路拥塞
丢包率	0% 到 1%	持续高于 3%	线路质量差或被限速
CPU steal	0% 到 3%	持续高于 8%	宿主机超售
下载速度	下降 10% 到 25%	下降 50% 以上	共享端口被抢占

zenlayer 官网机型与实时报价

这是判断一家服务商是否靠谱的最有效方法。 凌晨跑出来的数据几乎所有商家都能过，晚高峰跑出来的数据才能说明问题。

一个高效的做法是写个定时脚本，连测一周。

#!/bin/bash
# /root/perf_test.sh  —— 每小时记录一次
ts=$(date '+%F %T')
ping -c 10 -i 0.3 8.8.8.8 | grep "rtt" | awk -v t="$ts" '{print t, "rtt_avg_ms="$5}' >> /root/perf_log.txt
vmstat 1 3 | tail -1 | awk -v t="$ts" '{print t, "steal="$16, "cpu_idle="$15}' >> /root/perf_log.txt

连续跑一周，然后用 awk 按小时聚合，就能看到每天 20 点那个明显的劣化谷。

把原始日志变成一张对比表。 有了 /root/perf_log.txt 之后，聚合命令是这样的：

# 按小时统计平均延迟
awk '{split($2,a,"="); h=substr($1,12,2); sum[h]+=a[2]; n[h]++}
END {for (h in n) printf "%s时 平均延迟 %.1f ms\n", h, sum[h]/n[h]}' /root/perf_log.txt | sort

# 按小时统计平均 steal
awk '{split($3,a,"="); h=substr($1,12,2); s[h]+=a[2]; n[h]++}
END {for (h in n) printf "%s时 平均 steal %.2f%%\n", h, s[h]/n[h]}' /root/perf_log.txt | sort

这张表就是你和商家对话的依据。 它能直接回答三个问题：劣化是每天固定发生的还是偶发的、劣化的峰值出现在几点、劣化幅度有多大。

还要区分"线路问题"和"你自己的问题"。 一个实用做法是同时在另一台已知正常的机器上跑同样的测试。如果两台机器在同一时刻同时劣化，说明是上游骨干网的问题（找商家也没用，要换线路或换运营商）；如果只有这台劣化，那问题在商家这一侧的宿主机或端口。

# 在服务器 A（你的）和服务器 B（对照）上都跑
while true; do
  echo "$(date '+%T') $(ping -c 5 -i 0.2 目标IP | grep 'rtt' | awk '{print $5}')" >> /tmp/ping_$(hostname).log
  sleep 300
done

还有一个容易被忽略的变量：天气和节假日。 跨境光缆的维护、台风、春节前的流量高峰都会造成可预期的波动。如果你的测试恰好落在这些时段，不要据此下结论。 连续测三天以上能过滤掉偶发因素。

最后一条：测完把机器恢复原状。 如果测试过程中改了 sysctl 参数、改了防火墙规则，测完要还原，否则你测出来的"高性能"是配置带来的、不是机器自带的，这会误导后续的对比。

九、异常处置：看到这些数字该怎么处理

情况一：丢包率持续高于 3%。

先区分是"到某个特定 IP 丢"还是"普遍丢"。mtr 输出里如果只有一跳丢包，是那一跳的策略性限速（ICMP 限速），不影响实际业务；如果多跳连续丢包，就是真的链路问题。

# 排除策略性限速：直接 ping 目标端口所在的服务器
mtr --tcp --port 80 -r -c 50 你的服务器IP

处置动作： 找商家客服报工单，要求提供具体的排查结果。同时准备备用方案——把服务迁到另一台机器或加一个节点做负载均衡。绕路严重的场景，换机型的成本通常比忍受延迟更低。

情况二：晚高峰速度掉一半以上。

先确认是不是自己的流量打满了端口：

sar -n DEV 1 10

如果端口利用率本来就接近 100%，那不是被抢，是你自己用满了——升配或分流。如果利用率只有 30% 但速度掉一半，那就是端口共享被抢。

处置动作： 找客服确认端口是独享还是共享。如果确认是共享且实测长期不达标，换一个明确标注独享端口的机型。

情况三：CPU steal 持续超过 10%。

这是宿主机超售的直接证据，而且换配置没用——你买的是被超售的宿主机上的一个切片。处置动作： 换商家或换资源池。这是最应该果断走的一类问题，因为你的钱买到的算力实际上少于标称值。

情况四：磁盘 await 随机读写超过 20 毫秒。

先确认是不是自己的问题：

iostat -x 2 5

如果 w_await 高而 r_await 正常，说明是写入慢——可能是日志写得太多，或者备份在跑。检查：

# 看是不是备份任务
crontab -l
# 看大文件写入
iotop -oPa

如果排除了自己的负载，磁盘性能就是商家给的硬件不达标或有大量邻居在抢 IO。处置动作： 确认介质类型是否与订单一致（lsblk -d -o NAME,ROTA,MODEL），不一致直接找商家。

情况五：DNS 解析慢，但直连 IP 很快。

# 分别测 DNS 和直连
dig 你的域名 +stats | grep "Query time"
curl -o /dev/null -w "connect: %{time_connect}s\n" http://服务器IP

如果 connect 时间远小于通过域名访问的时间，问题在 DNS 服务器。处置动作： 换 DNS 解析器，比如 Cloudflare 或 Google 的公共 DNS。

情况六：一切正常，但你就是觉得慢。

这时候要怀疑的是应用层：Nginx 配置、缓存策略、数据库索引、TLS 握手开销。用 curl -w 把时间拆开：

curl -o /dev/null -w "DNS: %{time_namelookup}s\n连接: %{time_connect}s\nTLS: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总计: %{time_total}s\n" \
  https://你的域名/

查 cloudcone 在售套餐与库存

看哪一段吃掉了时间。TLS 握手占大头就开会话复用；首字节占大头就是后端慢；总计减去首字节占大头说明数据传输慢，那才要回到带宽方向查。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 justg 当前机型与价格
主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 vpckr 当前机型与价格
只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 zji 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

测性能需要多长时间才准？ 单次测试只能反映当前时刻的状态。至少要在晚高峰测一次，并且最好连续测三天。 一个商家某天超售了不代表长期如此，但如果你每次测都在晚上 9 点，结果就是稳定的。

sysbench 的分数能横向比较吗？ 只能和同配置、同测试参数的机器比。不同核数的机器之间，events per second 的绝对值没有可比性。正确的比法是拿你自己的旧机器跑同样命令做基准。

为什么我的测试跑出 500 Mbps，但商家说 10 Gbps？ 两个原因：一是 10 Gbps 是端口标称而非保证值（共享端口），二是单 TCP 连接受窗口限制本来就打不满 10 Gbps。要测端口上限必须用多连接（iperf3 -P 10 或多个 curl 并行）。

steal time 高就一定是超售吗？ 不一定。宿主机跑其他任务也会产生 steal。但如果 steal 在晚高峰明显升高而凌晨接近 0，说明是动态超售——这才是真正需要警惕的。偶发的高 steal 可能只是宿主机在跑例行任务。

测试会不会影响商家？ 压测类测试（iperf3 大流量、fio 长时间随机写）确实会占用资源。建议： 用 speedtest-cli 或 iperf3 测带宽时控制在 30 秒以内，随机写测试限制在 30 秒，不用 stress-ng 长时间满载。礼貌的测试者不会因为跑一次测试被区别对待。

怎么测我实际的业务性能？ 用业务自己的压测工具。API 服务用 hey 或 wrk；Web 用 ab 或 siege；下载站直接并发拉真实文件。业务压测的价值在于它能同时暴露应用层和系统层的问题，而系统基准测试只能说明其中一层。

# API 压测示例
hey -n 50000 -c 50 -m POST -H "Content-Type: application/json" \
  -d '{"id":1}' https://你的api域名/v1/endpoint

关注 P99 延迟列（99% 那一行），而不是平均值。

下载站的带宽测试文件该放多大？ 至少 100 MB。文件太小则 TCP 握手和慢启动的占比过大，测出来的速率会明显偏低；理想是 1 GB。

连着测试要花多少钱？ 软件工具全部免费（sysbench、iperf3、mtr、vnstat 都能用系统包管理器装）。唯一可能的成本是流量——下载 1 GB 测试文件会消耗 VPS 的月流量额度。云途系列的流量超额按固定重置价买回（HK.DS.M 和 DS.ES.F 是 200 元，HK.DS.S 和 HK.DS.P 是 500 元），所以测完几次的流量消耗在可控范围内，但测试完记得清理测试文件。

测试报告应该长什么样？ 一份能拿去和商家沟通的性能报告，必须包含下面七项，每项都有具体数字和时间：

项目	内容	判读阈值
测试时间	具体日期与时段，标注是凌晨/平峰/晚高峰	至少覆盖晚高峰
CPU 单核与多核	sysbench 的 events per system second	多核比值接近核数
CPU steal	vmstat 的 st 列	晚高峰低于 5%
内存与 Swap	free 的 available 列、vmstat 的 si/so	si/so 稳定为 0
磁盘随机写	sysbench fileio randwr 的吞吐与 iostat 的 await	await 低于 10 毫秒
网络	三地 ping 延迟、mtr 丢包位置、重传率	丢包低于 2%、重传率低于 1%
带宽	单连接速度与 8 连接总速	8 连接总速接近端口标称

只有数字、没有阈值的报告没有意义。 商家回复"我们这边一切正常"时，你能指着表里的某一格说"这一项在晚高峰是 8%，你们的说明是低于 3%"，这才是有效沟通。

测试结果和商家宣传不一致，该怎么办？ 保留完整测试记录（命令、输出、时间点），先向客服提交工单要求说明。如果得到的是模板化的回复而不是具体排查，明确的处置是换到月付机型先验证——云途系列全部月付，验证成本极低。年付机型（如 sixtynet 系列）不要在没有验证的情况下直接签。

一套完整的自测脚本，直接抄走用：

#!/bin/bash
# /root/full_test.sh —— 一次性跑完所有测试项并生成报告
echo "===== 测试开始: $(date '+%F %T') =====" > /root/test_report.txt

echo "--- 基础信息 ---" >> /root/test_report.txt
echo "时间: $(date '+%F %T')" >> /root/test_report.txt
echo "核数: $(nproc)" >> /root/test_report.txt
free -h >> /root/test_report.txt 2>&1
df -h / >> /root/test_report.txt 2>&1
lscpu | grep "Model name" | head -1 >> /root/test_report.txt
lsblk -d -o NAME,SIZE,ROTA,MODEL >> /root/test_report.txt 2>&1

echo "--- CPU (单核) ---" >> /root/test_report.txt
sysbench cpu --cpu-max-time=20 --threads=1 run 2>&1 | grep -E "events per second" >> /root/test_report.txt
echo "--- CPU (全核) ---" >> /root/test_report.txt
sysbench cpu --cpu-max-time=20 --threads=$(nproc) run 2>&1 | grep -E "events per second" >> /root/test_report.txt
echo "--- steal ---" >> /root/test_report.txt
vmstat 1 5 | tail -3 >> /root/test_report.txt

echo "--- 磁盘随机写 ---" >> /root/test_report.txt
sysbench fileio --fileio-mode=randwr --fileio-size=1G --threads=16 --time=20 run 2>&1 | grep -E "throughput|total io" >> /root/test_report.txt
iostat -x 2 2 | tail -5 >> /root/test_report.txt 2>&1

echo "--- 网络 ---" >> /root/test_report.txt
mtr --tcp --port 443 -r -c 50 你的目标IP >> /root/test_report.txt 2>&1
nstat -az | grep -E "TcpRetransSegs|TcpOutSegs" >> /root/test_report.txt 2>&1

echo "===== 测试结束: $(date '+%F %T') =====" >> /root/test_report.txt
rm -f sysbench-fileio* testfile* 2>/dev/null
cat /root/test_report.txt

跑完记得删掉测试文件，它们会占磁盘并且产生流量。