Linux系统网络中断抖动的核心是中断不均→单核过载→协议栈处理延迟→业务响应波动，需沿硬中断→软中断→协议栈→应用链路逐层验证：查/proc/interrupts确认网卡中断是否单核集中，结合/proc/softirqs和perf top定位NET_RX软中断热点，用ss -i和tcpdump分析RTT方差与包到达离散性，调优netdev_budget并启用RPS分散负载，最后通过curl时延标准差验证业务影响。
分析 Linux 系统网络中断造成的性能抖动，核心是确认“中断是否不均 → 是否压垮单核 → 是否拖慢协议栈处理 → 是否最终表现为业务延迟波动”。不能只看 CPU 使用率或 ping 延迟，而要沿着硬中断→软中断→协议栈→应用响应这条链路逐层验证。
查硬中断分布：先看网卡中断是不是扎堆
执行 cat /proc/interrupts | grep eth0（把 eth0 换成你的实际网卡名），观察每列数字——如果某一 CPU 核（比如 CPU0）的计数远高于其他核（例如高出 5 倍以上），说明中断全打在它身上。这不是负载均衡，是瓶颈前兆。
进一步验证：隔 2 秒再跑一次，用 awk 计算差值，确认该核中断增长速率是否持续领先。若增长快且稳定，基本可判定为硬中断绑定失衡。
补充检查：lspci -v | grep -A 10 "Ethernet controller" 看网卡是否支持 MSI-X 多中断向量；ethtool -l eth0 查当前队列数，若显示 combined: 1，说明只有一条收发队列，天然无法分散中断。
盯软中断行为：确认是否真在“吃”CPU 时间
运行 top，按 1 显示所有 CPU 核，重点关注 %si 列。若某核 %si 长期 >10%，且和硬中断高负载的核一致，就是软中断在扛压。
更精准定位：cat /proc/softirqs，重点看 NET_RX 行各列数值。如果某 CPU 对应的 NET_RX 值比其他核高一个数量级，说明内核收包软中断集中在它身上。
交叉验证：perf top -C 0 -e irq:softirq_entry（替换 0 为高负载核号），若看到 net_rx_action 占主导，且调用栈里频繁出现 __napi_poll 或 process_backlog，说明收包处理已成热点。
看协议栈反馈：抖动是否已传导到 TCP 层
抓一个典型连接：ss -i dst 目标IP:端口，观察输出中的 rtt 和 rttvar。若 rttvar（RTT 方差）持续 >50ms，或 rtt 在几毫秒和几百毫秒间跳变，说明内核已感知链路不稳定——这很可能是中断不均导致包处理延迟不一致所致。
同步做轻量抓包：tcpdump -i eth0 'tcp and host 目标IP' -c 500 -w rx.pcap，用 Wireshark 打开后看 TCP 时序图（Time Sequence Graph）。若数据包到达时间线呈“一簇一簇”的离散分布（而非均匀间隔），大概率是中断集中引发的批量处理效应。
检查内核参数：sysctl net.core.netdev_budget。若设得过大（如 300），又没配 RPS，会导致单核长时间关中断收包，加剧抖动；建议千兆网设为 60–120，万兆设为 120–240。
验证业务影响：把中断问题和真实请求挂上钩
不要只信监控曲线。用 curl -w "@format.txt" -o /dev/null -s http://服务地址（其中 format.txt 含 %{time_total} %{time_starttransfer}），连续跑 100 次，统计响应时间标准差。若标准差 >30ms，且与高 %si 时间段强重合，就建立了因果关联。
对比实验：手动分散中断后验证效果。例如，启用 RPS：echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（f 表示前 4 个 CPU），再跑同样 curl 测试，看抖动是否收敛。
注意干扰项：若分散中断后抖动未改善，需排查是否还有其他因素耦合，比如内存换页（vmstat 1 看 si/so）、qdisc 队列积压（tc -s qdisc show dev eth0 看 drops/backlog）或应用读取 socket 过慢（ss -i 中 rmem 值长期接近 sndbuf）。
