iostat -x 1 是最直接可靠的磁盘性能诊断起点，因其 r_ios/w_ios 和 rMB/s/wMB/s 反映驱动层真实 I/O 次数与绕过缓存的吞吐，避免 page cache 和调度器干扰；普通 iostat 的 r/s、w/s 易低估实际 IOPS 达 3–10 倍。
iostat -x 1 是最直接、最可靠的起点，其他方式容易误判——比如只看 %util 或 top 里的 wa 值，会漏掉排队严重但并发不高的真实瓶颈。
为什么必须用 iostat -x 而不是普通 iostat
普通 iostat 输出的 r/s 和 w/s 是 VFS 层统计的逻辑请求次数，会被 page cache 合并、被 IO 调度器延迟下发；而 iostat -x 的 r_ios 和 w_ios 是驱动层真实发给设备的 I/O 次数，才是可比的 IOPS。
-
r_ios/w_ios：单位是「次/秒」，对应物理设备真实处理的读写请求数 -
rMB/s/wMB/s：绕过 page cache 的吞吐，单位统一为 MB，和厂商标称值可比 - 只跑
iostat不加-x→ 把r/s当 IOPS，结果可能比实际低 3–10 倍（尤其在日志轮转、数据库 checkpoint 场景下） - 用
rkB/s算吞吐 → 它包含缓存命中流量，无法反映真实落盘压力
iostat -x 输出里哪些字段真有用
运行 iostat -dx 2 3（每 2 秒刷新一次，共 3 次），跳过首行冷启动噪音，重点关注：
-
%util：持续 ≥ 80% 表示设备饱和；但 NVMe 多队列下该值可能失真，此时更要看await和avgqu-sz -
await：> 10ms 就需警惕，> 50ms 基本确认存在排队瓶颈（注意：svctm已弃用，仅作参考） -
avgqu-sz：是运行时平均队列长度，不是配置上限；持续 > 设备硬件队列深度 × 0.8 才说明真堵了 -
avgrq-sz：若长期 64KB，偏向顺序流（如备份、日志归档）
看到高 wa 值或低 %util 就放松？别急着下结论
top 里的 wa（等待 IO 的 CPU 时间百分比）只能粗略提示——wa 高说明有 IO 等待，但无法区分是磁盘慢、还是进程在等锁/网络；%util 低也不代表不忙：
-
%util只有 30%，但await达到 200ms → 单个请求等了很久，只是并发不高而已 - 在 KVM 虚拟机里跑
iostat -x→r_ios是 guest kernel 发给virtio-blkqueue 的次数，不等于宿主机物理 SSD 的 NAND 操作次数 - 忽略
rrqm/s和wrqm/s→ 如果合并率 > 70%，说明上层 IO 是顺序/可聚合的；如果几乎为 0，大概率是随机小 IO，优化方向完全不同
单靠 iostat 不够？配合 iotop 锁定具体进程
iostat 告诉你“哪块盘扛不住”，iotop 告诉你“谁在猛打它”：
- 以 root 运行
sudo iotop -o，只显示当前有 IO 活动的进程 - 按
P键按写入速率降序排列，按R键按读取速率排序 - 按
T启用树状视图，看清父子进程关系（比如 pg_dump 调用 gzip 导致高写） - 若
iotop显示某进程 IO 很高，但iostat -x的r_ios却很低 → 很可能是它在反复读同一块缓存页，没真正落盘
真正卡点往往藏在多层抽象之下：LVM、dm-crypt、NVMe 多队列、甚至 RAID 卡 write-back cache —— iostat -x 看到的是 block layer 统计，不是硬件 NAND 或 controller flush 的真实耗时。别只盯着一个数字调优，得把 await、avgqu-sz、r_ios 和 iotop 的 PID 对上号，再查 /sys/block/xxx/queue/scheduler 和 /sys/block/xxx/device/queue_depth，才可能摸到根子。
