使用 iostat -x 1 查看 avgrq-sz：该值位于每行设备输出的第7列，单位为扇区（1扇区=512字节），反映io合并后的平均请求大小；hdd建议长期≥64（32kb），ssd可略低但应波动小；需结合 avgqu-sz、%util、await 综合判断是否构成iops或吞吐瓶颈。
怎么用 iostat 看 avgrq-sz 这个值
avgrq-sz 就是 IO 合并后的平均扇区数，它直接反映内核是否成功把小请求合并成大请求。值越大，说明合并越充分；HDD 上长期稳定在 64（即 32KB）以上比较健康，SSD 因延迟低，可能略低但波动小。
运行 iostat -x 1 即可实时看到该列。注意必须加 -x（extended），否则默认输出不包含 avgrq-sz。每行设备（如 sda、dm-0）后第 7 列就是它。
- 如果你只关心某块盘，比如
sdb，可以加设备名过滤：iostat -x 1 5 sdb - 不要依赖单次快照——这个值受负载类型影响很大，顺序读写时通常 >128，随机小 IO 场景下掉到 8–16 是正常的
- 注意单位是「扇区」，不是字节；1 扇区 = 512 字节，所以
avgrq-sz为 64 对应 32KB
avgrq-sz 低但 rrqm/s 或 wrqm/s 高意味着什么
这说明内核在努力合并，但应用层发来的请求太碎、地址太散，或者文件系统/块层策略限制了合并效果。
-
rrqm/s和wrqm/s高，代表每秒有大量读/写请求被合并；但avgrq-sz仍低，说明合并后还是小包——常见于日志类随机写、数据库 WAL 写、小文件批量操作 - 某些场景下，即使
rrqm/s接近 0，avgrq-sz也可能偏高（比如大块顺序写），因为请求本身够大，无需合并 - 如果
avgrq-sz持续 r/s 或w/s很高，基本可判定是随机小 IO 压力源，不是合并没做，而是源头就没给机会
为什么 avgrq-sz 在不同设备上差异很大
同一台机器上，sda 和 dm-0（LVM）或 nvme0n1 的 avgrq-sz 常常差几倍，这不是异常，而是路径层级和驱动行为导致的。
- 物理盘（
sda）显示的是最终下发到硬件的请求大小，已含所有合并 - LVM 设备（
dm-0）或加密卷（dm-crypt）会先做一次逻辑合并，再转发给底层，所以它的avgrq-sz通常比物理盘小 - NVMe 设备因队列深度大、无传统“寻道”概念，
avgrq-sz更依赖上层调度器（如mq-deadline）和 I/O 调度策略，有时甚至不如 SATA HDD 稳定 - RAID 卡或硬件 HBA 可能截断合并过程，导致操作系统看到的
avgrq-sz明显偏低，此时需结合卡厂商工具交叉验证
别只盯着 avgrq-sz，搭配看这三个指标才有效
单独看 avgrq-sz 容易误判。它只是合并结果的“快照”，必须结合：
-
avgqu-sz：如果avgrq-sz高但avgqu-sz也高（>2），说明虽合并了，但请求量太大，队列压不住 -
%util：若%util接近 100% 且avgrq-sz中等（如 32–64），大概率是吞吐瓶颈；若%util仅 30% 但avgrq-sz很低（ -
await和svctm差值：如果await - svctm显著 > 1ms，说明队列等待时间长，这时候哪怕avgrq-sz看着不错，实际响应也卡
真正关键的不是“合并了多少”，而是“合并之后，请求是否还被排队、是否及时处理”。avgrq-sz 偏低不可怕，可怕的是它偏低的同时 await 持续飙升、%util 居高不下。
