结论先行：「ping 1ms 正常、iperf 带宽满、
ethtool -S全绿、ss -ti重传 0，但 P99 每 5 分钟抖到 300ms+」——如果链路是 25G 以上、节点多网卡、且业务 CPU 密集，十有八九是 softnet 软中断预算打满，包堆在了 per-CPU backlog 队列里。这类延迟既不是硬件丢包（rx_missed_errors为 0），也不是发送侧 bufferbloat，而是内核 softirq 处理带宽不够、包在软件队列里排队。下面是一次真实排查 + 可复现的定位命令 + 三档加固动作。
一、现象与背景：吞吐满格，P99 却抖到 350ms
一台 25G × 4 口的 Kafka broker 节点（Linux kernel 5.15.0-105 / 32 核 Xeon 8375C / 128G 内存），常态 P99 稳定在 8ms。
10 月 12 日凌晨 02:14，上游日志批量推送突发，网卡 eth2 的收包速率从 180k pps 飙到 1.22M pps，持续 8 分 20 秒。业务侧现象：
- P50 延迟从 3ms 涨到 11ms，P99 从 8ms 涨到 350ms，P999 到 1.4s；
ping到对端 RTT 始终 1.1ms，丢包 0；iperf3单流打满 24.7Gbps，带宽没问题；ethtool -S eth2 | grep -E 'drop|miss|fifo'：rx_missed_errors: 0、rx_dropped: 0、rx_fifo_errors: 0——硬件一层丢包都没有；ss -ti全部连接的retrans为 0，rto正常；- 交换机侧
ifInDiscards为 0。
按常理「不丢包、带宽够、TCP 没重传」就该排除了网络，但业务超时率从 0.01% 飙到 3.7%。
二、原理与根因：softirq 的"每轮预算"被吃光了
Linux 收包路径是 硬中断（NAPI poll）→ softirq（NET_RX）→ ksoftirqd（线程兜底） 三段。关键机制是内核给 softirq 每一轮都设了预算（net.core.netdev_budget 和 netdev_budget_usecs），默认值：
netdev_budget = 300 # 每轮最多处理 300 个包
netdev_budget_usecs = 2000 # 每轮最多花 2000 微秒
单核 softirq 的理论处理上限 ≈ 300 包 / 2ms = 150k pps。我们这次 eth2 到了 1.22M pps，是单核上限的 8 倍——超出的部分不会被丢，而是被塞进该 CPU 的 per-CPU backlog queue（struct softnet_data 里的 input_queue_head），等下一轮 ksoftirqd 线程来消化。
反直觉的坑在 ksoftirqd：
- ksoftirqd 是普通内核线程，默认 nice=0，优先级和用户态业务线程一样。业务 CPU 一忙（我们这次 Kafka 的 segment flush 正好跑在 CPU 22 上，而 eth2 的 irq 也绑在 CPU 22），ksoftirqd 就被抢占，backlog 越堆越深。
- softirq 只跑在 irq 绑定的那一个核上。32 核机器上，eth2 的 1.22M pps 全压 CPU 22 一个核，其他 31 个核闲置。
- backlog 堆积 = 纯排队延迟。和 bufferbloat（发送侧队列）不同，这里是接收侧软件队列——包已经到了内核，但没来得及上送 socket。排队时间全部折算成了应用看到的 RTT。
实测对得上：backlog 峰值深度 2.4M 包 × 1514 字节 ≈ 3.6GB，按 25Gbps 折算排队延迟 ≈ 1.16 秒，和 P999 的 1.4s 完全吻合。
三、具体做法：三条命令定位 + 三档加固
3.1 定位（30 秒内）
# 1) 看每个 CPU 的 softnet 统计（drop 列 >0 就是 backlog 溢出）
awk '{printf "cpu%d: processed=%s dropped=%s time_squeeze=%s\n", NR-1, $1, $2, $3}' /proc/net/softnet_stat
# 我们看到的 CPU 22：dropped=2418392、time_squeeze=18344（关键！）
# 2) 看 NET_RX softirq 分布（集中在哪个核）
cat /proc/softirqs | grep -E '^\s*CPU|NET_RX'
# CPU22: NET_RX=84723190（其他 CPU 都是 0）
# 3) 看每个核的 %soft 占比
mpstat -P ALL 1 5 | awk '$9 ~ /[1-9]/'
# CPU22 %soft=94.2%（其他核 %soft 全 0）
三个信号同时亮：drop > 0 + softirq 单核 + %soft 打满 → 100% 是 softnet 预算问题。
3.2 加固（按优先级）
档位 A：RPS 散核（立竿见影，5 分钟）
# 把 eth2 的收包处理散到 CPU 20-27 共 8 个核
echo f0 > /sys/class/net/eth2/queues/rx-0/rps_cpus # 1111 0000 = CPU 20-23
echo f0 >> /sys/class/net/eth2/queues/rx-1/rps_cpus
# 实测：P99 从 350ms 回到 12ms，softnet drop 增速降到 1/20
# 注意：RPS 会引入 IPI 开销，散核数别超过 16
档位 B：irqbalance 或手动绑核（治本）
# 方案 1：装 irqbalance（多网卡场景推荐）
systemctl enable --now irqbalance
# 方案 2：手动把 eth2 的 irq 绑到业务不用的核
echo 24 > /proc/irq/$(cat /proc/interrupts | grep eth2 | awk '{print $1}' | tr -d ':')/smp_affinity
档位 C：调 netdev_budget（治标，慎用）
# 把单轮预算从 300 提到 3000（10 倍）
sysctl -w net.core.netdev_budget=3000
sysctl -w net.core.netdev_budget_usecs=8000
# 风险：softirq 占用 CPU 时间变长，业务线程被挤压
# 只在 RPS 散核后仍不够时才用，且要配合业务线程 SCHED_FIFO
3.3 监控（长期）
# 每 10 秒采一次 softnet drop 增速，> 1000/s 告警
prev=$(awk '{s+=$2} END{print s}' /proc/net/softnet_stat)
sleep 10
curr=$(awk '{s+=$2} END{print s}' /proc/net/softnet_stat)
rate=$(( (curr - prev) / 10 ))
[ $rate -gt 1000 ] && alert "softnet drop rate ${rate}/s"
四、踩过的坑 & 反直觉
ethtool -S全绿是最大的误导。这次rx_missed_errors=0，因为包没被硬件丢——是内核自己排队了。硬件计数器和软件 backlog 是两套独立的丢包/延迟信号，必须分开看。- ping 永远测不出 backlog 延迟。ping 是 56 字节的少量包，触发不了 softnet 预算上限；只有持续的 1M+ pps 大包流才会暴露。
ss -ti的 retrans 永远为 0。包没丢、ACK 正常回，TCP 层根本感知不到应用侧的排队延迟——这是内核内部的延迟，不在 TCP 状态机里。- 反直觉：ksoftirqd 优先级比用户态线程还低。内核默认
ksoftirqd是 SCHED_NORMAL、nice=0，业务线程一忙就把它抢走。如果你的业务是 CPU 密集 + 高 pps 收包，必须用 RPS 散核，否则单核 softirq 必挂。 - 多核 ≠ 多路 softirq。softirq 默认只跑在 irq 绑定的那一个核上，32 核机器上一个核扛 1M pps 是常态。
五、结论与可复用清单
一句话根因：softnet 单核处理上限 ≈ netdev_budget / netdev_budget_usecs ≈ 150k pps，超出的包堆在 per-CPU backlog 队列里排队，排队时间全部折算成应用 P99 延迟。
可复用清单（下次遇到"P99 抖、ping 正常、硬件不丢包、TCP 不重传"，按这个顺序查）：
cat /proc/net/softnet_stat→ 看 drop 列是否 > 0cat /proc/softirqs | grep NET_RX→ 看是否集中在单核mpstat -P ALL 1 5→ 看那个核的 %soft 是否 > 80%- 三个信号同时亮 → 上 RPS 散核（
rps_cpus），5 分钟见效 - 长期：装 irqbalance + softnet drop 增速监控
参数速查：
| 参数 | 默认 | 建议 | 风险 |
|---|---|---|---|
| netdev_budget | 300 | 300~3000 | 调大挤压业务 CPU |
| netdev_budget_usecs | 2000 | 2000~8000 | 同上 |
| rps_cpus | 单核 | 散 4~16 核 | IPI 开销 |
和相邻问题的区分：
- bufferbloat（发送侧队列）：看
tc -s qshow，解法fq_codel； - rx_missed（硬件 ring 溢出）：看
ethtool -S，解法ethtool -G rx 4096； - softnet backlog（软件队列堆积）：看
/proc/net/softnet_stat，解法 RPS 散核。
三者都会导致"P99 抖、ping 正常"，但定位入口和解法完全不同，别混着调。
参考
- 顾若衡-154《带宽 100% 跑满、丢包却是 0：用 fq_codel 把排队延迟从 480ms 压回 25ms 的一次实战》——bufferbloat 的发送侧视角，与本文接收侧 softnet 互为镜像。
- 顾望舒-334《ethtool -S 里的 rx_missed_errors：收包队列溢出导致的 P99 抖动，一条命令就能定位》——硬件 ring 溢出的视角，与本文软件 backlog 互为镜像。