Linux 中 CPU 软中断偏高需定位真实瓶颈：先查 /proc/softirqs 识别 NET_RX 等异常类型，再结合 RSS/RPS 配置、驱动卸载设置及 perf 追踪协议栈路径，三层交叉验证。
Linux 系统中 CPU 软中断（softirq）持续偏高，通常意味着内核正在高频处理网络收发、定时器、任务队列等异步事件，尤其在网络负载重或驱动不当时表现明显。重点不是“压低数值”，而是定位真实瓶颈——是流量过大？网卡中断聚合不足？驱动有缺陷？还是应用层突发包冲击？
看懂软中断来源：/proc/softirqs 是第一现场
执行 cat /proc/softirqs 查看各类型软中断在每个 CPU 上的触发次数。重点关注：
- NET_RX：网卡收到数据包后触发的接收软中断——值高说明入向流量大或协议 栈处理慢
- NET_TX：发送完成确认或清理发送队列时触发——值高可能因发送队列积压、驱动释放 skb 不及时
- TIMER：高频率定时器（如 CFS 调度、RCU 回调）也会推高 softirq，需结合 perf top -e ‘irq:softirq_entry’ 进一步过滤
对比多轮输出（如每秒一次），观察是否某 CPU 持续飙升（不均衡）、或某 softirq 类型增长异常快。
检查网卡与中断配置：RSS、RPS、RFS 是否启用并合理
单 CPU 软中断过高，大概率是网卡中断未分散或软件收包路径未并行化：
- 用 ethtool -l eth0 确认网卡是否支持并启用了 RSS（Receive Side Scaling），硬件层面将不同流分发到不同 CPU
- 检查 /proc/sys/net/core/rps_sock_flow_entries 和 /sys/class/net/eth0/queues/rx-*/rps_cpus，确保 RPS（软件层面收包均衡）已配且掩码覆盖足够 CPU
- RFS（Receive Flow Steering）可提升缓存局部性，需配合应用程序调用 setsockopt(SO_ATTACH_REUSEPORT_CBPF) 或使用 flow director 硬件支持
若全关 RSS/RPS，所有包都由一个 CPU 处理 NET_RX 软中断，必然瓶颈。
排查驱动与固件：老旧驱动、错误 offload、网卡丢包
某些驱动在特定负载下会反复触发软中断，例如：
- 禁用 TSO/GSO/LRO 等卸载功能：ethtool -K eth0 tso off gso off lro off，排除因分片 / 聚合异常导致协议栈频繁处理小包
- 检查 dmesg 是否有 “hardware error”、“reset adapter” 或“rx queue full”类报错，指向固件 bug 或硬件故障
- 对比同型号网卡在其他机器的表现，或临时更换驱动版本（如 ixgbe → ixgbevf，或升级 firmware）验证
特别注意 虚拟化 环境：vhost-net 或 VFIO 直通时，软中断可能转移到宿主机 vCPU，需同步检查 QEMU 参数与 virtio-net 特性协商。
抓包 + 协议栈追踪：确认是不是应用层在“制造”压力
软中断高 ≠ 网络本身有问题，可能是上层行为诱发：
- 用 tcpdump -i eth0 -c 1000 port 80 快速采样，看是否大量小包（如 HTTP 短连接、ACK 风暴、SYN 洪泛）
- 运行 perf record -e ‘irq:softirq_entry’ -g -a sleep 10，再用 perf script 分析调用栈，看 NET_RX 软中断是否集中在 ip_rcv_finish、tcp_v4_do_rcv 等函数
- 检查 ss - i 查看 socket 接收队列（rcv_space、rcv_rtt）和丢包统计（retrans、reord），确认是否因应用读取慢导致 sk_buff 堆积、反复触发软中断
常见诱因：未开启 TCP 快速打开（TFO）、应用未使用 SO_REUSEPORT、日志服务高频 flush 小包、监控探针轮询过于密集。
不复杂但容易忽略：软中断本身不可抢占，长时间运行会阻塞进程调度和硬中断响应。定位必须从 /proc/softirqs 出发，结合网卡能力、驱动状态、实际流量特征三层交叉验证，而不是盲目调参。
