linux中修改块设备队列深度本质是调整nr_requests参数，它控制i/o调度器能暂存的最大请求数，需按设备名（如sdb）通过cat /sys/block/sdb/queue/nr_requests查询，临时修改用echo 512 > /sys/block/sdb/queue/nr_requests，该值建议至少为硬件queue_depth的两倍，适用于极限压测、hdd大块顺序i/o等场景，但盲目调大会增加内存开销并可能抬升延迟。
Linux 中修改块设备队列深度，本质是调整 nr_requests 参数，它控制 I/O 调度器能暂存的最大请求数。这个值不是全局内核参数，而是每个块设备（如 sdb、nvme0n1）独立配置的。
怎么查当前队列深度
必须指定具体设备名，不能笼统查系统级值：
-
cat /sys/block/sdb/queue/nr_requests—— 查看当前值（单位：请求数） -
sudo blockdev --getss /dev/sdb可辅助确认扇区大小，用于后续对齐判断
临时修改方法（重启失效）
直接写入对应设备的 sysfs 接口即可，需 root 权限：
echo 512 > /sys/block/sdb/queue/nr_requests- 注意：该操作仅影响调度器层，不改变底层硬件队列深度（
/sys/block/sdb/device/queue_depth），但建议nr_requests至少为硬件队列深度的两倍
哪些情况适合调大
默认值通常是 128，一般无需改动。只有在明确场景下才考虑增大：
- 进行极限性能压测，需要提高并发写压力
- 使用机械硬盘（HDD）且业务以大块顺序 I/O 为主
- 配合
deadline或bfq调度器时，适当增大可提升合并效率 - NVMe 设备通常设为
none调度器，此时nr_requests影响变小，重点应放在硬件队列和驱动配置上
注意事项
盲目调大会带来副作用，需权衡：
- 内存开销增加：每个请求结构体占用一定内存，值过大可能浪费内核内存
- 延迟上升：过深队列可能掩盖响应慢的问题，不利于故障定位
- 文件系统与调度器需匹配：例如
cfq在高并发下可能因公平性导致吞吐下降，此时换用bfq或none更有效 - 永久生效需靠启动脚本或 udev 规则，因为 sysfs 修改在重启后丢失
