真正起效的是让整个I/O路径持续稳定地将足够请求送入NVMe控制器队列，而非仅调大队列深度；需同步调大nr_requests、切换mq-deadline调度器、匹配应用层AIO/ io_uring深度，并通过aqu-sz、await、r/s/w/s三指标验证效果。
直接调大块设备的队列深度（queue_depth）并不能“压榨”NVMe性能——它只是释放硬件本就具备的能力。真正起效的是让整个I/O路径（从应用到驱动）能持续、稳定地把足够多的请求塞进NVMe控制器的海量队列中，而不是被中间环节卡住。
理解 queue_depth 的真实作用
Linux中/sys/block/nvme0n1/device/queue_depth反映的是主机端向NVMe设备提交命令时，单个队列允许挂起的最大未完成命令数（即“队列深度”）。它不是性能目标，而是上限阈值：
- 该值默认常为128或256，远低于NVMe协议支持的65536上限，属于保守设置
- 设得太小（如32），会人为限制并发，即使应用发了100个异步I/O，内核也只允许32个排队，其余阻塞在上层
- 设得过大（如65536）但底层无支撑（如调度器、nr_requests、AIO线程数没跟上），反而可能加剧锁竞争或内存压力
三步联动调大 queue_depth 才有效
单独改queue_depth几乎无效。必须同步打通三层瓶颈：
-
设备层：增大内核块层请求队列容量
echo 1024 > /sys/block/nvme0n1/queue/nr_requests
（默认64，不调大会导致请求在块层就排队，根本到不了NVMe队列） -
调度层：切换为高并发友好型调度器
echo mq-deadline > /sys/block/nvme0n1/queue/scheduler
（避免cfq等传统调度器引入额外延迟；noop在直通场景下也可用） -
应用层：确保AIO或io_uring提交深度匹配
例如fio压测需设--iodepth=256，Nginx启用aio threads时线程池大小应≥ queue_depth × 0.8，且max_queue≥ 2×线程数
验证是否真正“压榨”到位
不能只看queue_depth数字变大，关键看实际负载下的三个指标是否协同改善：
-
aqu-sz（iostat -x 中的平均队列长度）：应稳定在
queue_depth的60%~90%，长期接近100%说明仍受限；长期＜30%说明配置过剩 - await（平均I/O等待时间）：调优后应明显下降，尤其在高iodepth下仍保持百微秒级（NVMe典型值）
- r/s 或 w/s：吞吐量是否随iodepth提升而线性增长，直至逼近PCIe带宽极限（如PCIe 4.0 x4约3.9 GB/s）
企业级NVMe的特别注意事项
消费级盘（如980 Pro）和企业级盘（如PM9A3、P5510）对高队列深度的响应差异极大：
- 企业盘在QD64下延迟增幅小（0.3ms→0.5ms），可放心设
queue_depth=512甚至1024 - 消费盘在QD64下延迟跳升明显（0.9ms→2.1ms），建议上限控制在256以内，并配合更激进的
nr_requests和io_uring轮询模式 - 若使用多盘阵列，还需确认PCIe拓扑（如是否共享上游Switch），避免单通道成为瓶颈
