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（扩展模式）才能看到这些字段，否则你看到的只是上层逻辑请求的统计，不是实际物理吞吐。

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

• 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 定位——这些混淆一旦发生，排查方向就全偏了。