Linux NVMe 中断排查与性能优化：IRQ 优化(原理+排查)

[一、为什么要关注 NVMe 中断](#一、为什么要关注 NVMe 中断)

二、原理篇

[2.1 中断演进：从 INTx 到 MSI-X](#2.1 中断演进：从 INTx 到 MSI-X)

[2.2 NVMe 多队列模型](#2.2 NVMe 多队列模型)

[2.3 中断处理的完整路径](#2.3 中断处理的完整路径)

[2.4 NUMA 拓扑与中断的关系](#2.4 NUMA 拓扑与中断的关系)

[2.5 Managed IRQ 机制](#2.5 Managed IRQ 机制)

三、排查篇：系统化诊断流程

[3.1 完整排查流程图](#3.1 完整排查流程图)

[3.2 步骤一：确认症状](#3.2 步骤一：确认症状)

[3.3 步骤二：观察中断分布](#3.3 步骤二：观察中断分布)

[3.4 步骤三：检查中断亲和性](#3.4 步骤三：检查中断亲和性)

[3.5 步骤四：NUMA 对齐检查](#3.5 步骤四：NUMA 对齐检查)

[3.6 步骤五：队列与向量数检查](#3.6 步骤五：队列与向量数检查)

下篇：Linux NVMe 中断排查与性能优化：IRQ 优化(优化+验证)-CSDN博客

一、为什么要关注 NVMe 中断

NVMe SSD 的硬件性能可以轻松达到百万级 IOPS、微秒级延迟，但在生产环境中经常出现"硬件很快，体感很慢"的情况。根源往往不在磁盘本身，而在中断处理环节：

某一个 CPU 核的 softirq 占用率长期 100%，其余核几乎空闲
高并发下 P99 延迟抖动严重，偶尔出现毫秒级尾延迟
perf top 中 nvme_irq、__blk_mq_complete_request 长期排前列
NUMA 跨节点访问带来隐性开销

这些问题的共同指向是：中断的分配与处理效率成了瓶颈。

二、原理篇

2.1 中断演进：从 INTx 到 MSI-X

理解 NVMe 中断优化，先要理解 PCI 中断机制的演进。

复制代码

┌─────────────────────────────────────────────────────────────────┐
│                    PCI 中断机制演进                               │
├──────────┬──────────────┬───────────────────────────────────────┤
│   类型    │  中断向量数   │  特点                                 │
├──────────┼──────────────┼───────────────────────────────────────┤
│  INTx    │  1 (共享)     │  电平触发, 多设备共享同一中断线,       │
│          │              │  需逐一轮询确认来源, 效率最低           │
├──────────┼──────────────┼───────────────────────────────────────┤
│  MSI     │  1~32        │  消息触发, 写内存方式通知 CPU,          │
│          │              │  无需共享, 但向量数有限                 │
├──────────┼──────────────┼───────────────────────────────────────┤
│  MSI-X   │  1~2048      │  消息触发, 每个向量可独立路由到         │
│          │              │  不同 CPU, NVMe 标配                   │
└──────────┴──────────────┴───────────────────────────────────────┘

NVMe 规范要求支持 MSI-X。每个 MSI-X 中断向量本质上是设备向特定内存地址写入一条消息，APIC 接收后将中断投递到目标 CPU。这意味着：

无需共享中断线，避免了 INTx 时代的轮询开销
每个队列可以有自己的中断向量，天然支持并行
中断可以定向路由到指定 CPU，这正是亲和性优化的基础

2.2 NVMe 多队列模型

NVMe 的核心设计是 Submission Queue（SQ）和 Completion Queue（CQ）配对工作：

复制代码

                        用户态 / 内核 I/O 栈
                               │
              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
         ┌─────────┐     ┌─────────┐      ┌─────────┐
         │  SQ #1  │     │  SQ #2  │      │  SQ #N  │    提交队列
         │ (CPU 0) │     │ (CPU 1) │      │ (CPU N) │    (环形缓冲区)
         └────┬────┘     └────┬────┘      └────┬────┘
              │               │                │
              ▼               ▼                ▼
         ┌──────────────────────────────────────────┐
         │            NVMe Controller                │
         │     (从 SQ 取命令, 执行, 写结果到 CQ)      │
         └──────────────────────────────────────────┘
              │               │                │
              ▼               ▼                ▼
         ┌─────────┐     ┌─────────┐      ┌─────────┐
         │  CQ #1  │     │  CQ #2  │      │  CQ #N  │    完成队列
         │ IRQ 41  │     │ IRQ 42  │      │ IRQ 4N  │    (各自绑定 MSI-X)
         └─────────┘     └─────────┘      └─────────┘

队列数量的决定公式：

复制代码

I/O 队列数 = min(设备支持的最大队列数, 在线 CPU 数)
MSI-X 向量数 = I/O 队列数 + 1 (Admin Queue)
复制代码

每个 CQ 绑定一个独立的 MSI-X 中断向量。当控制器在 CQ 中写入完成条目后，通过对应的 MSI-X 向量通知 CPU。这个"通知哪个 CPU"就是中断亲和性（IRQ Affinity）控制的内容。

2.3 中断处理的完整路径

一次 NVMe I/O 从提交到完成，中断介入的完整流程：

复制代码

应用程序发起 I/O (read/write/io_uring_enter)
    │
    ▼
① 内核 blk-mq 层：选择当前 CPU 对应的硬件队列 (hctx)
    │
    ▼
② 将命令写入对应的 SQ，敲 Doorbell 寄存器通知控制器
    │
    ▼
③ NVMe 控制器执行命令，将结果写入对应 CQ
    │
    ▼
④ 控制器触发该 CQ 绑定的 MSI-X 中断
    │
    ▼
⑤ CPU 收到硬中断 ──→ nvme_irq()           [硬中断上下文, 极短]
    │                    │
    │                    ├─ 读取 CQ 中的完成条目
    │                    ├─ 标记请求完成
    │                    └─ 触发 softirq 或直接完成
    │
    ▼
⑥ BLOCK_SOFTIRQ ──→ blk_done_softirq()    [软中断上下文]
    │                    │
    │                    └─ nvme_pci_complete_rq()
    │                         │
    │                         └─ bio_endio() → 回调上层文件系统/应用
    │
    ▼
⑦ 应用程序收到 I/O 完成通知

性能敏感点分析：

阶段	关键因素	性能影响
① 选择 hctx	CPU 到队列的映射	映射不当会导致锁竞争
④ MSI-X 投递	中断路由到哪个 CPU	跨 NUMA 投递增加延迟
⑤ 硬中断	处理时间极短 (~ns)	通常不是瓶颈
⑥ 软中断	所有完成工作在此执行	单核集中处理时成为瓶颈
①→⑦ 跨核	提交 CPU ≠ 完成 CPU	IPI + cache miss 开销

2.4 NUMA 拓扑与中断的关系

复制代码

┌─────────────────────────────────────────────────────┐
│                    服务器主板                         │
│                                                     │
│  ┌──────────────┐    QPI/UPI    ┌──────────────┐   │
│  │  NUMA Node 0 │◄────────────►│  NUMA Node 1 │   │
│  │              │              │              │    │
│  │  CPU 0-15    │              │  CPU 16-31   │    │
│  │  本地内存     │              │  本地内存     │    │
│  │              │              │              │    │
│  │  PCIe Root   │              │  PCIe Root   │    │
│  │  Complex #0  │              │  Complex #1  │    │
│  └──────┬───────┘              └──────────────┘    │
│         │                                          │
│    ┌────┴─────┐                                    │
│    │ NVMe SSD │  ← 物理连接在 Node 0 的 PCIe 槽位   │
│    └──────────┘                                    │
└─────────────────────────────────────────────────────┘

当 NVMe 设备连接在 Node 0 的 PCIe 总线上时：

理想情况：I/O 提交和中断完成都在 Node 0 的 CPU 上，DMA 缓冲区也在 Node 0 的内存中
糟糕情况：中断被路由到 Node 1 的 CPU，完成处理需要跨 QPI/UPI 总线访问 Node 0 的内存，延迟增加 50~100ns

2.5 Managed IRQ 机制

从 Linux 4.x 后期开始，NVMe 驱动采用 managed interrupt 机制。这是理解现代内核中断行为的关键。

复制代码

传统模式:
  驱动申请中断 → 用户可通过 smp_affinity 自由绑定
Managed 模式 (NVMe 默认):
驱动申请中断时声明 CPU 亲和性 → 内核自动管理
→ smp_affinity 变为只读（写入被忽略或报错）
→ 内核根据 NUMA 拓扑和 CPU 上下线事件自动调整

managed irq 的设计目标是让内核做出比用户手动配置更合理的决策，特别是在 CPU 热插拔场景下。在大多数情况下它工作良好，但也意味着手动调优的空间受限。

三、排查篇：系统化诊断流程

3.1 完整排查流程图

复制代码

开始排查
  │
  ▼
┌──────────────────────────┐
│ 1. 确认症状              │
│    mpstat -P ALL 1       │──→ 某核 %soft 异常高？
│    iostat -x 1           │──→ await / svctm 异常？
└───────────┬──────────────┘
            │ 是
            ▼
┌──────────────────────────┐
│ 2. 观察中断分布           │
│    /proc/interrupts      │──→ 中断集中在少数 CPU？
│    sar -I ALL 1          │──→ 中断速率哪些核高？
└───────────┬──────────────┘
            │ 分布不均
            ▼
┌──────────────────────────┐
│ 3. 检查亲和性配置         │
│    smp_affinity_list     │──→ 期望值是什么？
│    effective_affinity    │──→ 实际生效值是什么？
│    是否 managed irq?     │──→ 决定优化手段
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────┐
│ 4. 确认 NUMA 对齐         │
│    设备 numa_node        │──→ 设备在哪个节点？
│    中断 CPU 在哪个节点？   │──→ 是否跨节点？
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────┐
│ 5. 检查队列数与向量数     │
│    queue_count           │──→ 队列数 vs CPU 数
│    msi_irqs/             │──→ 向量数是否充足
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────┐
│ 6. 实施针对性优化         │
│    (见优化篇)             │
└───────────┬──────────────┘
            │
            ▼
┌──────────────────────────┐
│ 7. 验证优化效果           │
│    fio 对比测试           │
│    重新检查中断分布        │
└──────────────────────────┘

3.2 步骤一：确认症状

复制代码

# 观察各 CPU 的负载分布，重点看 %soft 列
mpstat -P ALL 1 5

# 典型的不均衡输出：
CPU    %usr   %sys   %soft   %idle
  0    2.00   5.00   88.00    5.00   ← softirq 打满
  1    1.00   1.00    0.50   97.50
  2    1.00   1.00    0.50   97.50
  3    1.00   1.00    0.50   97.50

# 磁盘延迟观察
iostat -x -p nvme0n1 1 5
# 关注 await（平均 I/O 延迟）和 %util

3.3 步骤二：观察中断分布

复制代码

# 查看 NVMe 相关的中断计数
cat /proc/interrupts | grep nvme

# 示例输出（问题状态）：
           CPU0       CPU1       CPU2       CPU3
 41:   29384756          0          0          0  IR-PCI-MSI  nvme0q0
 42:   18273645          0          0          0  IR-PCI-MSI  nvme0q1
 43:         12          0          0          0  IR-PCI-MSI  nvme0q2
 44:          8          0          0          0  IR-PCI-MSI  nvme0q3

所有中断集中在 CPU0，队列 2 和 3 几乎没有中断------说明 I/O 也集中在队列 1。

复制代码

# 动态观察中断增长速率（对比两次快照）
watch -d -n 1 'cat /proc/interrupts | grep nvme'
或用 sar 统计每秒中断数
sar -I 41,42,43,44 1 10

3.4 步骤三：检查中断亲和性

复制代码

# 遍历所有 NVMe 中断的亲和性
for IRQ in $(awk '/nvme/ {print $1}' /proc/interrupts | tr -d ':'); do
    echo -n "IRQ $IRQ: "
    echo -n "smp_affinity_list=$(cat /proc/irq/$IRQ/smp_affinity_list) | "
    echo -n "effective=$(cat /proc/irq/$IRQ/effective_affinity_list) | "
    # 检查是否为 managed irq
    ACTIONS=$(cat /proc/irq/$IRQ/actions 2>/dev/null)
    echo "actions=$ACTIONS"
done

# 输出示例：
IRQ 41: smp_affinity_list=0-3 | effective=0 | actions=nvme0q0
IRQ 42: smp_affinity_list=0-3 | effective=0 | actions=nvme0q1
IRQ 43: smp_affinity_list=0-3 | effective=1 | actions=nvme0q2
IRQ 44: smp_affinity_list=0-3 | effective=2 | actions=nvme0q3

如果 smp_affinity_list 写入后 effective_affinity 不跟随变化，大概率是 managed irq 在起作用。

复制代码

# 确认 managed irq 状态（需要内核调试信息）
# 方法 1：尝试写入 smp_affinity，观察是否报错
echo 2 > /proc/irq/42/smp_affinity_list
# 如果报 "write error: Input/output error" → managed irq
方法 2：查看内核日志
dmesg | grep -i "managed|affinity" | grep nvme

3.5 步骤四：NUMA 对齐检查

复制代码

# NVMe 设备所在 NUMA 节点
cat /sys/class/nvme/nvme0/device/numa_node
# 输出: 0
CPU 和 NUMA 的对应关系
lscpu | grep -i numa
NUMA node0 CPU(s): 0-15,32-47
NUMA node1 CPU(s): 16-31,48-63
交叉对比：中断实际投递到的 CPU 是否在同一节点
如果 NVMe 在 Node 0，但中断在 CPU 16-31 上 → 跨 NUMA

# 更详细的 NUMA 拓扑
numactl --hardware
查看 PCIe 设备拓扑
lspci -tv | grep -A2 -B2 "NVMe|Non-Volatile"

3.6 步骤五：队列与向量数检查

复制代码

# NVMe 设备的队列数
cat /sys/block/nvme0n1/device/queue_count
# 输出: 33 (32 I/O queues + 1 Admin queue)
MSI-X 向量数
ls /sys/class/nvme/nvme0/device/msi_irqs/ | wc -l
驱动初始化日志
dmesg | grep nvme | grep -E "queue|irq|vector|io queues"
典型输出:
nvme nvme0: 32/0/0 default/read/poll queues

如果队列数少于 CPU 数，说明设备支持的最大队列数是限制因素，部分 CPU 会共享队列。

六、总结与常见问题

本文围绕 NVMe 中断的演进、多队列模型、NUMA 对齐、managed IRQ 机制以及系统化排查流程进行了完整梳理。下面用要点总结核心结论，并针对常见问题给出解答。

6.1 核心结论

中断演进：从 INTx 到 MSI-X，NVMe 借助 MSI-X 实现每个队列独立中断向量，并支持将中断定向路由到指定 CPU，这是亲和性优化的基础。
多队列模型：NVMe 通过 SQ/CQ 配对实现多队列并行，I/O 队列数由设备支持的最大队列数和在线 CPU 数共同决定，每个 CQ 绑定独立的 MSI-X 向量。
NUMA 对齐：中断投递和完成处理应尽量落在设备所在 NUMA 节点，跨节点访问会带来 50~100ns 的额外延迟，是性能优化的关键点。
managed IRQ 限制：现代内核默认采用 managed interrupt，smp_affinity 变为只读，手动调优空间受限，需借助间接手段干预。
排查流程：从确认症状、观察中断分布、检查亲和性、NUMA 对齐到队列与向量数检查，形成系统化诊断路径，避免盲目调优。
性能敏感点：软中断集中处理、提交 CPU 与完成 CPU 不一致导致的 IPI 和 cache miss，是延迟抖动的主要来源。
先测量再行动：任何优化都应基于 mpstat、/proc/interrupts、numactl 等实测数据，避免凭经验过度干预。

6.2 常见问题

Q1：为什么 smp_affinity 写入不生效？

如果写入 /proc/irq/<IRQ>/smp_affinity_list 后 effective_affinity 不跟随变化，或直接报 "write error: Input/output error"，说明该中断是 managed irq。NVMe 驱动在申请中断时声明了 CPU 亲和性，内核接管了分配逻辑，用户手动写入会被忽略或拒绝。此时应通过调整驱动参数、irqbalance 配置或 CPU 热插拔策略间接影响分配。

Q2：队列数少于 CPU 数怎么办？

队列数由 min(设备支持的最大队列数, 在线 CPU 数) 决定。如果设备最大队列数小于 CPU 数，部分 CPU 会共享队列，这是硬件限制。此时应优先保证共享队列的 CPU 与设备所在 NUMA 节点对齐，并关注队列上的中断是否均匀分布，必要时通过 blk-mq 的映射策略优化。

Q3：如何判断是否跨 NUMA 访问？

先查看设备所在节点：cat /sys/class/nvme/nvme0/device/numa_node，再通过 lscpu 或 numactl --hardware 确认各节点的 CPU 范围。最后对比 /proc/irq/<IRQ>/effective_affinity_list 中实际生效的 CPU 是否落在设备所在节点。如果设备在 Node 0 而中断投递到 Node 1 的 CPU，即为跨 NUMA 访问。

Q4：managed IRQ 下如何手动干预？

managed irq 下 smp_affinity 只读，但可以通过以下间接手段干预：调整 irqbalance 的配置策略、使用 taskset 将发起 I/O 的进程绑定到目标 CPU、通过 CPU 热插拔触发内核重新分配，或在内核启动参数中调整相关配置。对于极端场景，可考虑关闭 managed irq 或改用轮询模式。

Q5：中断集中在 CPU0 一定是问题吗？

不一定。如果系统负载本身很低，中断集中在某个 CPU 并不会成为瓶颈。只有当该 CPU 的 softirq 占用率长期接近 100%、P99 延迟抖动明显，或 I/O 吞吐受限时，才需要关注中断分布。判断标准是实际性能指标，而非中断计数本身。

6.3 进一步学习资源

内核文档：Documentation/IRQ-affinity.txt，介绍中断亲和性的配置与原理。
内核文档：Documentation/PCI/msi-howto.txt，讲解 MSI/MSI-X 的使用与限制。
内核文档：Documentation/block/blk-mq.txt，说明 blk-mq 多队列机制与映射策略。
man page：man 8 irqbalance，了解 irqbalance 的配置与运行机制。
man page：man 8 numactl，查看 NUMA 拓扑与内存策略工具用法。
man page：man 1 mpstat、man 1 iostat，掌握 CPU 与磁盘性能观测工具。
本人博客：Linux NVMe 中断排查与性能优化：IRQ 优化（优化+验证），本文的续篇，讲解中断亲和性优化与验证方法。
本人博客：Linux NVMe 中断排查与性能优化：原理与排查，本文的姊妹篇，系统梳理 NVMe 中断原理与排查流程。