avgrq-sz 反映真实合并效果需结合 rrqm/s 和设备类型：HDD 上长期低于 64（32KB）说明合并不足，SSD/NVMe 因随机访问特性，该值偏低属正常，应重点看 rrqm/s 是否为正且稳定。
怎么看 avgrq-sz 是否反映真实合并效果
avgrq-sz 是 iostat -x 输出里最直接体现合并结果的字段，单位是扇区（512 字节），值越大通常说明合并越充分。但它不是绝对指标：HDD 上长期低于 64（即 avgrq-sz 达到 128，也可能只是队列深度高、单请求大，并非传统意义的“前后向合并”。
验证是否真由合并驱动，得看变化趋势：rrqm/s 上升的同时 avgrq-sz 明显增大、r/s 下降，才是典型信号。如果 avgrq-sz 高但 rrqm/s 始终为 0，大概率是应用层发了大块 IO（如 O_DIRECT + 1MB buffer），和块层合并无关。
为什么 wrqm/s 为 0 但 avgrq-sz 却很高
写合并失效不等于没发生合并——wrqm/s 只统计进入队列前被合并的次数，而很多写操作根本没进队列：
- 页缓存 writeback 模式下，大量脏页由内核后台线程批量 flush，这些请求绕过调度器直接下发，
wrqm/s不计数，但avgrq-sz仍会体现 batch 效果 - 使用
posix_fadvise(POSIX_FADV_DONTNEED)或O_DIRECT的程序，跳过页缓存，IO 更“直给”，合并窗口极小 - LVM 或加密设备（如 dm-crypt）在块层之上多了一层映射，
/sys/block/sda/queue/nomerges改了也没用，得查/sys/block/dm-0/queue/nomerges
如何用 blktrace 确认合并是否真实发生
blktrace 是唯一能看见“M”（merged）事件的工具，比 iostat 更底层可靠：
- 必须用 root 权限运行：
sudo blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'M' - 输出中每行带
M标记（如sda 12345 M R 123456789）就代表一次成功合并 - 注意：该命令会短暂增加 I/O 延迟，别在生产高峰跑；若设备是 NVMe，需指定具体 queue（如
-q nvme0n1q0），否则默认 trace 主 queue
合并对读写效率的实际影响怎么评估
合并不是单纯“让数字变好看”，它对效率的影响取决于硬件特性：
- HDD：寻道代价高，合并连续扇区能显著减少磁头移动 —— 此时
avgrq-sz从 8 升到 64，r_await可能下降 30% 以上 - SSD/NVMe：无机械寻道，但过小请求（avgrq-sz ≥ 64 更利于控制器内部优化
- 警惕反效果：强行开启合并但应用本身发的是随机小 IO（如数据库 WAL），反而增加调度延迟，
avgqu-sz可能不降反升
真正要盯住的组合是：rrqm/s 或 wrqm/s + avgrq-sz + avgqu-sz 三者同步变化，缺一不可。单独看任一字段都容易误判。
