iostat -x 1 是唯一能查到真实磁盘读写吞吐量的方式，因其 rMB/s 和 wMB/s 绕过 page cache、直接从块设备驱动上报，而普通 iostat 的 rkB/s/wkB/s 和 r/s/w/s 受缓存、请求合并及多路径干扰严重失真。
iostat -x 1 是唯一能查到真实磁盘读写吞吐量的方式，其他命令看到的几乎都是带缓存的虚高值。
为什么必须用 iostat -x 而不是普通 iostat
普通 iostat 输出的 rkB/s 和 wkB/s 是 VFS 层统计，大量命中 page cache 后数值严重失真；r/s 和 w/s 又被内核请求合并、多路径重排干扰，根本不能当 IOPS 用。只有加 -x 后出现的 rMB/s 和 wMB/s 字段，才是绕过缓存、直接从块设备驱动上报的真实吞吐（单位 MB/s），可对标 SSD 厂商标称值。
-
iostat -xk 1：每秒刷新，单位 KB，但字段名仍显示 MB（历史兼容） -
iostat -xh 1：自动换算单位（K/M/G），读起来更直观，字段名不变 - 不加
-x就没有rMB/s、wMB/s、r_ios、w_ios，等于没看关键指标
怎么只看某块盘或所有分区
默认 iostat -x 1 显示所有块设备，但实际场景常需聚焦：
- 只盯
/dev/sdb：用iostat -xh 1 /dev/sdb - 要看 LVM 或分区（如
sda1、nvme0n1p1）：加-p ALL，即iostat -xh 1 -p ALL - 注意：
-p必须和-x共存，单独-p不生效
别把 iotop 或 dstat 当吞吐依据
iotop 显示的 DISK WRITE 是进程调用 write(2) 的总量，含 page cache；dstat 的 disk write 列同样来自 VFS 层，缓存命中时可能显示 200 MB/s，而 iostat -x 显示 0 —— 两者根本不在同一数据层。
-
iotop -o -d 1适合快速定位“谁在刷盘”，但不能用来判断磁盘真实带宽 -
dstat -D sda --disk-util能看利用率，但数值与iostat -x不一致是常态，不可交叉比对 - 真要归因，必须切回
iostat -x+iotop -o组合使用
验证你看到的吞吐是否“落地”了
iostat -x 的 wMB/s 是内核块层统计，它仍可能被设备驱动进一步合并（比如 NVMe 多队列中一个 request 含多个 cmd）。要确认是否真发到了物理介质，得看 /sys/block/sda/stat 的第 5 列（writes completed）——那是设备层确认完成的计数，和 w_ios 对不上就说明有中间层缓冲或丢包。
- 对比
r_ios × avgrq-sz × 512和rkB/s × 1024：若偏差大，说明有压缩、去重或协议头开销 -
%util接近 100% 且await显著升高 → 队列积压，不是设备慢，而是并发或介质响应跟不上 -
%util低但await高 → 单个请求本身慢（如小块随机读、RAID 卡降速、NVMe flush 延迟）
真正卡住人的地方，往往不是看不懂字段，而是把 r/s 当 IOPS、把 rkB/s 当吞吐、用 dstat 结论直接下判断——这些动作都会让问题排查绕远路。
