答案是软中断分布不均需结合/proc/softirqs秒级增长、硬中断绑定及rps配置综合判断：net_rx单核飙升超其他核5–10倍且每秒增长>5万次即为异常，常因硬中断集中、多队列未启用或rps关闭导致。

软中断分布不均是多核CPU负载失衡的最常见原因，直接看 /proc/softirqs 就能定位，但必须结合秒级增长速率和 CPU 绑定逻辑来判断是否真有问题。

怎么看 /proc/softirqs 里 NET_RX 是否异常飙升

NET_RX 是网卡软中断的核心指标，单核数值远超其他核（比如 CPU0 是 CPU1 的 8 倍），基本等于收包路径已堵死。

• 执行 watch -n 1 'grep NET_RX /proc/softirqs'，观察每秒增长量：单核差值持续 >5 万/秒就要介入
• 别只盯绝对值——/proc/softirqs 是累计值，重启后归零；重点看动态变化趋势
• 若 NET_RX 高的同时 TIMER 或 SCHED 也同步暴涨，说明软中断处理太慢，正在拖垮调度器和定时器回调
• NET_RX 和 NET_TX 差异极大（如 RX 是 TX 的 10 倍），大概率是应用没及时读 socket，接收队列堆积，不是中断本身的问题

为什么 mpstat -P ALL 1 显示某 CPU 的 %soft 持续 >30% 却查不到对应进程

%soft 是软中断上下文占用 CPU 的比例，它不属于任何用户进程，也不会出现在 top 或 pidstat 进程列表里。

宝塔Linux面板11.8.1

宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。

下载

• ksoftirqd/0 线程高占用 ≠ 它在“干活”，而是它在排队等硬中断交活过来；真正瓶颈在硬中断绑定或网卡队列配置
• pidstat -u 5 完全不统计软中断，它的 %system 包含系统调用、锁竞争等，但不区分是否由软中断触发
• 要确认是不是软中断导致，得交叉验证：mpstat 看 %soft，cat /proc/softirqs 看哪一列涨得最快，再回查 /proc/interrupts 中对应设备的硬中断分布

怎么确认软中断是否被错误地绑死在单个 CPU 上

软中断本身不设亲和性，但它默认在触发它的那个 CPU 上执行。所以硬中断打在哪颗 CPU，软中断就大概率在哪颗 CPU 处理。

• 先查网卡硬中断分布：grep -E "(eth|enp|ens)" /proc/interrupts，看各 CPU 列是否严重倾斜
• 再查网卡是否开了多队列：ethtool -l eth0，如果 Combined: 1，说明只有一个接收队列，所有包都走同一个 IRQ，软中断自然无法摊开
• 检查 RPS 是否启用：cat /proc/sys/net/core/rps_cpu_mask，为空或全 0 表示关闭，软中断无法跨核迁移
• 注意：手动改 /proc/irq/N/smp_affinity 后又变回去？很可能是 irqbalance 在后台覆盖，临时停用它再试：sudo systemctl stop irqbalance

真正难的不是看到 NET_RX 高，而是分清它是“硬件收包太多”“驱动没开多队列”“RPS 关闭”还是“应用层读取太慢”。这四者现象相似，但修复路径完全不同——漏掉任一环，调了也白调。