需确认多队列中断是否真实分散至多个CPU:先用nmcli查物理网卡名,再grep其-rx-/-tx-中断行,watch实时观察各CPU列增长是否均衡;若仅单核增长则未生效。

怎么看网卡中断是否真分散到多个 CPU
仅仅执行 cat /proc/interrupts 是不够的哦——必须要确认带有 -rx-、-tx- 后缀的多队列中断行,它们每行是否真的在不同的CPU列上有所增长。倘若所有的 enp5s0f0-rx-0、enp5s0f0-rx-1、enp5s0f0-rx-2 都仅仅只在 CPU0 上增长,那么这个所谓的“多队列”就只是个摆设罢了。
- 先用
nmcli device status确认物理网卡名(如ens3f0),别查bond0或veth这类虚拟口 - 再跑
grep -i "ens3f0" /proc/interrupts,找含-rx-或-tx-的行;没有后缀的单行(如只有ens3f0)说明根本没开多队列 - 用
watch -n 1 'grep -i ens3f0 /proc/interrupts'实时看:某列(比如CPU0)数值秒增几百上千,其他列几乎不动 → 单核瓶颈坐实 - 注意末尾带
msi、IR-PCI-MSI的行才是现代多队列中断;IO-APIC前缀大概率是老式单中断线
怎么验证中断亲和性已生效
写了 smp_affinity_list 不代表就绑定了,内核或 irqbalance 可能几秒后就覆盖掉。必须比对 effective_affinity 和你写的值是否一致。
- 查某 IRQ 绑定情况:
grep -i "ens3f0-rx-0" /proc/interrupts | awk '{print $1}' | xargs -I{} sh -c 'echo {}:/proc/irq/{}/smp_affinity_list; echo {}:/proc/irq/{}/effective_affinity' | while read l; do echo "$l: $(cat ${l##*:} 2>/dev/null)"; done smp_affinity_list输出是十进制 CPU 编号(如0,2,4),人眼可读;别碰smp_affinity(十六进制掩码),x86 和 ARM 位宽不同,写错会直接丢中断- 如果
effective_affinity和smp_affinity_list不一致,八成是irqbalance在后台运行 —— 执行sudo systemctl stop irqbalance && sudo systemctl disable irqbalance彻底关掉 - 某些中断(如 BMC、老 RAID 卡)固件锁定,
ls -l /proc/irq/*/smp_affinity*没文件就别硬写,会报Operation not permitted
为什么 ethtool -S 比 /proc/interrupts 更早暴露问题
/proc/interrupts 只告诉你“中断来了多少次”,但不告诉你这些中断干了什么;ethtool -S 能看出网卡是否在“包包中断”,这是 NAPI 失效的典型信号。
- 执行
ethtool -S ens3f0 | grep -E "(rx_packets|rx_interrupts)" - 如果
rx_interrupts是rx_packets的 3 倍以上(比如 300K vs 100K),说明每收一个包都触发一次中断,NAPI 没起来 → 检查ethtool -k ens3f0中gro、lro是否开启,以及驱动是否支持 RSS rx_unicast高但rx_packets低?可能是硬件 offload 导致统计口径不一致,别光盯一个数tx_errors、rx_missed_errors持续涨,优先查物理链路或交换机配置,不是中断平衡问题
NUMA 架构下中断绑定容易被忽略的关键点
把网卡中断绑到离它物理最近的 CPU 节点,比“均匀分配到所有 CPU”更重要。跨 NUMA 访问内存延迟翻倍,软中断处理效率直接打骨折。
- 先用
lscpu看 CPU 分属哪些 NUMA node(比如 node 0 包含 CPU0–15,node 1 包含 CPU16–31) - 再查网卡直连的 NUMA node:
lspci -vv -s $(ethtool -i ens3f0 | grep 'bus-info' | awk '{print $2}') | grep NUMA - 如果网卡在 NUMA node 1,就只往
CPU16–31写smp_affinity_list,哪怕你有 64 核,也别往 node 0 的 CPU 上绑 /proc/softirqs里NET_RX列在某个 node 的 CPU 上集中飙升,而该 node 下无网卡直连 → 基本就是 NUMA 错配
irqbalance 悄悄复活、NUMA node 判定错误、或者驱动压根没启用 RSS。盯住 effective_affinity 和 ethtool -S 的比值,比反复调 smp_affinity_list 有用得多。