fio测峰值吞吐量需用libaio+direct=1直通磁盘，bs=1M/4M、numjobs=16、iodepth=64以打满NVMe带宽，避免小块测IOPS、单线程或sync引擎导致结果失真。
用 fio 测峰值吞吐量，别用 dd
dd 只能测单线程顺序吞吐，结果偏高且不反映真实负载能力。峰值吞吐量（尤其是顺序读写 MB/s）必须用 fio 控制并发、队列深度和 I/O 引擎来逼近硬件极限。
- 必须用
libaio+direct=1：绕过缓存，直通磁盘，否则测的是内存带宽 - 块大小选
bs=1M或bs=4M：小块（如 4K）测的是 IOPS，不是吞吐量 - 并发数和队列深度要拉满：
numjobs=16+iodepth=64才可能打满 NVMe 或多盘 RAID 的带宽 - 示例命令（顺序写峰值）：
fio --name=seqwrite --ioengine=libaio --rw=write --bs=1M --size=4G --numjobs=16 --iodepth=64 --direct=1 --group_reporting --runtime=30 --time_based
输出里看bw字段（单位通常是 KiB/s，除以 1024 得 MB/s）
iostat -x 2 看实时吞吐，但不是“峰值测试”
iostat -x 2 不主动压测，只观察当前负载下的瞬时吞吐（rkB/s 和 wkB/s），单位是 KiB/s，需手动换算。
- 它的数值是滚动平均值，每 2 秒刷新一次，无法捕捉短时峰值
- 若看到
await> 5ms 且%util接近 100%，说明设备已在饱和边缘，此时的rkB/s/wkB/s才接近实际可用峰值 - 别把单次
iostat输出当峰值指标——它只是快照，不是压力测试结果
SSD 和 NVMe 的峰值容易被“假低”误导
很多用户跑出远低于标称值的结果，问题不在工具，而在条件没对齐：- SSD 测试前未预留空闲空间（建议 ≥20% 容量空闲），垃圾回收会拖慢连续写
- NVMe 设备用了
ioengine=sync而不是libaio，完全无法发挥并行能力 - 测试文件小于设备缓存（如只写 1G），导致部分数据仍走 DRAM 缓存，测不准
- 挂载参数含
noatime,barrier=0等优化项未关闭，影响可比性
别在根分区或系统盘上跑峰值测试
-fio 拉满吞吐时会产生大量后台 I/O，可能触发内核 OOM killer，或让 ssh、systemd 响应卡顿
- 临时文件务必写到目标盘的独立挂载点（如 /mnt/ssd/test），而非 /tmp 或 /home
- 测试完记得清空文件：rm -f /mnt/ssd/test.fio，避免残留占满空间
真正能打出峰值的，从来不是参数最简的命令，而是把设备特性、队列机制、缓存策略全考虑进去的一组配置。漏掉任意一环，测出来的就不是“磁盘能跑多快”，而是“你让它跑多慢”。
