软中断持续高于10%–15%且伴响应延迟，多因网络收包不均或参数失当；需结合/proc/softirqs（重点NET_RX、TIMER、SCHED三列）、中断分布及perf归因交叉验证，而非仅看top %si。
软中断（%si）持续高于 10%–15%，尤其伴随业务响应延迟、抖动或 soft lockup 日志，大概率是网络收包处理不均或参数配置失当导致的。别只盯着 top 里的 %si 数值，得结合 /proc/softirqs、中断分布和实际业务行为交叉验证。
看 /proc/softirqs，盯紧三列
执行 cat /proc/softirqs，重点关注每行末尾对应各 CPU 的计数。真正有用的只有三列：
- NET_RX：网络数据包接收软中断。某 CPU 上该值比其他核高一个数量级（比如 500 万 vs 其他核几十万），说明网卡硬中断全打到这颗 CPU，软中断无法摊开；
- TIMER：内核定时器软中断。异常升高常与高频率 tick、cfs_bandwidth 过载或 RCU 回调积压有关；
- SCHED：调度器软中断。飙升多见于大量短生命周期线程频繁创建/销毁，或 cgroup 调度策略激进。
查硬中断绑定与队列映射
软中断堆积往往源于硬中断“扎堆”。分三步确认：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 运行 cat /proc/interrupts | grep eth0，观察各 CPU 上 eth0 相关中断计数是否严重不均；
- 检查网卡是否支持多队列：cat /sys/class/net/eth0/device/msi_irqs/*，输出文件数即 MSI-X 向量数，应 ≥ CPU 核数；
- 确认 RPS 是否启用：cat /proc/sys/net/core/rps_cpu_mask。若为空（0），RPS 关闭，软中断只能在硬中断所在 CPU 执行，极易单核过载。
别乱调 netdev_budget
net.core.netdev_budget 控制每次软中断上下文最多处理多少个包，默认 300。调大看似“清得快”，实则让 __do_softirq 占用 CPU 时间片过长，阻塞实时任务，抖动更明显。
- 千兆网卡建议设为 60–120，万兆设为 120–240；
- 必须同步调大 net.core.netdev_max_backlog（如 5000），否则丢包压力转为延迟压力；
- 单独改 budget 不开 RPS/RSS，基本无效，甚至恶化。
交叉验证是否真由软中断拖慢业务
仅靠 %si 高不能下结论。用 perf 做轻量级归因：
- 运行 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，才说明软中断直接抢占了业务线程。
软中断问题本质是中断负载分配与处理节奏失衡，不是调单个参数能解决的。重点在理清硬中断→RPS/RSS→软中断的链路，再针对性调参或重配队列映射。
