fio才能准确测4K随机IOPS，dd仅支持顺序读写；关键参数包括--rw=randread、--bs=4k、--direct=1、--iodepth=32、--numjobs=4、--runtime=60和--group_reporting，且需清缓存、直连设备、排除后台干扰。
直接用 fio 测 4K 随机读，别碰 dd
dd 根本测不了真正的 4K 随机 IOPS —— 它默认顺序写/读，加 oflag=direct 只能绕过缓存，但访问模式仍是线性的。你看到的 “IOPS = 123 MB/s ÷ 4 KB” 是数学换算，不是实际发出的随机请求次数。真正要压出磁盘在小块、乱序场景下的能力，必须用 fio。
fio 随机读写命令的关键参数不能漏
以下是最常用、最贴近生产环境的 4K 随机读写命令模板，每个参数都有明确作用：
-
--rw=randread或--rw=randwrite：必须显式指定，randread不是read，后者是顺序读 -
--bs=4k：块大小必须是4k（注意小写 k），写成4K或4096在某些 fio 版本里会静默失败或降级为默认值 -
--direct=1：强制 Direct IO，否则数据走 page cache，测的是内存速度 -
--iodepth=32：队列深度设为 32，模拟典型高并发负载；太低（如 1）测不出 NVMe 盘的真实能力，太高（如 128）可能触发设备限流或掩盖真实延迟 -
--numjobs=4：开 4 个并行 job，比单 job 更能打满队列；但别盲目堆到 16+，除非你真有 16 个业务线程在刷盘 -
--runtime=60：用时间而非数据量控制测试时长，避免因盘容量小导致提前退出 -
--group_reporting：合并所有 job 的统计，否则输出里一堆重复行，IOPS 值还得手动加总
测试前必须清理干扰，否则结果不可信
哪怕只是后台有个 rsync 在同步日志，iostat -x 2 里的 r/s 和 w/s 就会飘。实操中容易忽略的点：
- 运行前执行
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'，清空 page cache 和 dentries/inodes - 确认目标设备没被 LVM、mdadm、LVM cache 或任何用户态代理（如 qemu-img、docker overlay）包裹，
fio --filename=/dev/sdb要直连物理盘或 RAID 设备节点 - 用
iotop -oP看一眼有没有残留进程在刷盘；如果%util在测试中始终 --numjobs 或--iodepth - SSD/NVMe 盘首次测试前建议先做一次全盘写（
fio --rw=write --bs=1M --size=100% --direct=1 --name=precondition ...），避免新盘因未 TRIM 导致首测延迟虚高
看结果时盯住 IOPS、lat 和 clat，别只扫 BW
fio 输出里真正反映 4K 随机性能的是这三列：
-
IOPS：就是你要的数字，比如read: IOPS=153k，它由BW（单位 KiB/s）除以bs自动算出，前提是bs=4k -
clat (usec)：completion latency，即从内核提交 IO 到硬件完成的时间，这才是磁盘真实响应速度；如果avg超过 200 μs，或者99.90th超过 1 ms，说明盘已开始排队或掉速 -
lat (usec)：包含软件栈延迟（如文件系统、驱动），通常比clat高 10–50 μs，仅作参考
别被 BW=598MiB/s 迷惑——那是吞吐量，对 4K 场景毫无意义；同样，slat（submission latency）如果异常高（> 10 μs），说明 CPU 或调度器成了瓶颈，不是盘的问题。
