iostat -x 的 rMB/s 和 wMB/s 才是真实吞吐量，因其绕过 page cache、直接反映落到块设备的数据速率，单位统一为 MB，可对标厂商标称值；而普通 iostat 的 rkB/s/wkB/s 受缓存干扰、虚高失真。
iostat -x 是查看真实读写吞吐量的最可靠方式，dstat 只适合粗略观察，不能替代它。
为什么 iostat -x 的 rMB/s 和 wMB/s 才算真实吞吐量
普通 iostat 输出的 rkB/s 和 wkB/s 会被 page cache 干扰，数值虚高；而 iostat -x 中的 rMB/s 和 wMB/s 是绕过缓存、真正落到块设备的数据速率，单位统一为 MB，可直接对标厂商标称值。
必须加 -x（扩展模式）才能看到这些字段，否则你看到的只是上层逻辑请求的统计，不是实际物理吞吐。
-
iostat -xk 1：每秒刷新一次，单位 KB，但列名仍显示 MB（这是历史兼容行为，数值已换算） - 重点关注
rMB/s（读吞吐）、wMB/s（写吞吐）、%util（利用率）、await（平均等待毫秒） - 若
%util接近 100% 且await显著升高，说明 I/O 队列积压，吞吐瓶颈不在带宽而在调度或介质响应能力
dstat 能看吞吐但不推荐用于性能分析
dstat 是一个多功能实时监控工具，能同时显示 CPU、内存、网络和磁盘 IO，但它对磁盘吞吐的采样逻辑较粗，且默认不区分缓存/直通路径，disk read 和 disk write 列反映的是 VFS 层数据，含 page cache 影响，不适合定位真实瓶颈。
- 运行
dstat -D sda --disk-util可以看到设备级吞吐和利用率，但数值与iostat -x不一致是常态 -
dstat没有r_ios/w_ios或avgqu-sz等关键排队指标，无法判断是否因小 IO 随机访问压垮队列深度 - 它适合快速扫一眼“有没有明显异常”，比如某盘突然飙到 200MB/s 写入，但进一步归因必须切回
iostat -x+iotop -o
测试裸设备吞吐时，dd 的 oflag=direct 和 oflag=dsync 区别很关键
用 dd 测原始吞吐，目标不是跑出最高数字，而是排除干扰、逼近物理极限。选错 flag 会导致结果完全失真。
-
oflag=direct：绕过 page cache，但写操作可能仍被设备缓存暂存（如 SSD 内部 DRAM 缓存），测的是“带设备缓存的吞吐” -
oflag=dsync或conv=fdatasync：每次写都强制刷盘，禁用设备缓存，测的是“同步写延迟+吞吐”，更贴近数据库 fsync 场景 - 顺序写测试建议用
dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct；测延迟敏感场景（如 WAL 日志）才用dsync - 注意：不要在系统盘或已有数据的盘上直接跑
dd，避免覆盖关键分区表或文件系统元数据
真正卡住人的地方，往往不是看不懂 iostat 字段，而是把 r/s 当 IOPS、把 rkB/s 当吞吐、用 dstat 结论代替 iotop 定位——这些混淆一旦发生，排查方向就全偏了。
