软中断（si）过高是典型隐藏瓶颈，需先用cat /proc/softirqs定位net_rx等异常类型，再结合/proc/interrupts、msi-x队列数、rps配置及perf交叉分析，确认单核瓶颈根源并成套调参。

CPU 中断数过高，尤其是软中断（si）或硬中断（hi）持续偏高，常表现为单核 CPU 被“吃满”、业务延迟抖动、P99 毛刺明显，而整体 CPU 使用率却不高——这是典型的“隐藏瓶颈”。排查不能只看 top 的总百分比，得层层下钻，从现象定位到硬件队列与内核调度逻辑。

看清楚是哪类中断在飙升

先确认问题类型，避免误判：

• 运行 cat /proc/softirqs，重点关注三列：NET_RX（网络收包）、TIMER（定时器）、SCHED（调度器）。若某 CPU 核对应 NET_RX 值比其他核高出一个数量级（如 800 万 vs 8 万），基本锁定是网络软中断不均
• 运行 cat /proc/interrupts | grep -E "eth|enp"（替换为你的网卡名），观察硬中断是否全部集中在 0 号 CPU。如果 eth0-0、eth0-1 等中断号全落在 CPU0 上，说明硬中断绑定没做负载分发
• 用 top 按 1 展开所有 CPU，再观察 %si 列：若仅单核 si 接近 100%，其余核 idle 很高，就是典型的“单核软中断瓶颈”

查网卡多队列与中断亲和性是否匹配

软中断不均，根源往往在硬中断分配和网卡队列策略错配：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 查网卡支持的 MSI-X 向量数：ls /sys/class/net/eth0/device/msi_irqs/（输出多少个 IRQ 编号，就代表支持多少硬件接收队列）
• 查当前中断绑定情况：cat /proc/irq/*/smp_affinity_list | paste -d' ' - -，配合 grep eth0 找出各队列绑定的 CPU 列表
• 确保 RPS（Receive Packet Steering）已启用：cat /proc/sys/net/core/rps_cpu_mask 应为非零十六进制值（如 f 表示前 4 个 CPU 可参与软中断分发）；为空则需手动开启：echo f > /proc/sys/net/core/rps_cpu_mask

验证中断处理是否真影响业务线程

仅看 %si 高不够，要确认它是否实际抢占了关键路径：

• 用 perf 抓取软中断触发与业务休眠的交叉事件：perf record -e 'irq:softirq_entry,syscalls:sys_enter_nanosleep' -C 4 -g -- sleep 10（-C 4 指定监控 CPU4）
• 分析结果：perf script | grep -E "(net_rx_action|nanosleep)"。若大量 nanosleep 出现在 net_rx_action 调用栈中，说明网络软中断正在阻塞应用线程的调度
• 检查是否触发 soft lockup：dmesg -T | grep -i "watchdog.*hard|soft"，有日志说明中断处理已超时，内核强制 panic 防护

调参不是乱调，要配套生效

修改参数必须成套调整，否则可能恶化问题：

• net.core.netdev_budget 控制每次软中断最多处理包数，默认 300。千兆网卡建议设为 60–120，万兆设为 120–240；盲目调大（如 600）会让单次 net_rx_action 占用太久，反而卡住调度器
• 同步调大 net.core.netdev_max_backlog（建议 ≥5000），否则 budget 加大后，积压包无处暂存，直接丢弃
• RPS 必须开启，且 net.core.rps_flow_cnt 建议设为 4096，提升流哈希精度，避免不同连接被错误聚合到同一 CPU