LinuxCPU软中断高如何处理_网络与驱动分析【教学】

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、网卡丢包

某些驱动在特定负载下会反复触发软中断，例如：

标签： linux 栈 linux系统 虚拟化