去年有台跑了两年的云服务器突然开始变慢，订单落库要 3 秒多，运营的同学一开始怀疑是数据库慢，查了慢查询日志什么都没有；后来我把应用全停了，直接在这台机器上用 fio 压了一遍磁盘，结果一出来整个人都清醒了一块号称 5000 IOPS 的 SSD，实测只有 347 IOPS，差了整整 14 倍。机器换了一块云盘之后，同样的压测脚本直接跑到 4800 IOPS，订单写入时间回到 80 毫秒。这次经历让我养成了一个习惯：凡是涉及磁盘读写的业务，上线前一定先自己压一次，不看商家标称值。
如果你正在挑云服务器、或者想给现有机器换个更靠谱的存储方案，这两家可以先看看：狗云DOGYUN（高性价比云服务器，SSD 云盘可选，适合做读写密集型业务）、Zenlayer（全球多地区节点，本地化存储与大带宽场景更合适）
一、IOPS 到底是什么，为什么它比带宽更值钱
带宽大家都会看，单位是 MB/s，说的是"一秒能搬多少数据"。IOPS 是另一回事，单位是次/秒，说的是"一秒能做多少次读写操作"。这两者的关系在于：单次操作的块大小。同样是 100MB/s 的吞吐，用 4KB 的小块去读，能做两万多次 IOPS；用 1MB 的大块去读，只能做一百次。数据库的随机小查询、Redis 的 AOF 落盘、日志系统的写入，关心的是 IOPS；而视频转码、大文件备份、ETL 批量搬运，关心的是带宽。只看带宽不看 IOPS，是新手买云盘最常踩的坑。
还有个现实问题：几乎所有云厂商都不会告诉你它的 IOPS 是限制在共享池里的。同一台机器，磁盘写入达到某个阈值之后会被限速，这个阈值和你的 CPU、内存、宿主机其他租户都在抢同一份资源。所以"标称 5000 IOPS"和"你能稳定拿到 5000 IOPS"完全是两码事。
二、我用的压测命令，以及那几个必须懂的参数
fio 是 Linux 上最常用的磁盘压测工具，装起来很简单，主流发行版一条命令就够：
apt install fio -y # 或 yum install -y fio
我第一次跑的时候也踩了坑，用的这条命令：
fio --name=randread --filename=/mnt/data/testfile --rw=randread --bs=4k --iodepth=32 --numjobs=4 --size=1G --runtime=60 --group_reporting
参数含义拆开说：--rw=randread 是随机读，--bs=4k 是块大小 4KB，--iodepth=32 是队列深度 32，--numjobs=4 是 4 个并发任务。跑完我一看 IOPS 只有 347，当时第一反应是是不是参数写错了？
还真不是参数写错，是我压测的方法本身有问题：--size=1G 意味着每个 job 只写 1GB，四个 job 加起来才 4GB 的测试文件，文件全落在宿主机缓存里没落盘就被反复读，读出来的是内存里的东西。这种测法测的是内存带宽，不是磁盘。改成 --size=20G（要大于机器内存，至少几倍内存容量，保证真实落盘）之后再压，IOPS 才回到正常区间。
这里必须强调三点：
第一，测试文件必须大于内存。内存 16G 的机器，测试文件至少给 64G，不然就是自欺欺人。
第二，别用 --direct=1 之外的方式糊弄。 fio 默认走页缓存，加 --direct=1 才能绕过缓存直接打到块设备上，这才是真实 IOPS。
第三，队列深度要跟你的业务对上。Web 服务的并发请求多，队列深度给 32、64 合理；如果是离线批量任务，队列深度 1 或者 8 反而更接近真实情况。厂商给 IOPS 标称值时，测的多是高队列深度下的吞吐，你的业务如果并发很低，就很可能拿不到那个数。
三、347 和 4800 之间，差的到底是什么
把 fio 结果摊开对比，差距主要落在这几处：
1）介质类型。被限速的那块是机械盘或者 SATA SSD，另一块是 NVMe。SATA SSD 的随机 4K 读写普遍在 50~100 MB/s 区间，折算 IOPS 也就一千出头；NVMe 才可能跑到几千甚至上万。买云盘的时候，"SSD"这三个字现在基本等于没写，得具体问清楚是 SATA SSD 还是 NVMe。
2）是否独享。标称 5000 IOPS 的共享池，超售严重的时候你能拿到的份额可能只有标称的 10%~30%。我见过最夸张的一次，同一块盘白天测是 4800，晚上十点测就掉到 400 多同一台机器，同一块盘，没有任何人动过。
3）基线写入干扰。同一台机器上如果还有别的业务在写盘，你的读也会被拖慢。压测最好在业务低峰期做，并且把测试文件和业务数据分到不同的挂载点。
4）写入放大。云盘的底层大多有副本、纠删码、快照这些机制，写进去的数据不是一比一落盘。这也是为什么标称是"物理盘能力"，你拿到的永远是打折后的结果。
四、把 fio 结果翻译成你能用的结论
压完不是终点，关键是把数字对上业务。我一般这么算：需要的 IOPS = 日均订单量 × 峰值系数 × 单次请求产生的读写次数。以一台跑论坛加订单系统的机器为例，日均 2 万单，峰值集中系数按 5 算，单次请求大概 3 次读写，那就是 2万 × 5 × 3 ≈ 30 万次操作，摊到高峰那 2 小时里，每秒需要 41 IOPS。这点量对任何正经 SSD 都是小菜一碟所以我上面那台机器慢成那样，问题多半不是"IOPS 不够"，而是"IOPS 被限到了 347 但业务实际需要 800 以上"，也就是差了一个数量级。
再看延迟。fio 输出里 clat（完成延迟）比 lat 更能反映用户体验。业务对延迟的敏感度往往比对吞吐更高：一个 1 IOPS 但延迟 0.3ms 的盘，和一个 5000 IOPS 但延迟 25ms 的盘，在你的业务里表现可能完全相反高并发下后者会因为排队把请求拖到几十毫秒，而前端早就超时了。
我的建议是：把 fio 的结果连同业务基线一起存档。哪天性能突然掉了，先重跑一次 fio，如果数字没变，说明是业务侧的问题（SQL 变了、数据量涨了、缓存失效了）；如果数字掉了，说明云盘的底子或者邻居的负载变了，这时候再去找商家扯皮，证据就非常硬了。直接把两次 fio 输出贴进工单，比说"感觉变慢了"有用得多。
五、几个容易踩的细节
1）先跑 fio --version 确认版本。老版本 fio 的默认参数和新版差别不小，测出来的数不能混着比。
2）测试完记得删文件。我见过有人压完测试，100G 的 testfile 就那么躺在磁盘上，把本来就不够用的空间又吃光。清理命令：rm -f /mnt/data/testfile，另外 fio 有个 --unlink=1 参数可以压完自动删。
3）别在业务高峰期压。压测本身就是写负载，100% 写入会把整块盘的带宽吃满，顺便把同机邻居也拖下水。
4）压测是抽样，不是全貌。厂商的 IOPS 是在自己标准环境、固定块大小、固定队列深度下测的。你的业务有自己的分布，二者对不上是常态。压测的价值在于横向对比和长期留档，而不是纠结那几个点。
5）云盘和自建硬盘的差别。自己淘的硬盘在裸机上测出来的 IOPS 一般很稳定，因为没有人跟你抢；云盘的数字会浮动，因为底层宿主机是共享的。如果你的业务对磁盘性能敏感又对成本敏感，自建或混合方案往往比"全上云盘"更划算。
最后多说一句，硬盘本身的健康状况和性能是两回事，一块盘可以跑得飞快同时 SMART 已经在报警。性能压测和健康检测最好一起做：前者用 fio 测吞吐和延迟，后者看 SMART 的重映射扇区和坏道计数，两边数据放一起才是完整的磁盘画像。顺手也可以用 smartctl -a /dev/vda 拉一份完整信息存档。
云服务器的性能，从来不是看标称参数就能知道的。IOPS 这三个字母简单得很，但它背后是一整条从介质、超售、限速到业务模型的长链条。买之前多花十分钟压一次，比上线后半夜被人叫起来查慢查询要划算得多。
喜欢 
顶
难过
囧
围观
无聊
