irqbalance突然不工作常见于启动过早或以--no-daemon/--oneshot模式运行后退出；验证需检查systemctl状态及--debug输出；手动绑定前须确认CPU架构、当前绑定CPU列表和在线CPU范围。
irqbalance 为什么突然不干活了
常见现象是 irqbalance 进程在运行，但 /proc/irq/*/smp_affinity 值长期不变，多个中断集中落在 CPU0 上，cat /proc/interrupts 显示某网卡 IRQ 几乎全在单个 CPU。根本原因通常是 irqbalance 启动时系统尚未完成设备枚举（比如内核启动早期、热插拔网卡后未触发重平衡），或它被 systemd 以 --no-daemon 或 --oneshot 模式调用后退出，又没配置自动重启。
验证方法：执行 systemctl status irqbalance 看是否 active (running)；再运行 irqbalance --debug --foreground 观察输出里是否有 “No IRQs found” 或 “Skipping IRQ X: no affinity mask change needed” —— 后者往往意味着它认为当前绑定已“最优”，实际却是僵化状态。
手动写 smp_affinity 前必须确认的三件事
直接 echo 十六进制值进 /proc/irq/*/smp_affinity 很容易出错，先确认：
-
grep -i "model name" /proc/cpuinfo | head -1确认 CPU 是 x86_64（支持 64 位掩码）还是 ARM64（部分旧内核用 32 位）； -
cat /proc/irq/*/cpulist查看当前 IRQ 实际绑定了哪些 CPU（比smp_affinity更直观）； -
lscpu | grep "CPU\(s\)"和cat /sys/devices/system/cpu/online核对在线 CPU 列表，避免往 offline CPU 写掩码导致写入失败且无提示。
给网卡 IRQ 绑定到 CPU2 和 CPU3 的实操步骤
以 Intel i40e 网卡为例，假设 cat /proc/interrupts | grep i40e 显示 IRQ 128–135 属于该设备：
echo 0c > /proc/irq/128/smp_affinity echo 0c > /proc/irq/129/smp_affinity echo 0c > /proc/irq/130/smp_affinity # ... 依此类推
其中 0c 是十六进制，对应二进制 1100，即启用 CPU2（bit2）和 CPU3（bit3）。注意：smp_affinity 位序从右往左，bit0 = CPU0，bit1 = CPU1，以此类推；写入值必须是合法十六进制字符串，不能带 0x 前缀，也不能是十进制。
若需绑定到 CPU4–CPU7，则用 f0（11110000）；若只绑 CPU0，必须写 1，不是 01 或 0001 —— 多余前导零会导致写入失败且静默忽略。
如何让手动绑定持久化且不被 irqbalance 覆盖
irqbalance 默认每几秒扫描并覆盖手动设置。要禁用其对特定 IRQ 的干预，需在 /etc/irqbalance/irqbalance.conf 中添加：
banirq=128,129,130,131,132,133,134,135
然后重启服务：systemctl restart irqbalance。也可临时停用整个服务：systemctl stop irqbalance，但生产环境建议只 ban 特定 IRQ，保留其对其他设备（如 SATA、USB）的自动管理能力。
更稳妥的做法是把 echo 命令写进 systemd service，在网卡驱动加载后执行（例如监听 netdev udev 事件），否则 reboot 后绑定丢失 —— 这点常被忽略，尤其在使用 DPDK 或 SR-IOV 场景下。
