需确认多队列中断是否真实分散至多个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 和你写的值是否一致。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 查某 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 有用得多。 
