Linux 软中断原理：网卡报文是怎么抢占 CPU 的

很多托管服务器运维会遇到一个很迷惑的现象： top 里看用户 CPU、系统 CPU 占用都不高，但是 si（软中断）持续走高，业务接口卡顿、数据包处理跟不上、并发上不去。查带宽监控，带宽还远远没跑满。很多人不清楚：网卡收包并不是直接交给应用程序，网卡报文，就是通过硬中断 + 软中断这套机制抢占 CPU 来处理的。今天把这套流程通俗拆解清楚，结合托管服务器的网卡多队列实操场景来讲。

一、先分清：硬中断和软中断

硬件（网卡）收到数据包之后，第一件事是触发硬中断（IRQ） 。硬中断优先级极高，一旦触发，CPU 立刻停下手上正在跑的任务，去响应网卡。但硬中断里面要执行的代码必须越快结束越好，不能做复杂工作：解析报文、拷贝数据、协议栈处理这些耗时操作，不能放在硬中断上下文里，否则会阻塞别的硬件中断，引发更大问题。

于是 Linux 做了分工：

硬中断（hardirq）：网卡通知 CPU "有包来了"，只做极简标记，快速退出；
软中断（softirq）：延迟执行的后半段繁重工作，报文解析、交给内核协议栈，都放在软中断里执行。

网卡收包对应的软中断类型就是 NET_RX，发包是 NET_TX，也就是我们在 top 看到 si 里面网络流量的来源。

一句话理解： 硬中断是敲门通知，软中断是开门之后，真正搬货处理报文的工人。

二、完整流程：网卡收到报文，如何抢占 CPU

数据包从机房交换机送到服务器网卡芯片（NIC）；
网卡把报文 DMA 直接写到内存预分配的环形缓冲区（Rx Ring），不需要 CPU 拷贝；
网卡向 CPU 发送硬件中断信号：告知 CPU，缓冲区已经有新数据包；
CPU 收到硬中断，暂停当前正在运行的进程，进入硬中断处理函数；
硬中断里只做标记：标记这个 CPU 有网络报文待处理，触发NET_RX软中断；硬中断快速返回，释放硬件中断通道；
退出硬中断上下文之后，内核检测到挂起的软中断，在当前 CPU 上执行软中断处理函数；
软中断里，从环形缓冲区取出报文，做校验、skb 封装，递交给内核 TCP/IP 协议栈；
协议栈逐层解析 IP、TCP，最后送到 socket，唤醒等待数据的业务进程（Java、PHP、Go 服务等）。

重点：默认情况下，网卡硬中断落在哪个 CPU，后续这个报文的软中断，就会在同一个 CPU 上处理 。这就是经典问题根源：单 CPU 被网络软中断打满，其他 CPU 空闲，整体负载看着不高，业务却卡。

三、为什么托管服务器容易出现软中断 si 过高？

托管服务器常年 7×24 接收外网报文，CC、大量短连接、高频小包业务（接口、订单、游戏网关）最容易触发软中断瓶颈：

网卡中断全部绑定在同一个 CPU 核心（没有开启网卡多队列、没有做中断亲和），所有报文的软中断全部挤在一个核，单核打满；
小包风暴：大量短连接、高频小数据包。大包靠 DMA 传输压力小，小包单位数量多，每一个包都要走一遍中断、软中断流程，单位时间触发次数爆炸；
网卡队列数量不足，多核心服务器网卡只开 1 个 RX 队列；
业务大量 TIME_WAIT、频繁建连断连，TCP 协议栈开销上升，加重软中断处理负担；
机房内广播风暴、ARP 报文过多，无用报文持续抢占 CPU。

很多运维踩坑：看总 CPU 负载很低，以为 CPU 资源充足。但软中断绑定的那一个核心已经 100% 被 si 占死，业务排队，表现就是：ping 正常、带宽空闲、接口响应慢、随机超时。

四、怎么查看服务器软中断和网卡中断分布

几条运维常用命令，托管服务器可以直接上机排查：

复制代码

# 查看每个CPU的软中断统计，重点看 NET_RX、NET_TX
cat /proc/softirqs

# 查看网卡硬中断，确认中断绑定在哪些CPU
cat /proc/interrupts | grep eth0

# top 里观察 si 指标，si就是软中断占用
top

看 /proc/softirqs，如果只有一个 CPU 的 NET_RX 数值疯狂上涨，其他 CPU 几乎不动，就是典型中断不均衡。

五、优化思路：网卡多队列 + 中断亲和（托管服务器通用方案）

核心目标：把网卡报文的硬中断、软中断分散到多个 CPU 核心，避免单核瓶颈。

开启网卡多队列（RSS，接收端缩放），现代千兆 / 万兆网卡都支持；网卡自动根据报文哈希，把不同连接的报文分到不同 RX 队列，分配到不同 CPU；
设置中断亲和性，把网卡各个队列的中断号，均衡绑定到不同 CPU 核心；
开启 RPS/RFS：内核层面的报文分发，对不支持 RSS 的网卡、虚拟网卡很有用；
调大网卡 ring 缓冲区，减少报文在网卡侧丢包；
业务侧减少短连接，复用长连接，降低新建连接带来的中断压力。

⚠️ 注意：软中断本身不能跨 CPU 迁移。一个报文从硬中断落在某核，它的 NET_RX 软中断就固定在这个核处理，这也是为什么均衡中断至关重要。

六、误区澄清

❌ 软中断不是 "进程"，不能用 kill 杀掉；它属于内核上下文，优先级高于普通业务进程；
❌ 不是带宽跑满才会 si 高，小包场景下，带宽很低，软中断照样打满单核；
❌ 开启多队列不是万能，如果业务是单连接大流量（单条 TCP 传输），RSS 哈希无法分流，依旧只能跑在单个队列、单个 CPU 上。

七、托管机房场景下的补充提示

在我们易方科贸机房托管的服务器，万兆网卡、数据库、API 网关、交易类服务器，是软中断瓶颈高发机型。很多客户一开始只关注带宽、延迟，忽略网卡中断分布，业务并发上来之后，莫名其妙卡顿，排查很久才定位到单核软中断瓶颈。上架时提前做好网卡 RSS、中断亲和配置，可以提前规避这类隐性性能瓶颈。