在高并发场景下，如何优雅地解决网卡多队列（RSS）导致的 CPU 软中断不均与风暴问题？

在承载高并发、大吞吐量网络业务（如 LVS、Nginx 网关、高 QPS Redis 集群）的 Linux 多核服务器上，“CPU 0 独占网络软中断，其他 CPU 闲得发慌” 或者 “ksoftirqd/0 进程 CPU 占用率飙升至 100%，导致系统丢包严重” 是非常典型的生产故障。

尽管现代网卡普遍支持 RSS（Receive Side Scaling，网卡多队列），能够将网络流量分发到不同的物理队列中，但在默认配置或复杂业务场景下，软中断（Soft IRQ）倾斜与软中断风暴依然频发。本文将从硬件原理、Linux 内核网络栈、NUMA 架构以及生产实践出发，深入剖析如何优雅地解决这一顽疾。

一、 现象剖析：为什么多队列网卡依然会发生软中断倾斜？

RSS 的核心机制是通过硬件 Hash 算法（通常是 Toeplitz 算法），根据 TCP/UDP 的四元组（源 IP、目的 IP、源端口、目的端口）计算出一个 Hash 值，并根据这个值将数据包分发到不同的网卡硬件接收队列（Rx Queue）。每一个队列对应一个独立的 MSI-X 中断号，理应由不同的 CPU 核心去处理。

但在生产环境中，以下三个核心原因经常导致 RSS 失效：

1. irqbalance 服务的“帮倒忙”：
   Linux 默认运行的 irqbalance 守护进程试图在所有 CPU 之间动态平衡所有中断。然而，在高并发网络场景下，它的算法过于粗糙，经常将网卡队列中断在不同的 CPU 核心之间频繁切换。这不仅会导致 CPU 缓存（L1/L2 Cache）频繁失效，还可能在切换瞬间造成中断集中在单核上，诱发软中断风暴。
2. 极化流量（单一流）导致 Hash 撞车：
   如果业务存在大量的长连接，或者由于前置了 CDN/四层负载均衡（如 LVS、F5），导致流入服务器的数据包中，源 IP 或目的 IP 高度集中。此时，即使是四元组 Hash，计算出来的 Hash 值也极易落入同一个硬件队列，导致单核被榨干，其他核无所事事。
3. NUMA 架构不匹配（Cross-Node Memory Access）：
   网卡插在 PCIe 插槽上，而 PCIe 控制器是直连在某个特定的 CPU Socket（NUMA Node）上的。如果网卡中断被分发到了另一个 NUMA Node 的 CPU 核心上，CPU 在处理软中断时需要跨 Node 访问内存，巨大的 QPI/UPI 总线延迟会导致软中断处理变慢，从而在接收队列中积压，最终引发软中断风暴。

二、 诊断工具链：如何精准定位软中断风暴？

在动手优化之前，必须先用数据说话。以下三个步骤可以帮你精准定位瓶颈：

1. 监控各 CPU 核心的软中断占比

使用 mpstat 命令观察各个 CPU 的 soft（软中断）指标：

# 每秒输出一次所有 CPU 的指标
mpstat -P ALL 1

• 判断标准：若发现 CPU 0 或某几个特定 CPU 的 %soft 接近 80%~100%，而其他 CPU 的 %soft 低于 5%，说明存在严重的软中断倾斜。

2. 查看中断在 CPU 上的实时分布

通过 /proc/interrupts 可以清晰看到网卡各队列（通常命名为 ethX-TxRx-Y 或 ethX-fp-Y）的中断计数。
我们可以使用 watch 实时观察每秒的变化：

watch -d -n 1 "cat /proc/interrupts | grep -E 'eth|em|ens|enp'"

• 判断标准：观察中断计数器（每一列代表一个 CPU 核心）的增长速度。如果只有一两列的数值在疯狂飙升，而其他列纹丝不动，说明硬件中断绑定存在偏斜。

3. 检查 ksoftirqd 进程状态

