买 VPS 前不做基准测试，等于闭着眼睛花钱
个人站长买服务器，最容易犯的错是只看参数表：4 核 8G、NVMe 固态、10Gbps 带宽。可参数表背后藏着大量水分——同样是"4 核"，有的是独享物理核，有的是超卖到爆炸的共享核，邻居一顿跑分你就卡成幻灯片；同样是"NVMe"，有的顺序读写能到 3GB/s，有的实际跑起来还不如十年前的老 SATA。更常见的是促销时买的"1 核 1G"，便宜是真便宜，但你连它到底能扛多少并发都不知道，等到上线被压垮才追悔莫及。
基准测试（benchmark）就是给服务器"体检"：在可控条件下量化 CPU 算力、磁盘 IOPS、内存带宽、网络延迟这四个核心维度，让"这台机器够不够用"从玄学变成数字。这篇文章给出个人站长真正用得上的方法——不需要昂贵的商业工具，全部基于开源软件和系统自带命令，并且重点讲清楚每个数字该怎么解读，因为看不懂数字的测试等于没测。
测试前必须做的三件事
直接开跑是最容易得出垃圾数据的做法。先做这三步排除干扰：
# 1. 确认没有后台任务在抢占资源
uptime # load average 三个数应该都接近 0
top -bn1 | head # 没有异常高 CPU 进程
# 2. 确认磁盘是空的、没有跑在 tmpfs 上
df -h / # 根分区要有几 G 空闲，测试大文件才写得下
mount | grep ' / ' # 别是 overlay/tmpfs，那测的是内存不是磁盘
# 3. 关掉 swap 干扰（临时），让内存测试结果真实
sudo swapoff -a如果你买的是容器（OpenVZ/LXC 类），dd 和 fio 的数字会严重偏高，因为容器层可能命中宿主机缓存。识别方法：systemd-detect-virt 会告诉你虚拟化类型，看到 openvz 或 lxc 就对手里的 IO 数字保持怀疑。
CPU 算力：sysbench 是性价比之王
测试 CPU 的首选是 sysbench，Debian/Ubuntu 一条命令装好：
sudo apt-get install -y sysbench
# 单核质数计算测试（结果越低越好，看 events per second 越高越好）
sysbench cpu --cpu-max-prime=20000 --threads=1 run
# 多核测试，线程数填你的核数
sysbench cpu --cpu-max-prime=20000 --threads=4 run输出里 events per second 是每秒完成的运算次数，数字越大算力越强。关键在于单核和多核一起看：
- 单核数字低但多核数字高——典型的"核多但每个都弱"，适合跑并发多的 Web 服务，但不适合单线程的重计算任务。
- 单核数字高——说明是较新的架构（比如 AMD EPYC 或 Intel 新一代），单请求响应快，跑 PHP、Node 这类单线程瓶颈的应用更合适。
- 如果多核数字只有单核乘以核数的六成以下，说明存在 CPU 争抢或超卖，邻居影响了你的性能。
作为参考：一台较新的 EPYC 单核质数测试通常在 3000 events/s 以上，老 Xeon E5 可能只有一千多。测两次取平均，避免一次偶然抖动误导判断。
磁盘 IO：dd 看粗，fio 看细
先用 dd 做快速估算，注意一定要绕过文件系统缓存，否则你测的是内存：
# 顺序写入 1GB（direct 绕过缓存）
dd if=/dev/zero of=/tmp/test1G bs=1M count=1024 oflag=direct
# 顺序读取（先清缓存，否则会命中内存）
sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
dd if=/tmp/test1G of=/dev/null bs=1M iflag=directdd 的问题在于它是单线程顺序访问，只能反映"大文件顺序读写"这一个场景。真实网站的负载是大量随机小 IO（读索引、读日志），这个必须用 fio 测：
sudo apt-get install -y fio
# 模拟数据库负载：4K 随机读写，深度 32，跑 30 秒
fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw \
--bs=4k --size=1G --numjobs=1 --iodepth=32 --runtime=30 --group_reporting重点看输出里的 IOPS（每秒 IO 次数）和 latency（延迟）。给一组个人站务实的参考线：
- 真实 NVMe 云盘：4K 随机读 IOPS 能到 2 万以上，延迟低于 1 毫秒。
- 体面 SSD：IOPS 几千到一万，延迟 1-5 毫秒。
- 机械盘 / 严重超卖的"SSD"：IOPS 几百到一两千，延迟经常超过 10 毫秒。
如果你标称 NVMe 却只有几百 IOPS，那大概率是共享盘被邻居吃满了——这正是买之前必须测的原因。
内存带宽：mbw 快速探底
内存带宽影响数据库和缓存的吞吐，虽然不如前两项日常感知明显，但排查"为什么同样的 SQL 比别人慢"时有用：
sudo apt-get install -y mbw
mbw -q -n 10 256看 MEMCPY 和 MCOPY 两项的 MiB/s。现代 DDR4/DDR5 服务器单通道通常几 GB/s，如果结果异常低（几百 MB/s），可能内存被限速或者跑在特殊的虚拟化层上。
网络：别只信 ping，测吞吐和丢包
机房到用户的网络质量，比 CPU 磁盘更影响实际体验。分三步测：
# 1. 延迟与路由：看每一跳，定位是哪一段慢
mtr -rwzbc 20 1.1.1.1
# 2. 吞吐：需要另一台机器做对端，或者用公共测速节点
# 临时装 iperf3，跟一台有公网 IP 的机器对测
sudo apt-get install -y iperf3
# 服务端：iperf3 -s 客户端：iperf3 -c 对端IP -R
mtr 的价值在于它同时给出每一跳的延迟和丢包率。如果丢包集中在你的机房出口那一跳，那就是线路问题，换机房才有用；如果只在最后一跳出现，多半是本地网络。个人站长常踩的坑是：买的"10Gbps 带宽"在 mtr 里延迟忽高忽低，说明是共享带宽被跑满，宣传的峰值数字和你实际能用到的是两回事。
把测试串成一份体检报告
一次性把四项跑完，把结果记下来存档，作为这台机器的"基线"。以后性能下降时可以对比，一眼看出是哪块退化了。建议的完整流程：
# 一键体检（示例脚本，按需调整核数与路径）
echo "== CPU 单核 =="; sysbench cpu --cpu-max-prime=20000 --threads=1 run | grep events
echo "== CPU 多核 =="; sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run | grep events
echo "== 磁盘顺序写 =="; dd if=/dev/zero of=/tmp/t bs=1M count=1024 oflag=direct 2>&1 | tail -1
echo "== 磁盘随机IOPS =="; fio --name=r --ioengine=libaio --direct=1 --rw=randread --bs=4k --size=512M --iodepth=32 --runtime=20 --group_reporting | grep iops
echo "== 网络路由 =="; mtr -rwzbc 10 1.1.1.1测试时记得磁盘写入的临时文件测完就删，别把本来就不大的系统盘写满了——我见过有站长跑完测试忘了清理，硬盘直接告警。另外，测试本身会消耗流量和 IO，别在业务高峰期跑，避免影响访客。
实测案例：三台同价位 VPS 的差距有多大
空谈数字不如看真实对比。假设你在同一时期、用同一套命令测了三台标价相近的"2 核 4G NVMe"促销机，得到的典型结果可能是这样的：
机器 A（新架构 EPYC）
CPU 单核: 3200 events/s 磁盘 4K 随机读: 24000 IOPS 延迟: 0.6ms
机器 B（老 Xeon）
CPU 单核: 1100 events/s 磁盘 4K 随机读: 6500 IOPS 延迟: 3ms
机器 C（严重超卖）
CPU 单核: 450 events/s 磁盘 4K 随机读: 800 IOPS 延迟: 18ms三台机器参数表上看起来一模一样，但真实能力相差一个数量级。机器 C 的单核只有 A 的七分之一，磁盘延迟是 A 的三十倍——这意味着跑同一个 WordPress 站点，C 的首页响应时间可能是 A 的好几倍，数据库查询一多就直接把用户拖在那里转圈。这正是"只看参数表就下单"最典型的翻车现场。
怎么用这些数字做决策？给一个务实的换算思路：CPU 单核决定单个请求的处理速度，多核决定同时能处理多少请求，磁盘 IOPS 决定数据库的写入上限。 静态博客站对 CPU 要求低，选机器 C 也够；但动态站、有数据库和缓存写入的，机器 C 的磁盘延迟会成为致命瓶颈，宁可多花点钱也要选 B 以上。数字不是用来攀比的，而是用来匹配你的实际负载类型的。
容量换算：从测试数字推断能扛多少并发
基准测试的终极价值，是让你能大致估算出"这台机器能不能扛住我的流量"。虽然精确容量要靠压测，但拿体检数字做粗估已经能避开大部分坑：
- CPU 推算。 一个动态 PHP 请求（简单页面）大约消耗 20-50 毫秒 CPU 时间。单核 3000 events/s 的机器，理论上一核每秒能处理约 30-50 个这样的请求。4 核就是每秒一百多个请求的持续能力。虽然真实场景受 IO、数据库拖累会打折，但至少能判断"日 PV 一万"这种级别对现代机器是轻松的。
- 磁盘推算。 如果数据库每秒要处理 200 次随机写，而你的磁盘只有 800 IOPS，那写操作就会排队，查询延迟飙升。这时候要么换更高 IOPS 的盘，要么给数据库加缓存减少落盘。
- 内存推算。 用
free -h看 available，确保 MySQL 缓冲池（innodb_buffer_pool_size）能装下热数据，加上 PHP-FPM 进程和系统开销后还有余量。内存不够时机器会频繁读磁盘，把前面两项的好成绩全废掉。
把这些数字摆在一起，你就能回答一个站长最关心的问题："这台机器大概够我用多久？"而不是等到被流量打垮才手忙脚乱地升级。
数字背后：怎么用它做决策
最后说透基准测试的实战价值，免得你测完一堆数字却不知道怎么用：
- 买之前测（用试用机型）：确认宣传不虚。IOPS 虚标、CPU 超卖是重灾区，测一次就能戳破。
- 迁移前测（新旧对比）：换机房时，如果新机器单核反而更差，迁过去可能更卡，数字能防止你为了省钱反而降级。
- 上线后测（定容量）：知道磁盘 IOPS 上限，就能预估能扛多少并发写入，从而决定数据库要不要上缓存。
- 排障时测（找退化）：网站突然变慢时，和基线对比，能快速区分是服务器本身退化了，还是应用层的问题。
基准测试不是炫技，而是把"这台服务器到底行不行"这个模糊问题变成可量化、可比较、可追溯的事实。个人站长的预算有限，每一分钱都该花在刀刃上，而在一台机器上花二十分钟跑完这四个维度，往往就能帮你避免一次选错机房的懊恼。