4、NVMe队列深度与并发：队列深度对性能的影响、多队列并发策略、中断合并与轮询模式、自适应队列深度调整
队列深度，这个词听起来有点抽象。说白了，就是你的NVMe设备一次能“记住”多少个未完成的命令。我刚开始调NVMe驱动时，总觉得这参数随便设个值就行。直到有一次，一个存储项目死活跑不满带宽，我才意识到——队列深度，其实是整个性能调优的命门。
4.1 队列深度对性能的影响
先讲个简单的道理。队列深度太小，CPU得频繁地提交命令、等待完成，大部分时间都花在“来回跑”上了。队列深度太大呢？命令在设备内部排队，延迟反而会升高。你想想看，就像去银行办业务——窗口太少，排队的人太多，每个人都要等很久。
我习惯把队列深度和IOPS的关系画成一条曲线。刚开始，深度从1增加到8，IOPS几乎是线性增长。到了16、32，增长就变缓了。再往上，比如128、256，IOPS可能反而会掉。为什么会这样？因为设备内部的资源有限，命令多了，调度开销也大了。
关键结论：队列深度不是越大越好。每个系统都有一个“甜蜜点”。
我在项目中遇到过一块消费级SSD，队列深度超过64后，延迟直接翻倍。后来查了手册才知道，这块盘的内部命令槽位只有64个。嗯，这里要注意——不是所有NVMe设备都支持大队列深度。
| 队列深度 | IOPS（随机读4K） | 平均延迟（μs） | CPU占用率 |
|---|---|---|---|
| 1 | 8,000 | 125 | 5% |
| 8 | 55,000 | 145 | 12% |
| 32 | 120,000 | 267 | 28% |
| 64 | 135,000 | 474 | 35% |
| 128 | 128,000 | 1000 | 42% |
你看这个表，深度从1到32，IOPS涨了15倍。但从64到128，IOPS反而降了。这就是典型的“过犹不及”。
4.2 多队列并发策略
NVMe的一个核心优势，就是支持多队列。每个队列可以独立提交命令、独立处理完成。这跟AHCI那种单队列的设计比起来，简直是降维打击。
我个人的习惯是：有多少个CPU核心，就创建多少个队列。但这里有个坑——不是所有设备都支持那么多队列。有些低端NVMe控制器，最多只支持4个或8个队列。
实用技巧：用nvme list命令查看设备支持的队列数。如果设备支持32个队列，但你只有4个核，那就创建4个队列就够了。多了反而浪费。
多队列并发，说白了就是让每个CPU核心都有自己的“专属通道”。这样就不会出现多个核抢一个队列的情况。我在一个8核ARM平台上做过测试：单队列时，IOPS只有8万；开启8个队列后，IOPS直接飙到45万。你想想看，这差距有多大。
但要注意，队列之间的负载均衡也很重要。我曾经遇到过一个问题：8个队列中，有2个队列几乎没流量，另外6个队列忙得要死。后来发现是中断亲和性没配好，导致某些核上的中断处理不过来。
// 设置队列与CPU的亲和性
// 伪代码示例
for (int i = 0; i < num_queues; i++) {
int cpu = i % num_cpus;
irq_set_affinity(queue[i].irq, cpu_mask[cpu]);
}这段代码看起来简单，但实际项目中，我踩过不少坑。比如有些SoC的IRQ控制器不支持任意CPU绑定，你得查手册确认。
4.3 中断合并与轮询模式
中断合并，就是让设备攒一批完成事件再通知CPU。这样做的好处是减少中断次数，降低CPU开销。坏处呢？延迟会变大。
我习惯把中断合并比作“公交车”——等的人多了再发车，效率高，但每个人都要多等一会儿。轮询模式呢？就像打出租车，随叫随到，延迟低，但CPU得一直盯着。
在实际项目中，我一般这样选：
- 延迟敏感型应用（比如数据库日志写入）：用轮询模式，或者把中断合并时间设到最小。
- 吞吐量敏感型应用（比如大数据批处理）：用中断合并，合并时间设到50-100微秒。
警告：轮询模式会吃掉一个CPU核心。如果你的系统CPU资源紧张，慎用。我曾经在一个4核系统上开了轮询，结果应用线程被饿死了。
NVMe协议里有个特性叫Interrupt Coalescing，通过设置合并时间和合并阈值来控制。我记得有一次调优，把合并时间从0改成10微秒，CPU占用率从40%降到了15%，IOPS只掉了3%。嗯，这个trade-off很划算。
// 设置中断合并参数
// 伪代码示例
struct nvme_coalescing_cfg {
uint16_t time; // 合并时间，单位100微秒
uint8_t threshold; // 合并阈值，多少个完成事件触发一次中断
};
// 设置合并时间为50微秒，阈值为4
nvme_set_coalescing(dev, 0, 4);这里要注意，不同厂商的设备对合并参数的支持不一样。有些设备只支持时间合并，不支持阈值合并。调之前，先看看datasheet。
4.4 自适应队列深度调整
固定队列深度，说白了就是“一刀切”。但实际负载是动态变化的——有时候是大量小IO，有时候是少量大IO。我一直在想，能不能让队列深度自己动起来？
自适应队列深度调整，就是根据当前的负载情况，动态调整队列深度。比如，当延迟变高时，减小队列深度；当IOPS上不去时，增大队列深度。
我在一个分布式存储项目中实现过这个机制。核心思路是：
- 每隔100毫秒采样一次IOPS和延迟。
- 如果延迟超过阈值（比如500微秒），就把队列深度减半。
- 如果IOPS增长缓慢且延迟很低，就把队列深度增加25%。
- 设置上下限，防止队列深度跑飞。
核心算法： AIMD（加法增、乘法减）。这是TCP拥塞控制的思路，搬到NVMe队列深度调整上，效果出奇的好。
// 自适应队列深度调整伪代码
int current_depth = 32;
int min_depth = 4;
int max_depth = 128;
while (running) {
sleep(100ms);
float latency = get_avg_latency();
float iops = get_iops();
if (latency > LATENCY_THRESHOLD) {
// 延迟高了，乘法减
current_depth = max(min_depth, current_depth / 2);
} else if (iops_growth_rate < 0.1) {
// IOPS增长缓慢，加法增
current_depth = min(max_depth, current_depth + 8);
}
apply_queue_depth(current_depth);
}我曾经踩过一个坑：自适应调整时，采样周期太短，导致队列深度频繁抖动。后来把采样周期改成200毫秒，加上一个滞回区（hysteresis），才稳定下来。
避坑指南：自适应调整一定要加滞回区。比如延迟从400微秒升到500微秒才触发减半，从500微秒降到300微秒才触发增加。这样可以避免频繁震荡。
最后说一句，自适应队列深度不是银弹。如果你的负载非常稳定，固定队列深度反而更高效。我一般只在负载波动大的场景下才启用自适应模式。
嗯，这一章的内容就到这里。队列深度这东西，调好了是神器，调不好是累赘。多试试，多测测，找到最适合你系统的那个值。