Linux软中断查看与网卡优化技巧

本文深入解析了Linux系统中网卡软中断（尤其是NET_RX）异常飙高的精准诊断与高效优化方法，强调不能仅依赖/proc/softirqs的累计值，而必须通过watch命令实时观测秒级增长速率——单核每秒超5万次即属危险阈值；同时揭示了软中断风暴背后的真实根源：硬中断绑定失衡、网卡单队列限制、RPS未启用等关键配置缺失，并提供了从/proc/interrupts反向定位网卡设备、验证多队列与RPS状态、使用perf追踪驱动调用栈的一整套实战链路，彻底纠正常见误区（如盲目调大netdev_budget），帮助运维和内核开发者快速定位瓶颈、实现跨核负载均衡，避免将丢包压力错误转化为严重延迟。

怎么看 /proc/softirqs 里的 NET_RX 是否真在飙高

直接执行 cat /proc/softirqs 没用，它只给累计值。你要盯的是秒级增长速率——某 CPU 上 NET_RX 每秒涨超 5 万次，才说明正在发生软中断风暴。

实操命令：watch -n 1 'grep NET_RX /proc/softirqs'，盯着数字跳变。若 CPU0 列从 1200 万跳到 1205 万，而其他核几乎不动，这就是典型单核瓶颈。

注意三列联动：TIMER 和 SCHED 若同步飙升，大概率是 NET_RX 处理太慢导致回调积压、调度器被反复抢占，不是独立问题。

为什么 net_rx_action 占满 CPU0 却查不到对应网卡中断

ksoftirqd/0 高 ≠ 网卡中断在 CPU0，而是硬中断绑死在 CPU0 后，软中断只能跟着跑。软中断本身不绑定设备，它只是硬中断的“下游搬运工”。

验证步骤：

• 运行 cat /proc/interrupts | grep -E "(eth|enp|ens)"，看网卡行（如 45: 1234567 0 0 0 eth0-rx-0）是否所有计数全挤在 CPU0 列
• 查网卡队列数：ethtool -l eth0，若 Combined: 1，说明硬件只开了 1 个接收队列，再怎么调亲和性也没用
• 确认 RPS 是否关闭：cat /proc/sys/net/core/rps_cpu_mask 输出为空或 00000000，表示软中断无法跨核迁移

查不到设备名？用 /proc/interrupts 反推哪个网卡在刷 NET_RX

/proc/softirqs 不带设备名，但硬中断行末尾有 eth0-rx-0、enp3s0f1-tx-1 这类标识。这才是定位源头的关键。

操作链路：

• 先用 grep -E "(eth|enp|ens)" /proc/interrupts 找出所有网卡相关 IRQ 行，记下编号（如 42、43、44）
• 对每个 IRQ，检查其分布：grep " 42:" /proc/interrupts，看是否集中在单一 CPU
• 交叉比对：若 IRQ 42/43/44 全属 enp0s3，且它们在 CPU0 的增长速率与 /proc/softirqs 中 CPU0 的 NET_RX 增速高度一致，基本可锁定

更准的方法是用 perf record -e irq:softirq_entry --filter "vec == 3" -C 0 -g -- sleep 5，然后 perf report | grep net_rx_action，看调用栈里是不是来自 enp0s3 的驱动函数。

别碰 netdev_budget，除非你已配好 RPS 和多队列

net.core.netdev_budget 默认 300，调大只会让单次 net_rx_action 占用 CPU 时间片更长，加剧抖动。它不是“清得快”，而是“卡得久”。

真实生效前提：

• 网卡已开多队列：sudo ethtool -L eth0 combined 4（设为物理核数）
• RPS 已启用：echo ff > /proc/sys/net/core/rps_cpu_mask（8 核系统）
• 配套增大缓冲：echo 5000 > /proc/sys/net/core/netdev_max_backlog

单独改 netdev_budget 而不做以上三步，等于把丢包压力转成延迟压力，业务响应会更不可控。

本篇关于《Linux软中断查看与网卡优化技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！