软中断过高导致卡顿表现为%si持续超10%～15%、响应迟钝、网络延迟突增，但%us/%sy和负载偏低；需重点查/proc/softirqs中NET_RX、TIMER、SCHED三列是否失衡，结合/proc/interrupts与RPS配置定位单核瓶颈。
软中断过高引起的卡顿，往往表现为系统响应迟钝、网络延迟突增、top 中 %si 持续超过 10%～15%，但 %us 和 %sy 却不高，负载（load average）也偏低——CPU 看似“不忙”，实际却被内核后台任务拖住。
看 /proc/softirqs 定位主因类型
软中断不是单一行为，而是分类型的异步处理任务。最需关注三类：
- NET_RX：网络收包软中断。飙升常见于高并发短连接、SYN Flood、UDP 风暴或网卡过载
- TIMER：内核定时器软中断。异常升高可能源于驱动频繁注册微秒级定时器，或 RCU 回调堆积
- SCHED：调度器软中断。持续偏高通常指向大量短生命周期线程、cgroup 限频触发重调度
执行 cat /proc/softirqs，重点对比各 CPU 列中这三列数值。若某 CPU 的 NET_RX 值比其他核高出一个数量级（例如 500 万 vs 5 万），说明软中断严重不均衡，大概率是硬中断绑定单一 CPU 导致的“单核瓶颈”。
查硬中断分布与网卡队列配置
软中断不均，根源常在硬中断和网卡多队列策略错配：
- 运行 cat /proc/interrupts | grep eth0 查看 eth0 相关硬中断是否集中在 CPU 0
- 执行 cat /sys/class/net/eth0/device/msi_irqs/* 确认网卡支持的 MSI-X 向量数（即硬件接收队列数），应尽量与 CPU 核数匹配
- 检查 cat /proc/sys/net/core/rps_cpu_mask 是否为空：为空表示 RPS（Receive Packet Steering）关闭，软中断无法跨核分发
RPS、RSS、XPS 配置不一致时，容易触发 soft lockup 日志（dmesg | grep watchdog），此时仅调参数无效，需统一规划队列映射关系。
调参要讲配合，不能只改 netdev_budget
net.core.netdev_budget 控制每次软中断上下文最多处理多少个包，默认 300。盲目调大（如设为 600）反而更卡：
- 它会让 net_rx_action 单次占用软中断时间过长，阻塞实时线程、调度器等关键任务
- 千兆网卡建议值 60–120，万兆网卡建议 120–240
- 必须同步调整 net.core.netdev_max_backlog（建议 ≥5000），并确保 RPS 已启用，否则只是把丢包压力转成延迟压力
交叉验证是否真由软中断拖慢业务
仅看 %si 高不够，要确认它是否实际打断了业务线程：
- 运行 perf record -e 'syscalls:sys_enter_nanosleep,irq:softirq_entry' -C 0 -g -- sleep 10
- 再执行 perf script | grep -E '(net_rx|nanosleep)'
若大量 nanosleep 调用被 net_rx_action 中断打断，且堆栈显示在 __do_softirq 中单次耗时超 1ms，才可判定软中断是真实瓶颈。
