软中断（softirq）过高，典型表现是 top 中 %si 持续超过 10%～15%，而系统负载（load average）不高、用户态和内核态 CPU 使用率（%us/%sy）却明显偏低。这说明 CPU 时间正被内核后台中断处理大量占用，不是业务逻辑在跑，而是网络收包、定时器或调度任务在“卡住”CPU。
看 /proc/softirqs 定位主因类型
软中断种类多，但真正影响性能的通常只有三类：
- NET_RX：网络数据包接收软中断。飙升说明网卡收包压力大，常见于高并发短连接、SYN Flood、udp 风暴等场景
- TIMER：内核定时器软中断。异常升高可能源于大量 hrtimer 或 RCU 回调堆积，比如某些驱动或模块频繁注册微秒级定时器
- SCHED：调度器软中断。持续偏高往往指向进程调度过于频繁，如大量短生命周期线程、cgroup 频繁限频触发重调度
执行 cat /proc/softirqs，重点对比各 CPU 列中这三列数值。若某 CPU 的 NET_RX 值比其他核高出一个数量级（例如 500 万 vs 5 万），说明软中断严重不均衡，大概率是硬中断绑定单一 CPU 导致的“单核瓶颈”。
查硬中断分布与网卡队列配置
软中断不均，根源常在硬中断绑定和网卡多队列策略错配：
- 用 cat /proc/interrupts | grep eth0 查看各 CPU 上 eth0 相关硬中断次数，确认是否集中在 0 号核
- 运行 cat /sys/class/net/eth0/device/msi_irqs/* 确认网卡支持的 MSI-X 向量数（即硬件队列数），应与 CPU 核数匹配
- 检查 cat /proc/sys/net/core/rps_cpu_mask 是否为空：为空表示 RPS（Receive Packet Steering）关闭，软中断无法跨核分发，必须开启
RPS、RSS、XPS 配置不一致时，容易触发 soft lockup 日志（dmesg | grep watchdog），此时仅调参数无效，需统一规划队列映射关系。
调参要讲配合，不能只改 netdev_budget
net.core.netdev_budget 控制每次软中断上下文最多处理多少个包，默认 300。盲目调大（如设为 600）反而更卡：
- 它会让 net_rx_action 占用单次软中断时间过长，阻塞其他关键任务（如实时线程、调度器）
- 合理值参考：千兆网卡建议 60–120，万兆网卡 120–240
- 必须同步调整：net.core.netdev_max_backlog（建议 ≥5000），并确保 RPS 已启用，否则只是把丢包压力转成延迟压力
交叉验证是否真由软中断拖慢业务
仅看 %si 高不够，要确认它是否实际打断了业务线程：
- 运行 perf record -e ‘syscalls:sys_enter_nanosleep,irq:softirq_entry’ -C 0 -g — sleep 10
- 再执行 perf script | grep -E ‘(net_rx|nanosleep)’
- 若大量 nanosleep 调用被 net_rx_action 中断打断，且堆栈显示在 __do_softirq 中单次耗时超 1ms，才可判定软中断是直接诱因