先用 iostat -x 1 观察 %util＞80% 且 await 显著高于 svctm，确认磁盘瓶颈；dd 测吞吐须加 direct 参数绕过缓存；fio 模拟真实随机小 IO 负载并设 direct=1、sync=1；iotop -o 定位高 IO 等待进程；最终需关联多指标判断根因。
看 %util 和 await，先确认是不是真瓶颈
别一上来就跑压测工具。先用 iostat -x 1 看两眼：如果某块盘的 %util 长期 >80%，且 await 明显高于 svctm（比如 await=25ms 而 svctm=0.3ms），基本可以断定是磁盘层卡住了。注意：%util 接近 100% 并不等于“完全不能干活”，只是说明它几乎没空闲时间处理新请求；而 await 高才真正反映用户感受到的慢。
用 dd 测吞吐量，但必须绕过缓存才真实
dd 简单快，但默认走 Page Cache，测出来的是内存速度，不是磁盘真实性能。关键参数只有两个：oflag=direct（写）和 iflag=direct（读）。例如：
dd if=/dev/zero of=/mnt/testfile bs=1M count=1024 oflag=direct
这条命令才是真正压磁盘写入能力；读的时候也得加 iflag=direct，否则可能从缓存里直接拿数据，结果虚高好几倍。常见坑：没清缓存就反复测、没指定 bs 导致小块写放大延迟、测试文件放在系统盘上干扰结果。
用 fio 模拟真实负载，别只信顺序读写
数据库、日志、容器镜像这些场景全是随机小 IO，而 dd 默认是大块顺序操作，结果参考价值极低。fio 才能精准控制：rw=randread、bs=4k、iodepth=32——这才是 MySQL 的典型压力模型。配置里一定要设 direct=1 和 sync=1（如需测 fsync 延迟），否则又回到缓存层面。别漏掉 runtime=60，不然默认只跑一次就停，数据没代表性。
查进程级 IO，iotop -o 是最省事的入口
知道磁盘忙，但不知道谁在干——iotop -o 一眼定位。它显示的 IO> 列是进程等待 IO 的时间占比，比单纯的读写 MB/s 更能暴露问题根源。比如一个 Python 脚本 IO> 占 92%，但 DISK WRITE 只有 2MB/s，大概率是频繁小 write+fsync 拖垮了队列。这时候杀进程没用，得去看它是不是在疯狂刷日志或同步写临时文件。
真正难的不是测出数字，而是把 iostat 的 avgqu-sz、fio 的 lat (us) 分布、iotop 的阻塞行为串起来，判断是硬件极限、文件系统锁争用，还是应用逻辑缺陷。多数人卡在第一步：把缓存当磁盘，把平均值当真相。
