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出发，结合网卡能力、驱动状态、实际流量特征三层交叉验证，而不是盲目调参。