ps aux | grep ksoftirqd

当内核处理软中断的时间过长（超过 2ms）或连续处理次数过多时，会将未处理完的任务移交给内核线程 ksoftirqd/X（X 为 CPU 编号）。如果 ksoftirqd/X 的 CPU 占用率极高，说明该核已经不堪重负。

三、 落地解决方案：从硬件到内核的优雅调优

解决软中断风暴和倾斜，不能只靠单一手段，而应遵循**“物理绑核 -> 逻辑分流 -> 协议栈微调”**的阶梯式治理方案。

阶梯一：禁用 irqbalance，手动进行硬中断绑定（IRQ Affinity）

在高并发服务器上，第一步也是最重要的一步，就是关闭 irqbalance 并手动将网卡队列与 CPU 核心一对一绑定。

1. 关闭并禁用 irqbalance

systemctl stop irqbalance
systemctl disable irqbalance

2. 识别网卡所在的 NUMA 节点

将网卡队列绑定到与网卡处于同一个 NUMA 节点的 CPU 核心上，可以获得极低的内存访问延迟。

# 查看网卡所属的 NUMA Node
cat /sys/class/net/eth0/device/numa_node

假设输出为 0，我们需要找到 NUMA Node 0 包含哪些 CPU 核心：

lscpu | grep "NUMA node0"
# 输出示例：NUMA node0 CPU(s):   0-15,32-47

3. 编写脚本，手动 1:1 绑定

我们可以编写一个 Shell 脚本，将网卡的每个队列依次绑定到 Node 0 的物理核上（尽量避免绑定在超线程的辅助核上，如先绑定 0-15，再绑定 32-47）。

以下是生产环境常用的网卡中断绑定脚本模板：

#!/bin/bash
# 替换为你的物理网卡接口名称
NIC="eth0"

# 获取网卡的所有中断号和对应的队列
IRQS=$(cat /proc/interrupts | grep -E "${NIC}-.*(TxRx|rx|tx)" | awk '{print $1}' | cut -d: -f1)

# 如果上面的正则没匹配到，可以尝试更通用的匹配
if [ -z "$IRQS" ]; then
    IRQS=$(cat /proc/interrupts | grep -i "${NIC}" | awk '{print $1}' | cut -d: -f1)
fi

