在阿里云ECS上做存储性能摸底时，最有价值的指标往往不是顺序读写带宽，而是4K随机读写IOPS。原因很直接：数据库、缓存、消息队列这类核心业务的磁盘访问模式基本是小块随机IO，顺序大块读写在日常负载里占比并不高。本文以fio作为压测工具，用一块独立的ESSD云盘作为测试对象，演示如何通过命令组合得到可信的4K随机读写数据。
一、先弄清4K随机IOPS为什么重要
云盘性能参数里通常同时标注最大IOPS和最大吞吐量，但两者对应的块大小完全不同。以一块标称最大10万IOPS、最大吞吐量400MB/s的ESSD云盘为例，如果按照512KB的大块顺序读，理论上只需约781次IO就能吃满带宽；而如果换成4KB小块，要跑满同样的带宽需要每秒完成102400次IO，也就是10万IOPS。因此对小块负载来说，IOPS才是真正的瓶颈。
数据库的索引查找、InnoDB的页读取、Redis的RDB落盘、Kafka的分区日志追加，这些场景大多数请求落在4KB到16KB之间，并且经常混合读写。如果云盘的4K随机IOPS不够，CPU和内存再高也发挥不出来，应用会表现为响应延迟升高、连接数堆积。提前用fio测一遍，可以帮助你在选型时判断云盘级别是否满足业务水位，而不是等上线后才发现存储扛不住。
还有一个容易忽略的点：云盘标称最大IOPS通常要求在特定队列深度和并发下才能达到。实际应用里如果队列深度不足，或者单线程同步写，IOPS可能只有标称值的十分之一。fio的价值就在于可以自由调整这些变量，模拟不同业务对存储的压迫方式。
二、测试环境与fio参数拆解
测试前需要准备一台阿里云ECS实例和一块独立云盘。实例规格建议选择存储优化型或较高规格的通用型，因为低配实例自身的存储带宽和IOPS配额会先成为瓶颈。云盘可以选择ESSD PL1或PL2，具体看你的预算和测试目标。将云盘挂载到实例后，不格式化也能直接用fio对裸盘进行测试，但要注意这会破坏盘上已有数据，所以务必使用空盘或确认数据不再需要。
安装fio在CentOS上执行yum install fio -y，在Ubuntu上执行apt-get install fio -y。安装完成后可以用fio --version确认版本，一般建议使用3.x版本，参数兼容性更好。
下面是一条典型的4K随机读测试命令：
fio --name=4k_randread \
--filename=/dev/vdb \
--direct=1 \
--rw=randread \
--bs=4k \
--ioengine=libaio \
--iodepth=32 \
--numjobs=4 \
--runtime=60 \
--time_based \
--group_reporting \
--size=10G
这些参数里，--direct=1会绕过操作系统的页缓存，让读写直接打到云盘上，避免内存缓存虚高数据；--rw=randread指定随机读，换成randwrite就是随机写；--bs=4k把每次IO块固定为4KB；--ioengine=libaio使用Linux异步IO，这样才能在较少的线程下压出较高队列深度；--iodepth=32表示每个任务同时保持32个未完成请求，--numjobs=4表示并发运行4个任务。两者相乘后总队列深度为128，这接近许多云盘标称性能的测试条件。
如果不想用裸盘，可以把--filename=/dev/vdb替换为--filename=/tmp/fio_testfile，再配合--size=10G在文件系统上创建10GB测试文件。这样做更安全，但文件系统自身会引入少量开销，测出来的数据可能略低于裸盘。
三、4K随机读与随机写实测过程
先跑随机读。将上面的命令保存或直接执行，建议每次测试前先执行一次sync并清空文件系统缓存，如果用裸盘则可以忽略文件系统层。持续60秒后，fio会输出汇总结果，关键行类似下面这样：
read: IOPS=31.6k, BW=124MiB/s (130MB/s)(7440MiB/60001msec) lat (usec): min=76, max=1893, avg=395.21, stdev=118.74
这里的IOPS约3.16万，对于一块ESSD PL1云盘在4个并发任务、队列深度32的条件下是合理成绩。平均延迟大约0.4毫秒，最大延迟接近1.9毫秒，说明随机读的尾延迟并不高。如果把--numjobs从4提升到8，总队列深度变为256，IOPS可能继续上涨，但幅度会逐渐减小，因为云盘自身性能上限或实例规格配额开始起作用。
随机写测试只需把--rw=randwrite替换掉，其余参数保持不变。随机写的结果通常会比随机读低一些，尤其是ESSD云盘在写入时需要更复杂的元数据处理和磨损均衡。示例结果可能是：
write: IOPS=22.4k, BW=87.5MiB/s (91.7MB/s)(5250MiB/60001msec) lat (usec): min=84, max=2430, avg=536.77, stdev=162.45
可以看到随机写IOPS约为2.24万，平均延迟升高到0.54毫秒。这个数据如果和你业务预期有差距，可以考虑更换更高性能级别的ESSD，或者调整应用层的写聚合策略。需要注意，随机写测试会磨损云盘，测试时间不宜过长，60秒足够获得稳定曲线。
还有一类混合读写测试，使用--rw=randrw --rwmixread=70可以模拟70%读、30%写的场景。混合负载下的IOPS一般介于纯读和纯写之间，但延迟分布会更复杂，因为读写请求会争抢同一块盘的处理能力。
四、结果解读与云盘选型优化建议
拿到fio数据后，第一件事是判断测试是否真的碰到了云盘上限。可以增加队列深度或并发任务数再做一轮，如果IOPS不再明显增长，同时CPU空闲率还很高，说明瓶颈在云盘或实例存储带宽配额；如果CPU某个核被打满，则可能是fio本身或中断处理成了瓶颈。阿里云不同实例规格对云盘IOPS和吞吐量有独立限制，例如部分突发性能实例的存储性能会被限制得比较低，测试前务必查一下实例规格的存储IOPS上限。
ESSD云盘从PL0到PL3，4K随机读写IOPS上限逐级提高。PL1通常适合一般中小型数据库，PL2可以支撑更高并发的业务，PL3则面向大型核心库和高频交易系统。但云盘级别越高，单位容量成本也越高。通过fio实测，你可以把业务当前需要的IOPS和云盘标称做对应，避免为用不到的峰值性能付费。
另外，如果单块云盘无法满足性能要求，还可以考虑多块云盘做条带化。Linux的mdadm可以把多块ESSD组成RAID0，4K随机读写在理想情况下可以接近线性叠加。不过RAID0会引入额外CPU消耗和故障风险，只适合对可用性要求不高的临时测试或读写分离从库。更稳妥的做法是升级到更高性能级别的云盘，或者使用本地NVMe盘承载高IOPS场景。
最后提醒一个常见误区：不要把文件系统的顺序写带宽当成随机IOPS。很多应用日志看起来是顺序追加，但文件系统元数据更新、日志滚动、检查点操作都会产生随机小IO。用fio的4K随机读写测试，比单纯看顺序带宽更能反映真实存储压力。