软中断（si）占用过高最典型表现是整体cpu使用率不高但某核si列飙升、ksoftirqd/x线程cpu接近100%，同时业务延迟抖动、p99上升、偶发超时；需用top -1观察单核si，shift+p找ksoftirqd，再结合/proc/softirqs和mpstat -p all 1定位net_rx等异常计数。
软中断（si）占用过高，最典型的表现是：整体 CPU 使用率不高，但某个核的 si 列飙升、ksoftirqd/X 线程 CPU 占用接近 100%，同时业务出现延迟抖动、P99 上升、偶发超时——这说明网络或内核协议栈正在“悄悄吃掉”本该服务应用的 CPU 时间。
看准指标：确认真是软中断在作怪
登录后第一件事不是杀进程，而是执行：
top → 按 1 展开单核视图 → 观察各核的 si 列；再按 Shift + P 排序，找 ksoftirqd/X 进程。若某核 si > 60% 且 ksoftirqd/X 持续跑满，基本锁定软中断问题。
补充验证命令：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- cat /proc/softirqs：查看各类型软中断计数，重点关注 NET_RX（网卡收包）、NET_TX（发包）、TIMER（定时器）是否远高于其他项
- mpstat -P ALL 1：逐秒观察每核的 %si 变化，确认是否集中在特定 CPU
定位来源：到底是哪块在狂发软中断
软中断本身不干活，它只是“被触发”的结果。高 si 通常源于三类源头：
- 网卡收包风暴：DDoS、SYN Flood、大量小包（如 UDP 心跳）、网卡 RSS 配置不当导致流量全打到单核
- 驱动或固件异常：老旧网卡驱动、固件 bug 导致中断频繁触发（如某些 Intel I350 卡在高吞吐下会持续触发 NET_RX）
- 内核协议栈压力：conntrack 表满、nf_conntrack_gc 过于频繁、iptables 规则过多且匹配耗时、TCP 时间戳或校验和卸载关闭导致 CPU 软处理激增
快速判断法：用 ss -s 查看 socket 统计，若 inuse 或 orphan 数量异常高，或 netstat -s | grep -i "packet reassembled" 显示大量分片重组，都指向网络层瓶颈。
常见调优动作：能直接抄的几条命令
无需改代码，多数情况靠配置调整就能缓解：
-
启用网卡多队列与 RSS 均衡：
检查 ethtool -l eth0 看支持多少 RX/TX 队列；用 ethtool -L eth0 rx N tx N 开启（N 为 CPU 核数）；再确认 /sys/class/net/eth0/queues/ 下队列已创建，并绑定 IRQ 到不同 CPU（可用 sudo sh -c 'echo 0-3 > /proc/irq/*/smp_affinity_list' 均匀分配） -
开启硬件卸载：
ethtool -K eth0 gro on gso on tso on lro on（GRO/GSO/TSO 减少软中断次数，注意 LRO 与某些中间设备兼容性） -
调大 net.core.netdev_budget：
默认 300，可临时设为 600：sysctl -w net.core.netdev_budget=600（让每次软中断处理更多包，减少触发频率） -
限制 conntrack 表大小与老化时间：
sysctl -w net.netfilter.nf_conntrack_max=65536
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=1800（避免哈希冲突和 GC 占用过多 CPU）
进阶排查：当常规手段无效时
如果调完仍高，需深入内核行为：
- 抓包比对：用 tcpdump -i eth0 -c 1000 看实际流量特征——是否全是 SYN、小包、重复 ACK？
-
perf trace 跟踪软中断上下文：
perf record -e irq:softirq_entry -a sleep 10
perf script | grep NET_RX（确认软中断入口是否真由网卡驱动触发） - 检查中断线程化是否启用：某些老内核或驱动未开启 threaded_irq，导致硬中断返回后必须立刻处理软中断；可查 cat /proc/interrupts | grep eth0，若第二列是 PCI-MSI 且无 threaded 字样，考虑升级驱动或内核
