iostat -x 是查看真实磁盘吞吐量和 iops 的唯一可靠方式，因其 rmb/s、wmb/s 绕过 page cache 直接反映块设备速率，r_ios、w_ios 为底层驱动上报的实际 i/o 次数，而普通 iostat 的 rkb/s、wkb/s 和 r/s、w/s 受缓存、请求合并及多路径干扰严重失真。
iostat -x 是查看真实磁盘吞吐量的唯一可靠方式，其他工具（包括 dstat、vmstat、dd 默认行为）要么受 page cache 干扰，要么不反映物理设备实际数据速率。
为什么必须用 iostat -x 而不是普通 iostat
普通 iostat 输出的 rkB/s 和 wkB/s 是 VFS 层统计值，含大量缓存命中；r/s 和 w/s 会被请求合并、延迟下发、多路径重排，完全不能当 IOPS 用。只有加 -x（扩展模式）后出现的 rMB/s 和 wMB/s 字段，才是绕过 page cache、直接从块设备驱动上报的真实吞吐，单位统一为 MB/s，可对标 SSD 厂商标称值。
-
iostat -xk 1：每秒刷新一次，单位 KB，但字段名仍显示 MB（历史兼容），数值已换算 -
iostat -xh 1：自动换算单位（KB/MB/GB），更易读，但底层仍是同一数据源 - 不加
-x的输出里没有rMB/s、wMB/s、r_ios、w_ios，等于没看关键指标 - 若只关注某盘，如
sdb，用iostat -xk 1 /dev/sdb；要看所有分区，加-p ALL
iostat -x 输出中哪些字段代表真实吞吐和 IOPS
别被字段名误导：rkB/s 不是吞吐，r/s 不是 IOPS。真实指标只在 -x 模式下存在：
-
rMB/s和wMB/s：真实读/写吞吐量（MB/s），已剔除缓存干扰，是带宽瓶颈判断依据 -
r_ios和w_ios：真正下发到设备的读/写请求数，即真实 IOPS -
%util接近 100% 且await显著升高 → 队列积压，不是设备慢，而是并发或介质响应能力不足 -
avgrq-sz×r_ios× 512 ≈rkB/s× 1024？若偏差大，说明有压缩、去重、协议头开销（如 NVMe 多队列）
为什么 dstat 不适合分析真实吞吐瓶颈
dstat 的 disk read/disk write 列来自 VFS 层，和 free 一样受 page cache 主导——缓存命中时它可能显示 200 MB/s，而 iostat -x 显示 0。它无法区分逻辑请求与物理落盘，也没有 avgqu-sz、r_ios 等排队指标。
-
dstat -D sda --disk-util可看设备级利用率，但数值与iostat -x不一致是常态，不可交叉比对 -
dstat适合快速扫一眼“有没有明显异常”，比如某盘突然飙高；归因必须切回iostat -x+iotop -o - 它不支持
oflag=direct类语义，无法模拟 bypass-cache 场景，不适合性能调优闭环
如何验证你看到的吞吐是否“真实”
真实吞吐必须排除缓存、设备 DRAM 缓存、RAID 卡 write-back 缓存三层干扰。仅靠监控不够，需配合测试验证：
- 用
dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct测顺序写：绕过 page cache，但 SSD 内部 DRAM 缓存仍生效 - 若要禁用设备缓存、测同步写极限，改用
oflag=dsync或conv=fdatasync，代价是吞吐暴跌、延迟飙升 - 不要在系统盘或已有数据的盘上直接跑
dd，避免覆盖分区表或元数据 - fio 更精准：
fio --name=randwrite --ioengine=libaio --direct=1 --sync=1 --rw=randwrite --bs=4k --numjobs=4 --runtime=60才接近数据库 WAL 场景
真正卡住人的地方，往往不是看不懂字段，而是把 rkB/s 当吞吐、把 r/s 当 IOPS、用 dstat 结论代替 iostat -x 判断——这些都会导致你优化错方向。
