要看/proc/softirqs里NET_RX是否真在飙高，需用watch -n 1 'grep NET_RX /proc/softirqs'观察秒级增长，单核每秒超5万次即属异常；同时联动检查TIMER/SCHED是否同步飙升，并结合/proc/interrupts确认硬中断是否集中于同一CPU及网卡多队列与RPS配置状态。
怎么看 /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 而不做以上三步，等于把丢包压力转成延迟压力，业务响应会更不可控。
