必须加 direct=1，否则测的是内存而非磁盘；未绕缓存时4k随机读iops虚高5–10倍，加direct=1后nvme真实值为60k–90k；遇operation not supported需改buffered=1并注明“非直通模式”。
必须加 direct=1，否则测的不是磁盘是内存
默认不加 direct=1 时，fio 全部 IO 都走 page cache，randread 可能全从内存返回，IOPS 虚高 5–10 倍。实测 NVMe 盘在未绕缓存时，4K 随机读 IOPS 能报出 200k+，但加 direct=1 后真实值通常只有 60k–90k。
- 遇到
Operation not supported错误，说明内核或设备不支持直接 IO（常见于老旧内核或某些裸 RAID 设备），此时改用buffered=1，但结论里必须注明“非直通模式” - 别信
conv=fdatasync或oflag=dsync—— 它们只保证落盘，不绕缓存 - 若测试对象是文件系统（如
/mnt/data/testfile），确保该路径挂载在目标盘上，且不与业务数据混用；若测裸设备（如/dev/nvme0n1），务必确认已卸载、无任何进程访问，否则会破坏数据
rw=randread 和 rw=randwrite 的关键参数怎么配
数据库、虚拟机这类负载盯的是 4K 随机读写能力，bs=4k 是硬性起点，不能用 bs=16k 或 bs=1m 混着测——IOPS 数值会完全不可比。
宝塔Linux面板11.8.1
下载
宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。
-
iodepth=32是多数 SSD 的合理起点：SATA SSD 超过 16 就易掩盖延迟差异，NVMe 可试 64，但别盲目堆高 -
numjobs=4比单线程更能压出设备并发能力，但注意：两个numjobs=4的 job 并发跑，总 IOPS 不是单个的 2 倍——尤其 SATA 盘常因控制器争抢导致吞吐塌缩 - 加
--time_based --runtime=60，避免因--size=1G提前跑完而退出；同时设--size=10G（至少 2 倍于主机内存），防 swap 干扰 - 别漏
--group_reporting，否则每个 job 单独输出，IOPS 总和得手动加，容易算错
看懂 fio 输出里真正决定业务扛不扛得住的三行
fio 报告末尾的汇总里，bw 最显眼但最误导人——数据库根本不在乎 MB/s，它卡在 IOPS 和延迟上。
-
iops=31.9k：这才是 OLTP 场景的生死线；低于预期值 30%，先查iodepth是否设太低，再查是不是队列积压 -
lat (usec): min=123, max=18920, avg=3210：单位是微秒（μs），不是 ms；avg > 10000（即 10ms）说明磁盘已吃紧；max突增往往意味着硬件响应异常或队列深度溢出 -
bw=124.5MiB/s：注意单位是MiB/s（1024 进制），不是MB/s（1000 进制），差约 7%；大文件场景才真看这个
为什么你跑出来的 IOPS 总是不稳定或偏低
不是参数写错了，而是环境干扰没清干净。真实磁盘性能被掩盖，往往因为几个隐形因素。
- 测试前没停掉
rsyslog、auditd、systemd-journald等后台刷盘服务，它们会偷偷抢 IO 队列 - 没绑核：NVMe 测 IOPS 时，用
taskset -c 1-4 fio ...把进程固定到专用 CPU 核，避免调度抖动 - 散热不足：机械盘超 50°C、RAID 卡超 70°C 就开始降频；测前先
ipmitool sensor看温度，风扇转速不够就手动提 - SSD 没预热：随机写测试前，先用
fio -rw=randwrite -bs=4k -direct=1 -size=50g写满一遍再正式测，否则擦写放大会让前 10 秒 IOPS 虚高、后 50 秒骤降
fio -name=randread -ioengine=libaio -rw=randread -bs=4k -direct=1 -iodepth=32 -numjobs=4 -runtime=60 -time_based -group_reporting -filename=/dev/nvme0n1。别省参数，少一个都可能让结果失真。
