生产环境磁盘压测必须遵循不干扰业务、可中断、可归因、结果对标真实负载四大原则：明确目标（如验证RAID卡IOPS或复现MySQL IO模式），选用fio精准建模（bs/iodepth/rw需匹配业务），严格避坑（必加--direct=1和--invalidate=1），执行时绑定CPU亲和性、限速保底、设置超时，并同步监控iostat指标，最终聚焦延迟分布、队列堆积与响应一致性解读结果。
直接上生产环境压测磁盘，不能靠 `dd` 或 `fio` 一跑了事。核心原则是：**不干扰业务、可中断、可归因、结果能对标真实负载**。下面分四步说清楚怎么做。
明确压测目标和业务对齐点
先问清楚：你到底想验证什么？不同目标对应完全不同的压测设计：
- 验证新盘/RAID卡是否达标 → 关注 IOPS、平均延迟、99%延迟、队列深度响应（用 fio 模拟随机读写）
- 排查线上 IO 延迟突增原因 → 复现业务典型 IO 模式（如 MySQL 的 16K 随机读 + 4K 日志写），不是跑满盘
- 评估文件系统挂载参数影响 → 同一硬件下，对比 `noatime,barrier=0,commit=60` 等组合下的延迟抖动
- 检验 SSD 耐久性或固件稳定性 → 长时间（24h+）混合负载 + `memtester`+`smartctl -a`交叉验证
选对工具，避开常见陷阱
推荐主力工具是 fio，它能精准控制块大小、IO 类型、队列深度、运行时长，且支持直接读写裸设备（绕过文件系统缓存干扰）。关键避坑点：
- 别用
dd if=/dev/zero of=test bs=1M count=1000—— 它只测顺序写，且受 page cache 影响极大，结果无参考价值 - 避免
fio --rw=randread --bs=4k --iodepth=32这类“通用参数” —— 如果你的数据库实际用的是 16K 页，就该测 16K - 必须加
--direct=1（绕过 page cache）和--invalidate=1（每次清缓存），否则测的是内存不是磁盘 - 生产环境建议用
--time_based --runtime=300（5分钟定时），而不是--nrfiles=1 --size=10G（固定数据量），避免长时间占满空间
安全执行策略：低侵入、可熔断
上线前必须做三件事：
-
绑定 CPU 和 IO 亲和性：用
taskset -c 0-3 fio ...把压测进程锁在非业务核心上，防止调度争抢 -
限速保底：用
cgroups v2或ionice -c 3（空闲级）+iotop实时盯住 %util，一旦超过 70% 就手动终止 -
设置超时与自动退出：fio 加
--timeout=600，并配合timeout 600 fio ...双保险，防进程卡死 -
监控同步开启：压测同时跑
iostat -x 1和cat /proc/diskstats，重点关注r_await、w_await、avgqu-sz是否异常跳变
结果解读：看数字背后的业务含义
别只盯着 IOPS 和 MB/s。真正决定业务体验的是：
- 延迟分布：p99 > 20ms 对 OLTP 是红线；p99 > 100ms 对日志盘已属异常
-
队列堆积：
avgqu-sz持续 > 队列深度（如 NVMe 默认 64），说明设备已饱和，再加压只会拉高延迟 - 响应一致性：标准差 / 均值 > 0.3，说明延迟抖动大——可能是 RAID 卡缓存策略不当或后台 GC 干扰
-
对比基线：拿压测结果和业务高峰期的
iostat -x 1实际值比，如果压测延迟比线上还低，说明瓶颈不在磁盘本身
