这不是异常，而是默认行为：多数设备IRQ初始只绑定到CPU0，尤其在未启用irqbalance或未配置CONFIG_IRQ_REMAP的老系统上，导致/proc/interrupts中CPU0计数远高于其他CPU。
为什么 /proc/interrupts 里某 CPU 的中断数远高于其他 CPU
这不是异常，而是默认行为：多数设备 IRQ 初始只绑定到 CPU0，尤其在未启用中断负载均衡（如 irqbalance）或内核未配置 CONFIG_IRQ_REMAP 的老系统上。你会看到 /proc/interrupts 第一列（CPU0）数值爆炸，后面几列接近 0。
真正要问的是：这是否影响性能？答案取决于设备类型——网卡、NVMe、高性能 GPU 等高吞吐设备若只打到单个 CPU，会迅速吃满该核的软中断（softirq），导致延迟抖动、丢包或 I/O 延迟升高。
- 确认瓶颈：用
top -H看ksoftirqd/0占用率是否持续 >80%，再结合cat /proc/interrupts | grep eth0确认对应 IRQ 是否全落在 CPU0 - 别盲目绑多核：不是“越多越好”。比如单队列网卡只对应 1 个 IRQ，硬绑 4 个 CPU 没意义；而支持 MSI-X 的万兆网卡可能有 32 个独立 IRQ，才值得逐个分配
- 注意亲和性掩码是位图（bitmask），不是 CPU 编号列表。CPU0=0x1，CPU1=0x2，CPU0+CPU1=0x3，写错格式（如写成
"0,1"）会静默失败
smp_affinity 写入前必须确认 IRQ 支持可写
不是所有 IRQ 都允许手动修改 smp_affinity。PCIe 设备通常支持，但 APIC LINT0/LINT1、IPI、热插拔事件等内部中断会拒绝写入，直接报 Operation not permitted。
实操前先检查：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 运行
grep -q "NO_BALANCE" /proc/interrupts—— 若有输出，说明该行 IRQ 被标记为不可均衡，smp_affinity文件可能不存在或只读 - 进对应 IRQ 目录：
ls -l /proc/irq/42/smp_affinity*。如果只有smp_affinity_list（无smp_affinity），说明该 IRQ 使用的是十进制 CPU 列表格式（如"0,2,4"），而非十六进制掩码 - 有些驱动（如某些 Realtek 网卡）在加载时禁用 IRQ 平衡，需加内核参数
pci=noacpi或换驱动才能解锁
写 smp_affinity 的三种常见错误写法
写错格式不会报错，但完全不生效——值会被内核忽略并维持原状。最常踩的坑是混淆掩码进制和 CPU 编号范围。
- 误用十进制数：
echo 3 > /proc/irq/42/smp_affinity→ 实际写入的是十进制 3，但内核按十六进制解析，等价于 0x3（即 CPU0+CPU1），看似对，但若你本意是“只绑 CPU3”，就错了 - 超出 CPU 数量：系统有 8 核（CPU0–CPU7），却写
0xff0（0x111111110₂），最高位对应 CPU8，越界部分被截断，最终只绑了 CPU1–CPU7 - 没用 root 权限且未重定向：直接
echo 0x3 /proc/irq/42/smp_affinity是 shell 重定向失败，正确写法是echo 0x3 > /proc/irq/42/smp_affinity（注意>符号）
验证是否生效：改完立刻 cat /proc/irq/42/smp_affinity，再触发一次中断（如 ping 一下网关），然后 watch -n1 'cat /proc/interrupts | grep 42' 观察各列计数是否开始增长。
生产环境绕不开的两个现实约束
手动绑定 IRQ 不是“设一次就高枕无忧”。真实服务器上，硬件热插拔、DPDK 应用接管网卡、内核升级都可能重置亲和性设置。
-
irqbalance服务默认开启，它会在后台动态调整 IRQ 分布。如果你手动绑定了，又开了 irqbalance，两者会互相覆盖。停用命令是systemctl stop irqbalance && systemctl disable irqbalance，但别忘了检查是否被 systemd-resolved 或其他服务间接拉起 - 容器或 VM 场景下，宿主机写的
smp_affinity对 guest 无效。KVM 虚拟机需在启动参数加irqchip=on并配合virtio-msi，否则虚拟中断无法透传亲和性
最易被忽略的一点：CPU topology。NUMA 节点内跨 CPU 绑定（如绑 CPU8 和 CPU9）比跨节点（CPU0 和 CPU16）延迟低得多。用 lscpu | grep "NUMA node" 看清楚物理布局，再决定把 IRQ 和业务进程绑在同一 NUMA 节点内。
