软中断（softirq）是Linux内核中一种延迟处理机制。当网卡收到数据包、磁盘完成IO等硬件事件发生时，内核并不会在硬件中断上下文里把所有工作做完，而是把耗时的部分挂到软中断队列里，等待合适的时机处理。这样设计是为了让硬件中断尽快返回，但代价是软中断本身也消耗CPU。在top命令的输出中，软中断的CPU占用体现为si这一列。如果si长期处于很高的水平，比如单核被打满，往往意味着网络收发、丢包重传或者中断分布不均等问题。这篇文章从原理到实操命令，完整梳理一遍排查思路。
先搞清楚软中断是怎么产生的
理解软中断的来源，是排查的第一步。在Linux内核里，软中断的类型定义在include/linux/interrupt.h中，常见的有HI_SOFTIRQ、TIMER_SOFTIRQ、NET_TX_SOFTIRQ、NET_RX_SOFTIRQ、TASKLET_SOFTIRQ等。实际生产环境中，si过高几乎都和NET_RX_SOFTIRQ（网络接收）有关，少量场景是NET_TX_SOFTIRQ（网络发送）。
当一个数据包到达网卡，网卡通过DMA把包写入内存环，然后向CPU发出硬件中断。硬件中断处理函数本身只做最少的工作：应答网卡、屏蔽该中断，然后触发NET_RX_SOFTIRQ。软中断的执行点主要有两处：一是硬件中断返回时，二是每个CPU上都有一个叫ksoftirqd的内核线程，当软中断积压过多时会唤醒它来兜底处理。
这一点很关键：如果你在top里看到ksoftirqd/0这类进程占用了大量CPU，说明该CPU上的软中断已经积压到正常收包路径处理不过来的程度了。ksoftirqd不是问题的原因，而是问题的表现，真正要查的是为什么会有这么多软中断，以及为什么它们都集中在这一个CPU上。
第一步：确认软中断的类型和数量
排查从/proc/softirqs开始，这个文件按CPU统计了各类软中断的累计次数：
cat /proc/softirqs # 间隔几秒采样两次，观察增量 cat /proc/softirqs && sleep 5 && cat /proc/softirqs
重点对比两次输出的差值。如果NET_RX增长飞快，每秒百万级别，说明软中断来自网络收包；如果NET_TX增长明显，则是发包侧的问题；如果是TIMER增长很快，那问题可能出在定时器风暴，比如大量短周期的定时任务。多数情况下你会看到NET_RX一枝独秀。
接着看软中断在CPU上的分布。如果所有增量都集中在CPU0一列，而机器有几十个核，那就是典型的中断不均衡：所有网络中断都打在了一个核上，单核被打满，整机性能却没吃满。这种情况的排查方向和软中断总量过大是完全不同的，下面分别展开。
第二步：检查硬件中断的分布情况
软中断通常在接收硬件中断的那个CPU上执行，所以先看硬件中断打到了哪里：
# 查看网卡中断分布，mpstat按核观察软中断占比 cat /proc/interrupts | grep eth0 mpstat -P ALL 1 5
在/proc/interrupts的输出里，每一行是一个中断号，后面跟着它在各CPU上触发的次数。如果网卡只占用一个中断号，且计数全部落在CPU0，说明是单队列网卡或中断绑定有问题；如果占用了多个中断号（比如eth0-TxRx-0到eth0-TxRx-7），分布却仍然集中，可能是irqbalance服务没起，或者被手工绑定了亲和性。
多队列网卡场景下，最优的做法是让每个队列的中断均匀分布在各个NUMA节点的CPU上。可以检查irqbalance是否运行：
systemctl status irqbalance # 查看某个中断的亲和性掩码 cat /proc/irq/26/smp_affinity_list
对于不支持RSS（接收侧扩展）的单队列网卡，内核提供了RPS/RFS作为软件层面的补充，把收包处理分散到多个CPU：
# 对eth0的队列0开启RPS，掩码表示可用CPU集合 echo "fffe" > /sys/class/net/eth0/queues/rx-0/rps_cpus
注意掩码要避开接收中断所在的CPU0本身，否则起不到分流作用。调整后再用mpstat观察各核si是否趋于均衡。
第三步：判断是流量真大还是有异常
中断均衡之后，如果整体软中断依然很高，就要判断流量本身是否合理。先用ipconfig或ip -s link看网卡速率和丢包统计：
ip -s -s link show eth0 # 观察收发包速率 sar -n DEV 1 5
把pps（每秒包数）和带宽分开看。软中断开销主要和pps相关，一个100G网卡跑大包和千兆网卡跑小包，pps可能一样，软中断压力也接近。如果pps确实很高但业务流量正常，那属于容量问题，只能考虑升级硬件特性，比如开启网卡offload、使用DPDK内核旁路，或者换支持更多队列的网卡。
如果流量并不大但NET_RX计数暴涨，常见原因有三类：一是受到扫描攻击或异常流量冲击，可以用conntrack统计和防火墙日志确认；二是网卡或驱动层面的丢包重传，dropwatch和ethtool -S能看到丢的位置：
ethtool -S eth0 | grep -i drop dropwatch -l kas
dropwatch能显示丢包发生的内核函数位置，如果大量丢在netif_receive_skb附近，通常意味着软中断处理不过来导致backlog溢出，这时可以调大net.core.netdev_max_backlog，但调参只是缓解，根源还是要解决流量或均衡问题。三是TCP重传风暴，用ss -ti观察重传计数，定位到具体连接和对端。
总结一套完整的排查顺序
把上面的内容串成一条固定的排查链路，遇到si过高时按顺序执行即可：先用top确认si占比和ksoftirqd状态；再看/proc/softirqs确认软中断类型；然后用/proc/interrupts和mpstat检查中断分布，不均衡就调irqbalance或RPS；均衡后仍然高，就用sar -n DEV评估pps是否匹配业务量；流量异常时用dropwatch、conntrack、ss定位丢包、攻击或重传。每一步都有明确的判断依据，避免一上来就盲目改内核参数。软中断问题十有八九落在流量、均衡、丢包这三件事上，带着这三个方向去查，基本都能找到根因。