在 iostat -x 的所有字段里，rrqm/s 和 wrqm/s 是少数能够直接反映 IO 合并情况的指标。它们表示的是：每秒有多少读/写请求在进入设备前被调度器合并掉。这里有一个很容易混淆的点——它统计的不是“合并后总共减少了多少请求”，而是“有多少请求参与了合并”。另外，数值显示为 0，也不能简单理解为完全没有发生合并；也可能是因为队列太浅、访问地址过于分散，或者请求派发得太快，来不及进入排队阶段就被处理掉了。要确认合并是否真的发生，还是需要配合 blktrace 来看：blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'M'，只要看到 M 标记，就说明合并确实发生过。
怎么用 iostat -x 看真实合并效率
rrqm/s 和 wrqm/s 是最直接标示合并行为的字段，但它们并不是“省掉了多少请求”，而是“调度器在进入队列前主动合并掉的次数”。数值为 0 也不代表没有合并——可能是因为 IO 太零散、队列太浅，或者请求刚进入就被立即派发，根本没有排队机会。
真正体现合并效果的，更多是这些间接指标：
a vgrq-sz：平均请求大小（扇区数）。HDD 上长期大于 64（即大于 32KB）通常说明合并较充分；SSD 上该值偏低也属正常，因为 SSD 原生支持小请求并发a vgqu-sz：平均队列长度。在吞吐相近的情况下，a vgqu-sz越低，通常意味着合并越有效（请求更少，队列压力更小）r_await/w_await：如果合并生效，等待时间通常会下降——但要注意，svctm才是纯设备处理时间，await - svctm才是排队等待部分
为什么改了 /sys/block/sda/queue/nomerges 没变化
写入 nomerges 后 rrqm/s 和 wrqm/s 没有明显响应，常见原因有：
- 后台 writeback 机制在起作用：应用层
write()调用后，数据先进入页缓存，合并发生在 page cache 层或 flush 阶段，iostat统计的是最终下发到块层的 request，而不是 syscall 本身 - IO 类型本身不容易触发合并：随机小 IO（例如数据库 WAL 写）、direct I/O、O_SYNC 文件写，都会绕过页缓存，调度器的合并窗口极小，甚至直接关闭
- 设备类型限制：NVMe 设备默认使用
none调度器，nomerges对其无效；而某些 SCSI 控制器固件也可能忽略内核的合并指令
用 blktrace 验证合并是否真发生
iostat 的数值容易产生误判，要确认合并是否实际发生，必须查看块层原始事件流：
- 执行：
sudo blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'M' - 输出中每行带
M标记（merged）就表示一次前向或后向合并完成 - 注意：
blktrace需要 root 权限，并且会短暂增加 I/O 延迟，生产环境高负载时不要长时间运行 - 如果完全没有
M行，再结合a vgrq-sz持续 ≤8（即 ≤4KB），基本可以判断当前负载下没有有效合并
a vgrq-sz 和扇区利用率的关系
a vgrq-sz 表示扇区数，1 个扇区 = 512 字节（传统扇区），但现代设备多使用逻辑扇区 4K。它本身并不等于“扇区利用率”，但可以反推出底层对齐情况：
- 如果
a vgrq-sz长期为 8、16、32、64 这类 2 的幂次，大概率说明上层 IO 对齐良好，例如文件系统 block size 与物理扇区匹配 - 如果
a vgrq-sz出现大量非整数倍值（如 9、17、33），往往意味着跨扇区读写，会引发读-改-写（R-M-W）放大，实际扇区擦写量远高于逻辑数据量 - 在 SSD 场景下，
a vgrq-sz过低（<16）+%util高 +await波动大，可能是 FTL 层内部碎片化导致的写放大，此时应查看厂商工具（如smartctl -a），而不是只看iostat
判断合并是否生效，不能只看一个数字。rrqm/s 是入口信号，a vgrq-sz 是结果快照，blktrace 是证据链——三者不一致时，优先以 blktrace 的 M 行为准。
