网卡软中断不均导致连接堆积的本质是NET_RX集中于单核，使ksoftirqd持续满载、收包延迟，引发SYN/accept队列溢出；需通过mpstat和/proc/interrupts确认瓶颈，启用RPS或升级多队列并绑定中断亲和性，辅以长连接优化。
网卡软中断不均导致个别工作进程连接堆积，本质是网络收包（NET_RX）集中在单个 CPU 核上，软中断线程（如 ksoftirqd/0）持续满载，来不及处理新到的数据包，进而造成 TCP 连接队列（如 SYN queue 或 accept queue）堆积、连接超时、新建连接失败。这不是应用层代码问题，而是 Linux 网络栈与多核 CPU 协同失衡的典型表现。
确认是否为网卡软中断瓶颈
先排除误判，聚焦真实瓶颈：
- 运行
mpstat -P ALL 1，观察各 CPU 的%soft列：若某核（如 CPU0）长期高于 60%，其余核接近 0，即为明显信号 - 执行
cat /proc/interrupts | grep -E "(eth|enp|ens|eno)"，看网卡中断行是否只有一行（如45: ... eth0），且该行中仅某一 CPU 列数值远高于其他（例如 CPU0 是 CPU1 的百倍以上） - 检查网卡队列数：
ethtool -l eth0，若Combined: 1，说明是单队列网卡，无法硬件分流，必须靠软件机制补救 - 用
ss -lnt或netstat -s | grep -i "listen\|overflow"查看是否有listen overflows或syn drop，这是连接堆积的直接证据
启用 RPS 分散软中断负载
RPS（Receive Packet Steering）是内核级软件分流机制，无需硬件支持，适合虚拟机、老网卡或云主机：
- 查看当前配置：
cat /sys/class/net/eth0/queues/rx-0/rps_cpus - 启用多核接收：假设物理 CPU 核为 0–3，执行
echo 0f > /sys/class/net/eth0/queues/rx-0/rps_cpus（十六进制0f= 二进制1111） - 增大流表容量：
sysctl -w net.core.rps_sock_flow_entries=32768 - 设置每队列流计数：
echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt - 将上述命令写入
/etc/rc.local或 systemd 启动服务，确保重启后生效
升级为多队列网卡并绑定中断亲和性
硬件级优化效果更彻底，适用于物理服务器或支持 RSS 的云主机：
- 确认网卡支持多队列：
lspci -vvv | grep -A 10 "Ethernet controller" | grep -E "(MSI-X|TabSize)"，若含MSI-X: Enable+ Count > 1，则支持 - 开启 4 个队列：
ethtool -L eth0 combined 4（建议设为物理核心数） - 重启网卡后，
ls /sys/class/net/eth0/queues/应出现rx-0到rx-3多个接收队列 - 将各队列中断绑定到不同 CPU：
echo 0 > /proc/irq/$(cat /proc/interrupts | grep "eth0-rx-0" | awk '{print $1}' | tr -d ':')/smp_affinity_list，依此类推为 rx-1 绑定 CPU1，rx-2 绑定 CPU2……
配合协议层减少连接冲击
缓解短连接高频建连对中断系统的持续压力：
- Nginx 中启用上游长连接：
upstream backend { keepalive 32; ... }，搭配proxy_http_version 1.1;和proxy_set_header Connection ''; - 调高客户端保活：
keepalive_timeout 75s;，降低重连频次 - 若上游是 Tomcat、Spring Boot 等，延长其连接超时（如
server.connection-timeout=60000），避免主动断连引发反复建连 - 必要时在负载均衡层（如 LVS 或 Nginx）开启连接复用或限速，防止突发流量打穿中断处理能力
不复杂但容易忽略——连接堆积不是进程卡死，而是 CPU 核被软中断“锁死”在收包路径上。定位准、开 RPS、配队列、减建连，四步到位，连接队列就能回归正常水位。