# 获取 NUMA Node 0 的物理 CPU 核心列表（此处以 0-15 为例，根据实际情况调整）
CPUS=(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)
NUM_CPUS=${#CPUS[@]}

idx=0
for irq in $IRQS; do
    # 计算当前应该绑定的 CPU 核心
    cpu=${CPUS[$((idx % NUM_CPUS))]}
    
    # 将 CPU 编号转换为 16 进制掩码（smp_affinity_list 更直观，部分老内核不支持，可用 smp_affinity_list）
    if [ -f "/proc/irq/${irq}/smp_affinity_list" ]; then
        echo "Binding IRQ ${irq} to CPU ${cpu}"
        echo "${cpu}" > "/proc/irq/${irq}/smp_affinity_list"
    else
        # 兼容老内核，使用十六进制掩码
        mask=$(printf "%x" $((1 << cpu)))
        echo "Binding IRQ ${irq} to CPU mask ${mask}"
        echo "${mask}" > "/proc/irq/${irq}/smp_affinity"
    fi
    let idx++
done

阶梯二：若网卡队列数少于 CPU 核心数，启用 RPS / RFS / XPS

有时，服务器有 64 个 CPU 核心，但网卡硬件只支持 8 个或 16 个队列。即使做完硬中断绑定，也只能压榨 16 个核，剩下的 48 个核根本无法参与网络协议栈（如 TCP/IP 握手、校验和计算等）的软中断处理。

此时，我们需要借助 Linux 内核提供的软件负载均衡机制：RPS (Receive Packet Steering) 和 RFS (Receive Flow Steering)。

1. 配置 RPS (接收数据包转向)

RPS 在软中断层模拟了 RSS 的功能。网卡通过硬中断将数据包收到某个 CPU 后，RPS 根据数据包的 Hash 值，将数据包放入其他 CPU 的积压队列中，从而将后续的协议栈处理（软中断）分流到其他物理核。

我们可以为每个网卡队列配置可以分流的 CPU 掩码（例如，允许分流到所有 CPU 核心）：

# 假设网卡为 eth0，有 8 个 rx 队列
# 将所有 CPU 核心（如 64 核对应的掩码为 ffffffff,ffffffff）写入 rps_cpus
for rx_dir in /sys/class/net/eth0/queues/rx-*; do
    echo "ffffffff,ffffffff" > "${rx_dir}/rps_cpus"
done

2. 配置 RFS (接收流转向)

RFS 是对 RPS 的优化。RFS 会考虑应用程序当前在哪个 CPU 上运行，并尽量将该连接的软中断分流到应用所在的 CPU，以提高 CPU L1 Cache 的命中率。

要启用 RFS，需要配置两个全局参数以及每个队列的流表大小：

# 1. 设置系统全局的最大 RFS 流数
sysctl -w net.core.rps_sock_flow_entries=32768

# 2. 设置每个队列的流数（推荐值：rps_sock_flow_entries / 队列数）
# 假设有 8 个队列，32768 / 8 = 4096
for rx_dir in /sys/class/net/eth0/queues/rx-*; do
    echo 4096 > "${rx_dir}/rps_flow_cnt"
done

3. 配置 XPS (发送包转向)

在发送端，XPS (Transmit Packet Steering) 能够根据发送数据的 CPU 核心，智能选择对应的发送队列。这可以极大地减少发送方向上的锁竞争。

# 推荐做法：将 XPS 绑定与硬件队列对应的 CPU 相同
for tx_dir in /sys/class/net/eth0/queues/tx-*; do
    # 写入与对应 RX 队列相同的 CPU 掩码
    echo "ffffffff,ffffffff" > "${tx_dir}/xps_cpus"
done

阶梯三：利用 ethtool 调整 Hash 算法与参数

当面临极化流量（例如：大流量的 UDP 视频流、固定的反向代理 IP 导致 Hash 倾斜）时，传统的 4-tuple Hash 往往会失效。此时需要微调网卡的过滤机制。

1. 调整 RSS 散列字段

如果流量主要集中在特定端口或特定 IP 上，可以尝试通过 ethtool 改变 Hash 字段。例如，让 UDP 流量仅根据 IP 进行 Hash，或包含 L4 端口：

# 查看当前 UDP 的 RSS Hash 规则
ethtool -n eth0 rx-flow-hash udp4

# 修改 UDP 4元组 Hash：包含源 IP、目的 IP、源端口、目的端口
ethtool -N eth0 rx-flow-hash udp4 sdfn

2. 调整网卡中断合并（Interrupt Coalescing）

如果软中断风暴是因为每秒的中断次数（pps）过高导致的，可以开启网卡的“中断合并”功能，让网卡攒够一定数量的数据包或等待一小段时间后，再向 CPU 发送一次中断，从而合并处理。

# 查看当前中断合并配置
ethtool -c eth0

# 开启自适应中断合并（由网卡驱动根据流量自动调节，推荐）
ethtool -C eth0 adaptive-rx on adaptive-tx on

# 或者手动微调：设置接收延迟时间为 30 微秒，或者积压 30 个包后再发送中断
ethtool -C eth0 rx-usecs 30 rx-frames 30

四、 生产环境优化实战 Checklist

在实际运维或系统初始化时，建议将上述优化整理成标准的配置规范。以下是一份完整的网络软中断优化 Checklist：

通过上述从硬件中断绑定、NUMA 亲和性，到内核 RPS 软件分流，再到网卡硬件中断合并的深度调优，多核服务器上的网络软中断不均与软中断风暴问题基本可以得到优雅且彻底的解决，从而将网络协议栈的处理能力发挥到极致。