rrqm/s 和 wrqm/s 是 iostat -x 中唯一直接反映 io 合并行为的字段，表示每秒被调度器合并掉的读/写请求数，并非合并后减少的请求数；值为 0 不代表无合并，可能因队列浅、地址分散或派发过快导致未排队即处理；验证合并是否真实发生应结合 blktrace：blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'm'，出现 m 标记即证实合并。
怎么看 rrqm/s 和 wrqm/s 是否真实有效
rrqm/s 和 wrqm/s 是 iostat -x 输出里唯一直接反映 IO 合并行为的字段，但它们容易被误读：这个值不是“合并后减少的请求数”，而是“进入队列前被调度器合并掉的次数”。即使值为 0，也不代表没发生合并——可能因为队列深度低、IO 地址太分散，或请求刚进队就立刻派发，根本没机会排队合并。
更可靠的方式是结合 blktrace 看实际事件流：blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'M'。只要输出里有带 M（merged）标记的行，就说明后向或前向合并确实发生了。注意：该命令需 root 权限，且会短暂影响 I/O 性能。
iostat -x 输出中哪些字段和合并强相关
合并效果最终会体现在请求形态上，iostat -x 中以下字段可间接验证合并是否起作用：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
avgrq-sz：平均请求大小（扇区数）。合并越多，该值通常越大。HDD 上若长期 64（即 >32KB）较常见。 -
avgqu-sz：平均队列长度。合并充分时，相同数据量对应的请求数变少，队列压力降低。但若该值过低（如持续 r/s 很高，反而提示 IO 过于离散、无法合并。 -
r_await/w_await：合并减少请求次数，从而缩短队列等待时间。若await显著低于历史均值，且rrqm/s同步上升，大概率是合并生效了。
为什么改了 /sys/block/sda/queue/nomerges 还没变化
修改 /sys/block/sda/queue/nomerges 后没看到 rrqm/s 变化，常见原因有：
- 写入的是缓存文件系统（如 ext4 默认开启
writeback），大量 write 被延迟提交，iostat统计的是最终下发到块层的 request，不是 syscalls； - 应用本身用
O_DIRECT或posix_fadvise(POSIX_FADV_DONTNEED)，绕过了页缓存，也削弱了合并机会； - 设备是 NVMe，其多队列设计让每个 CPU 队列独立，
nomerges只作用于单个 queue，全局rrqm/s看起来仍不为 0； - 你改的是
sda，但实际 IO 走的是 LVM 逻辑卷（如dm-0），应检查并修改对应/sys/block/dm-0/queue/nomerges。
合并对 HDD 和 SSD 的意义完全不同
合并不是万能优化，硬件特性决定它是否值得调：
- HDD：寻道代价高，合并连续扇区能显著减少物理移动。建议保持
nomerges=0，并确保max_sectors_kb≥512（避免强制拆分大 IO）； - SATA SSD：无寻道，但控制器处理小请求开销仍存在。合并仍有价值，但阈值可更高（
max_sectors_kb=1024）； - NVMe：深度队列 + 多队列 + 无锁提交，合并收益极低，甚至因增加判断逻辑拖慢路径。生产环境一般不干预合并策略，
%util和r_await才是关键指标。
别只盯着 rrqm/s 数字涨没涨——对 NVMe 来说，它接近 0 反而是健康信号。
