公司动态 · 发布时间：
独占节点并不意味着所有 CPU 都适合处理网卡中断。若多个接收队列的中断集中在少数核心，其他核心闲置，网络负载较高时可能出现软中断积压；若中断散布过广，又可能增加跨 NUMA 节点访问和调度开销。独占硬件节点的中断亲和性调优与网络吞吐提升，应从队列、CPU 拓扑和业务流量共同着手，而不是只改一个中断掩码。
先确认网卡队列与 CPU 拓扑
RSS（接收端扩展）可将不同网络流分配到多个接收队列，队列通常对应各自的中断向量。队列数过少会限制并行处理能力；队列多于实际可用的处理核心，也未必带来收益。先记录网卡、队列和中断的当前状态，再决定是否调整。
- 用 lscpu -e 查看 CPU 编号、核心及 NUMA 节点；读取 /sys/class/net/接口名/device/numa_node，确认网卡所在节点。返回负值时，设备可能没有明确的 NUMA 归属。
- 运行 ethtool -l 接口名查看通道数量和上限，运行 ethtool -x 接口名查看 RSS 队列分配；并检查 /proc/interrupts 中该网卡的中断计数。
- 对照驱动和设备信息确认队列对应关系。不同网卡及驱动的中断名称、可调参数并不完全相同，不要仅凭中断编号推断它对应的队列。
以 Intel E810 或 NVIDIA ConnectX 系列网卡为例，实际可用队列和配置能力取决于具体型号、驱动、固件及系统设置；应以本机查询结果为准。调整队列数可能改变中断向量分配，因此应先记录原值。
把中断放到合适的核心
优先让网卡中断落在其本地 NUMA 节点的 CPU 上，并避开繁忙的应用核心。可以先观察哪些 CPU 的网卡中断计数持续增长，再按队列分配核心，尽量避免多个高流量队列都挤在同一核心。独占节点也要留意 irqbalance：若它在运行，可能重新分配中断，与手动设置产生冲突。
- 从 /proc/interrupts 找到网卡对应的 IRQ 编号，并再次核对接口、队列与 IRQ 的关联。
- 选择与网卡 NUMA 节点相同的 CPU 编号。确认该核心没有承担关键应用线程或其他高负载设备的中断。
- 将选定 CPU 写入对应 IRQ 的 /proc/irq/IRQ号/smp_affinity_list。例如将某 IRQ 绑定到 CPU 4，可执行 echo 4 > /proc/irq/IRQ号/smp_affinity_list；编号须依据本机拓扑替换。
- 再次查看 /proc/interrupts，并在测试期间观察计数是否按预期增长。若 irqbalance 正在管理该设备，应先明确采用自动还是手动策略，避免设置被覆盖。
调整亲和性时，还要检查网卡队列配置与 RSS 映射是否匹配。RPS 可在软件层分散接收处理，XPS 可影响发送队列选择；两者适用于特定负载，不应在未确认硬件队列瓶颈前一并启用。尤其要关注跨节点处理：中断在本地而应用线程长期运行于远端节点，仍可能增加内存访问成本。
用可重复测试判断是否有效
每次只改变一项设置，使用相同的报文大小、连接数、测试时长及对端条件比较前后结果。可用 iperf3 在两台机器间测量 TCP 吞吐，增加并行流数量以观察多队列是否发挥作用；同时检查丢包、重传、CPU 利用率、软中断负载和 ethtool -S 接口名提供的网卡统计。单流表现与多流表现可能不同，不能只用一次峰值判断。
若吞吐提升但丢包增加，或少数核心持续满载，应重新检查队列分布与 CPU 亲和性；若吞吐没有变化而 CPU 负载已较低，瓶颈可能在对端、链路、存储或应用处理，而非中断。独占硬件节点的中断亲和性调优与网络吞吐提升，最终应以同一环境下可复现的指标改善为依据，并保留回滚方案。
常见问题
队列数量是否应等于 CPU 核心数？
不一定。还要考虑流量并行度、网卡能力、应用占用和 NUMA 布局；先比较现有队列数与实际中断负载。
手动绑定后中断又移动了，怎么办？
检查 irqbalance 是否运行，以及网卡重置或队列重配置是否重建了中断向量；随后重新核对 IRQ 对应关系和亲和性。
只看吞吐量够不够？
不够。还应比较丢包、重传、延迟、CPU 与软中断负载，避免以牺牲稳定性换取短时峰值。
调优后效果不明显是否要继续增加队列？
先确认瓶颈是否在网卡中断处理。若限制来自链路、对端或应用，增加队列通常不能解决问题。
