用 watch -n 1 'grep -i "网卡名" /proc/interrupts' 实时观察各 -rx-/-tx- 中断行cpu列增长斜率，若所有队列均只在单核上涨，则存在中断绑定失效或未启用多队列；需结合 grep -c 验证中断行数、lspci 查 msi-x 向量、dmesg 检查驱动报错，并停用 irqbalance 后手动配置 smp_affinity_list 或启用 rps。
怎么用 watch + grep 实时盯住网卡多队列中断增长斜率
没有“中断平衡走势图”这种现成图表，Linux 本身不画图——但你能用 watch 和 grep 把动态分布变成肉眼可判的“趋势流”。关键不是看静态数字，是看每秒谁涨得快、谁几乎不动。
- 先确认网卡名：
nmcli device status | grep ethernet，拿到真实设备名（如enp5s0f0） - 执行：
watch -n 1 'grep -i "enp5s0f0" /proc/interrupts'，观察带-rx-0、-rx-1、-tx-2后缀的行 - 重点盯各 CPU 列（
CPU0、CPU1…）数值变化：如果enp5s0f0-rx-0只在CPU0列跳，enp5s0f0-rx-1只在CPU1列跳，说明队列已分散；若所有-rx-*行都只涨同一列，就是绑定失效或队列没真启用 - 别信“总数均衡”：某队列每秒涨 500，另一队列涨 5，哪怕总和差不多，也是严重倾斜——软中断会全挤在第一个核上
为什么 ethtool -l 显示 combined > 1 却只看到一行中断
网卡驱动说开了 4 队列，/proc/interrupts 却只有一行匹配？八成是硬件或固件没真分配 MSI-X 中断向量，或者内核没成功注册多中断号。
- 查实际中断行数：
grep -c "enp5s0f0" /proc/interrupts，结果为 1 就说明只绑了主 IRQ，多队列形同虚设 - 验证驱动是否支持并启用了 MSI-X：
lspci -vv -s $(ethtool -i enp5s0f0 | grep bus-info | awk '{print $2}') | grep -A 10 MSI，输出里要有MSI-X: Enable+ Count=且Count≥ 队列数 - 检查内核日志有没有报错：
dmesg | grep -i "enp5s0f0.*msi\|irq"，常见失败提示是Failed to allocate MSI-X vectors - 某些 Intel 网卡（如 i40e）需额外加载参数：
modprobe i40e max_vfs=0 RSS=1，否则即使ethtool -l显示 combined=8，也只用一个 IRQ
怎么确认 smp_affinity_list 是否真正生效
写了 smp_affinity_list，/proc/interrupts 数字还在单核狂涨？不是写错了，就是被覆盖了，或者根本没写进去。
- 查当前生效值：
cat /proc/irq/$(grep "enp5s0f0-rx-0" /proc/interrupts | awk '{print $1}' | tr -d ':')/smp_affinity_list，对比你写的值是否一致 - 查是否被 irqbalance 覆盖：
systemctl is-active irqbalance，只要返回active，它就在后台重写smp_affinity_list—— 必须sudo systemctl stop irqbalance && sudo systemctl disable irqbalance - 写入后立刻验证：
echo 0-3 | sudo tee /proc/irq/42/smp_affinity_list（42 是你的 rx-0 中断号），再立刻cat /proc/irq/42/smp_affinity_list，若输出不是0-3，说明该 IRQ 不支持动态调整（ls /proc/irq/42/看不到smp_affinity_list文件） - NUMA 架构下，优先绑本地 CPU：
lscpu | grep "NUMA node(s)"和lspci -vv -s $(ethtool -i enp5s0f0 | grep bus-info | awk '{print $2}') | grep NUMA交叉确认节点编号，再写如echo "0,4,8,12" | sudo tee /proc/irq/42/smp_affinity_list
软中断 NET_RX 堆积却看不到对应硬中断飙升怎么办
ksoftirqd/0 占满 CPU0，但 /proc/interrupts 里 enp5s0f0-rx-* 各列增长平缓？说明硬中断触发少，但每次带进来大量包，全压在软中断里串行处理——这是 NAPI 或 GRO 导致的典型“假均衡”。
- 查网卡收包统计：
ethtool -S enp5s0f0 | grep -E "(rx_packets|rx_bytes|rx_jabbers|rx_missed)"，若rx_packets每秒几万，而/proc/interrupts里对应中断每秒只涨几十，基本确定 NAPI 在轮询模式工作 - 确认 GRO/LRO 是否开启：
ethtool -k enp5s0f0 | grep "generic-receive-offload\|large-receive-offload"，开启状态下单次中断可能处理数百帧，NET_RX计数会远高于硬中断计数 - 查软中断分布：
cat /proc/softirqs | grep NET_RX，对比各 CPU 列数值；若只有CPU0列暴涨，说明即使硬中断分散了，软中断仍没跨核调度——这是内核默认行为，需靠 RPS/RFS 手动干预 - RPS 配置示例：
echo f | sudo tee /sys/class/net/enp5s0f0/queues/rx-0/rps_cpus（十六进制掩码，f=CPU0–3），它让软中断模拟多核分发，不依赖硬中断亲和性
/proc/interrupts 的数字，也不动 smp_affinity_list，却能彻底改变 CPU 负载形态——这点最容易被忽略。
