短连接高频请求导致CPU软中断堆积，本质是NET_RX集中单核；需先用top和/proc/softirqs确认瓶颈，再启用RPS、升级多队列网卡、配置长连接优化。
短连接高频请求导致 Nginx 所在服务器 CPU 中断频率过高，本质是网络收包（NET_RX）集中在单个 CPU 核上，引发软中断（softirq）堆积，进而拖慢整体响应、抬高 CPU 使用率。这不是 Nginx 本身性能差，而是 Linux 网络栈与硬件协同的负载不均问题。
确认是否为网卡软中断瓶颈
先验证问题根源，避免误判：
- 运行
top，观察si（softirq）列是否持续高于 15%，且集中在某一个 CPU（如 CPU1 占比远超其它核） - 执行
watch -n 1 'cat /proc/softirqs | grep NET_RX'，看各 CPU 的NET_RX计数是否严重不均衡（比如 CPU1 是 CPU2 的 5 倍以上） - 检查网卡队列数：
ethtool -l eth0或grep -i "rx queue" /var/log/dmesg，若显示1 rx queue(s)，说明是单队列网卡，这是典型诱因
启用 RPS（Receive Packet Steering）分散软中断
RPS 是内核软件层面的负载分发机制，无需硬件支持，适合虚拟机或老网卡：
- 查看当前 RPS 配置：
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，对应 CPU0–3） - 持久化配置（写入
/etc/rc.local或 systemd service）防止重启失效
升级为多队列网卡并启用 RSS
硬件级优化效果更彻底，适用于物理机或支持多队列的云主机：
- 确认网卡是否支持多队列：
ethtool -l eth0，若Combined最大值 > 1，则可开启 - 设置多队列：
ethtool -L eth0 combined 4（启用 4 个 RX/TX 队列） - 重启网卡或系统后，
/proc/interrupts中网卡中断应均匀分布到多个 CPU - 配合 RPS 或 RFS（Receive Flow Steering）进一步提升缓存局部性
配套优化：减少短连接冲击
从协议层降低单位时间新建连接数，缓解中断压力：
- 在 upstream 块中启用长连接：
keepalive 32;（保持空闲连接池）proxy_http_version 1.1;proxy_set_header Connection ''; - 调高客户端 keepalive 超时：
keepalive_timeout 75s;，减少重连频次 - 若上游服务支持，关闭其主动关闭连接行为（如 Tomcat 的
connectionTimeout设长些）
不复杂但容易忽略——软中断不是代码 bug，而是网络流量和 CPU 调度之间的“错配”。定位准、开 RPS、配队列、减建连，四步到位，CPU 就不会再被中断“钉死”在某一个核上了。
