首页/资讯中心/详情

Offload flow APR GC

Offload flow APR GC
📅 发布时间：2026/6/19 16:27:03

Offload flow APR GC

下面我给你一个 精确、可落地、可以快速判断：

到底是：
（1）网卡 Offload（GRO/LRO/TSO/RXCSUM/TXCSUM）问题？
（2）Flow 流量过大（队列/CPU软中断高）？
（3）ARP GC 或邻居缓存问题？

并且告诉你 如何判断、如何复现、如何定位、如何排除。

你贴的命令：

ethtool --offload flannel.1 rx off tx off
ethtool --offload cni0 rx off tx off
ethtool --offload eno3 rx off tx off

这是企图关闭 offload 来验证，但这样做 很容易误判，因为 Linux 网络的瓶颈可能来自多层。

我下面按你的需求给你一个 精准判断流程。

✅ 一、判断是否“网卡 Offload”导致网络问题

Offload 可能导致的问题：

  • GRO/LRO 合并导致延迟（尤其 VXLAN / flannel）

  • RX/TX checksum offload 兼容性问题

  • TSO 大包导致 CPU softirq 增高

  • 某些虚拟网卡（flannel.1 / cni0）反而不能 Offload

要判断是不是 Offload 的锅，看这几个信号：

① dmesg / kernel log 出现 checksum / GRO / LRO 错误

执行：

dmesg -T | egrep -i "checksum|gro|lro|rx error|tx error|skb"

如果 Offload 出问题，会看到：

  • skb checksum error

  • hw csum failure

  • rx csum incorrect

  • netif_receive_skb_general: drop

  • gro: packet malformed

出现这些就说明 Offload 的兼容性有问题 → 就该关。

② ethtool -S 查看网卡硬件错误

ethtool -S eno3 | egrep "err|drop|fail"

关注：

  • rx_errors

  • tx_errors

  • rx_crc_errors

  • rx_no_buffer_count

  • rx_missed_errors

  • rx_length_errors

  • rx_over_errors

如果 Offload 出问题，错误计数会持续增加。

③ perf top 看 softirq 是否异常集中在 GRO/TSO

perf top

如果看到：

net_rx_action
napi_gro_receive
tcp_tso_segs
skb_gro_receive

这些异常升高 → GRO/TSO 过大包合并导致 CPU 卡死。

尤其典型于：flannel + 高 QPS + 大包。

④ 用 ethtool 关闭后问题消失 → 基本确认是 Offload

按你贴的命令：

ethtool --offload eno3 rx off tx off
ethtool --offload flannel.1 rx off tx off
ethtool --offload cni0 rx off tx off

如果关掉后：

  • ping 延迟下降

  • curl/业务延迟下降

  • softirq 下降

  • rx_errors 不再递增

→ 确认是 Offload 的锅。

❗如果关闭 Offload 后仍然卡 → 问题不在 Offload

就进入下两个判断：Flow 还是 ARP GC。

✅ 二、判断是否 Flow（流量 / QPS / CPU 软中断）问题

判断 Flow 的方法比 Offload 更直接：

① softirq（ksoftirqd）是否满 CPU

top -H -p `pidof ksoftirqd/0`

或：

mpstat -P ALL 1

如果看到：

  • 某个 CPU 的 %soft >= 50%

  • ksoftirqd 占用很高

→ Flow 过大，网卡队列打满。

② /proc/net/softnet_stat 是否丢包

cat /proc/net/softnet_stat

每一行对应 CPU，格式：

cpu0: xxx yyy zzz ...

关键字段：

  • 第 1 个字段：flow 队列满了（netdev budget exhausted）

  • 第 2 个字段：RX dropped（硬件没来得及处理）

  • 第 3 个字段：软中断丢包

如果某 CPU 某项累计增长：

→ 流量瓶颈 / RPS/RFS 不足 / bind irq imbalance。

③ 观察 RX/TX ring buffer 是否满（Flow 畸高）

ethtool -g eno3

如果 ring buffer 很小而流量很大 → 很容易丢包。

④ sar 看网络收发速率逼近网卡上限

sar -n DEV 1

如果接近：

  • 1Gbps → 950Mbps 上下

  • 10Gbps → 9.5Gbps 上下

则 Flow 过载。

⚠ 结论：

如果 softirq 高、softnet_stat 增长、sar 显示流量接近带宽 → 是 Flow 过载，不是 Offload 或 ARP。

✅ 三、判断是否 ARP GC（邻居缓存）问题

这个问题常发生在 大量 Pod 的 flannel/cni0 网段中。

典型表现：

  • ping flannel 网段偶发丢包

  • curl 某服务间歇性超时

  • dmesg 出现：

    neighbour table overflow
ARP cache full

① 查看 neighbor 缓存是否溢出

ip -s neigh

如果看到：

  • FAILED 很多

  • INCOMPLETE 很多

→ ARP 缓存不足。

② 查看是否出现 overflow 错误

dmesg | grep -i "neigh\|arp"

出现：

neighbour table overflow

→ 确定是 ARP GC。

③ 查看 neigh table 大小是否被打满

sysctl -a | grep neigh | grep gc

一般参数：

net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh2
net.ipv4.neigh.default.gc_thresh3

如果阈值偏小（例如 flannel 网段 1000+ Pod）→ neighbor 缓存经常溢出。

📌 如何区分 Flow vs Offload vs ARP？

现象Offload 问题Flow 过载ARP GC
ping 丢包 ✔ 有可能 ✔ 有可能 ✔ 经常
curl 慢 ✔（大包合并问题） ✔（软中断高） ✔（CACHE MISS）
rx_errors 增长 ✔ 多 ✖ 少 ✖
softirq 飙高 ✔（GRO爆） ✔（队列满） ✖
softnet_stat 增长 ✖ ✔ ✖
dmesg 出现 checksum error ✔ ✖ ✖
dmesg 出现 neighbour overflow ✖ ✖ ✔
关闭 offload 后改善 ✔ 必然 ✖ 无效 ✖

你只要按这个表看，就能精准判断根因。

🟦 最终如何快速判断？

执行这一套：

1. dmesg | egrep "checksum|gro|lro"
2. ethtool -S eno3 | egrep "err|drop"
3. cat /proc/net/softnet_stat
4. top -H -p $(pidof ksoftirqd/*)
5. ip -s neigh
6. dmesg | grep -i neighbor
7. sar -n DEV 1

然后用上面表格对照。

📣 如果你愿意，我可以帮你做 自动诊断脚本：

bash diagnose_network.sh

自动：

  • 判断是否 Offload 导致

  • 是否 Flow 过载

  • 是否 ARP GC 溢出

  • 是否软中断瓶颈

  • 是否 ring buffer 太小

并输出清晰诊断结果。

你需要这个吗？