直接看/proc/net/softnet_stat可快速定位软中断丢包，关键看每CPU第1列（processed）是否平稳增长、第2列（dropped）是否非零且持续阶梯式上涨，并结合硬中断分布、netdev_budget及RSS配置综合判断丢包根源。
直接看 /proc/net/softnet_stat 能快速定位软中断处理不及时引发的突发丢包，关键不是看“有没有丢”，而是看“谁在丢、怎么丢、为什么持续丢”。
/proc/net/softnet_stat 前两列是诊断核心
每行对应一个 CPU（行号 = CPU 编号），重点关注：
- 第 1 列（processed）：该 CPU 成功入队并处理的包数。应平稳增长，增速反映真实收包压力。
-
第 2 列（dropped）：因
input_pkt_queue满或内存不足被主动丢弃的包数。只要非零且持续上涨，就是软中断已跟不上节奏的铁证。
不要误读其他列：第 3 列（time_squeeze）反映单次软中断处理超时被迫退出；第 9 列（ksoftirqd 唤醒次数）说明 backlog 没清完需后台线程续干——它们是 dropped 的伴生指标，但 dropped 才是丢包的直接计数。
突发丢包要抓“同步阶梯式上涨”特征
执行 watch -n 1 'awk '\''{print $1, $2}'\'' /proc/net/softnet_stat' 观察秒级变化：
- 若某 CPU 的
$2（dropped）出现阶梯式跳变（如每 2–3 秒突增 500+），同时其$1（processed）增速未同步加快 → 说明软中断循环被频繁打断，budget 不足或单核过载。 - 若多个 CPU 的
$2同步上涨，且与/proc/net/dev中RX-ERR（错误帧）增长曲线高度一致 → 很可能 NIC 正在提交大量异常帧（如 CRC 错、VLAN tag 错），源头是硬件或链路问题，不是 CPU 算力瓶颈。
结合硬中断分布确认是否真“不及时”
软中断处理不及时，90% 源头是硬中断没分摊好：
- 查硬中断绑定：
grep eth0 /proc/interrupts，看各 CPU 列数值是否严重倾斜（例如 CPU0 占 95% 以上）。 - 查 IRQ 亲和性：
cat /proc/irq/*/smp_affinity_list 2>/dev/null | grep -A1 eth0，确认多队列 IRQ 是否真绑到不同 CPU。 - 若硬中断全打在 CPU0，即使 RPS 开了，
/proc/net/softnet_stat中 CPU0 的$2也会飙升，而其他 CPU 几乎为 0 —— 这不是软中断“处理慢”，而是根本没机会分过去。
验证 netdev_budget 设置是否合理
默认值 300 容易在高吞吐下触发 time_squeeze：
- 先查当前 budget：
sysctl net.core.netdev_budget - 观察
$3（time_squeeze）增速是否 >$1（processed）增速：若time_squeeze每秒涨 1000+ 而processed只涨 500，说明预算太小。 - 逐步调大测试：
sysctl -w net.core.netdev_budget=600→1200，必须同步开启网卡 NAPI 和中断合并（ethtool -C eth0 rx on tx on），否则只是让单核更忙。 - 多队列网卡还须检查 RSS：
ethtool -x eth0确认 flow hash 均匀，避免所有流都哈希到同一队列。
不复杂但容易忽略。
