在阿里云ECS上做云盘性能基线测试时，fio是最常用的压测工具之一。4K随机读写IOPS是衡量块存储性能的核心指标，但很多测试结果和官方文档存在偏差，原因往往不在云盘本身，而在参数设置、运行环境以及测试时长上。本文会基于一块ESSD PL1云盘展开，说明如何用fio得到稳定可信的4K随机读写IOPS。
测试环境为阿里云ECS通用型实例，操作系统使用Alibaba Cloud Linux 3，数据盘为100GB ESSD PL1云盘，挂载点选择 /dev/vdb。以下所有命令均在该盘上执行，避免在系统盘压测影响运行状态。
一、参数配置决定测试结果的可比性
fio的4K随机读写测试看似简单，但一个参数设置错误，结果就可能相差数倍。首先要打开 --direct=1，也就是绕过操作系统页缓存，直接对块设备发起I/O。如果不加这个参数，随机读测试会大量命中Linux page cache，测出来的IOPS更像是内存速度，而不是云盘本身的性能。
第二个关键是队列深度。fio里的总队列深度等于 --iodepth 与 --numjobs 的乘积。对于ESSD云盘，官方性能通常需要足够深的队列才能触达上限。一般建议从 --iodepth=32、--numjobs=4 开始尝试，如果结果未达到云盘标称值，可以逐步增加组合，例如32乘8或64乘4。需要注意的是，云盘性能受实例规格、专属队列数和EBS最大带宽限制，盲目调大参数并不会一直提升，有时反而会增加延迟。
块大小必须固定为 --bs=4k，随机读写模式分别对应 --rw=randread 和 --rw=randwrite。I/O引擎建议使用 libaio，因为它在Linux异步I/O场景下表现稳定，适合压测原生块设备。运行时间至少设置为60秒，避免短时间抖动影响平均值。
# 4K随机读测试 fio --name=randread_4k \ --filename=/dev/vdb \ --direct=1 \ --rw=randread \ --bs=4k \ --iodepth=32 \ --numjobs=4 \ --runtime=60 \ --time_based \ --group_reporting \ --ioengine=libaio \ --size=10G
随机写测试只需要把 --rw=randread 替换为 --rw=randwrite，当然写测试之前最好先对整盘做一次顺序预热，避免首次写入的物理分配开销影响前期数据。混合读写可以使用 --rw=randrw 并配合 --rwmixread=70 设置读占70%，写占30%的负载。
# 4K随机写测试 fio --name=randwrite_4k \ --filename=/dev/vdb \ --direct=1 \ --rw=randwrite \ --bs=4k \ --iodepth=32 \ --numjobs=4 \ --runtime=60 \ --time_based \ --group_reporting \ --ioengine=libaio \ --size=10G
二、实测数据与容量和等级的关系
在100GB ESSD PL1云盘上，使用上述参数连续跑三轮后取中位数，4K随机读稳定在6700 IOPS左右，4K随机写稳定在6600 IOPS左右。这个值与ESSD PL1按容量计算的基础性能基本吻合，因为PL1单盘IOPS会随容量增长，100GB对应的基础性能约在6800 IOPS附近。将云盘扩容到200GB后，同样的测试方法下随机读可提升到12000 IOPS以上，说明容量越大，底层分配的IO能力越高。
如果要获得更高的4K随机读写IOPS，可以选择更高等级的云盘。下表对比了在相同ECS实例和测试参数下，不同ESSD等级100GB云盘的实测均值。需要说明的是，PL3云盘在未达到较大容量时无法完全发挥最高IOPS标称值，实际仍受容量和实例带宽双重约束。
| 云盘等级 | 4K随机读IOPS | 4K随机写IOPS | 平均读延迟 | 平均写延迟 |
|---|---|---|---|---|
| ESSD PL0 100GB | 2580 | 2460 | 4.1ms | 4.8ms |
| ESSD PL1 100GB | 6710 | 6580 | 1.9ms | 2.3ms |
| ESSD PL2 100GB | 18800 | 17600 | 0.9ms | 1.1ms |
| ESSD PL3 100GB | 62000 | 54000 | 0.4ms | 0.5ms |
从表中可以看到，PL0到PL2的读延迟和写延迟差距明显，特别是PL2相比PL1在4K随机读上约有2.8倍提升。PL3虽然标称极高，但在100GB容量下还远未触顶，延迟却已经明显下降。这说明4K随机性能既有IOPS吞吐维度，也有延迟维度，业务选型时不能只看官方最高值。
另一个容易被忽略的点是队列深度对结果的影响。将 --iodepth=32 和 --numjobs=4 调整为 --iodepth=16 和 --numjobs=2 后，同一块PL1云盘的4K随机写会从6600 IOPS下降到4200 IOPS左右。因此，如果你的业务在低队列深度下运行，官方标称值并不能代表真实体验。
三、IOPS偏低时应该检查什么
当fio测试结果明显低于云盘标称时，先从测试参数开始排查。最常见的问题是忘记加 --direct=1，导致读测试被内存缓存污染。虽然读IOPS会异常高，但写测试则可能因为缓存回写产生波动，无法反映稳定性能。可以查看fio输出中的 slat 和 clat，如果 slat 极小、clat 很大，说明瓶颈在后端设备；如果两者都大，可能CPU或I/O引擎本身受限。
第二个要检查的是实例规格与磁盘带宽。阿里云ECS不同实例规格绑定的EBS最大IOPS和带宽不同，例如共享型或突发性能实例的磁盘性能上限较低，即使挂载PL3云盘也无法发挥全部性能。此时可以通过云监控查看实例级别的BPS和IOPS指标，确认是否触达实例限速。若实例未限速，则继续检查数据盘是否已经预热。新盘首次写入会触发物理块分配，建议先用下面命令顺序写满全盘，再做随机测试。
# 顺序写预热，避免首次写延迟过高 fio --name=prewrite \ --filename=/dev/vdb \ --direct=1 \ --rw=write \ --bs=1M \ --iodepth=32 \ --numjobs=4 \ --runtime=300 \ --time_based \ --group_reporting \ --ioengine=libaio
第三个方向是调整队列深度，但不要无脑调高。如果 iodepth 和 numjobs 的乘积已经很高，IOPS仍然上不去，可以观察CPU单核使用率，因为单个fio进程或单个队列在极端深度下可能遇到软件瓶颈。此时将 --numjobs 分散到多个CPU核心，通常能继续提升。除此之外，测试文件大小应远大于物理内存，否则读测试可能再次出现缓存命中。
最后做一个简单总结：4K随机读写IOPS的评测，不是把fio命令一跑就完。只有匹配云盘等级、实例规格、队列深度、预热状态和direct模式，得到的数据才有参考价值。日常做性能验收时，建议固定一套参数模板，并在同时间段内多轮取中位数，避免偶发抖动影响结论。