sar -n DEV 显示 rx_fifo_errors 增长的网卡 buffer overflow 与 rx ring 增大

rx_fifo_errors 是网卡硬件接收 FIFO 溢出导致的丢包计数，增长说明数据未及被 DMA 搬运至内存即被丢弃，典型于高吞吐、中断延迟或 rx ring 不足等场景。

rx_fifo_errors 是什么，为什么它增长说明网卡丢包

rx_fifo_errors 是 sar -n DEV 输出中一个关键指标，代表网卡 FIFO（硬件接收缓冲区）溢出导致的丢包数。它不是驱动或协议栈丢包，而是数据还没进内核就已被硬件丢弃——典型表现是：业务延迟突增、TCP 重传上升，但 .netstat -s 的“packet receive errors”却没明显变化。

根本原因是：网卡收到数据帧后，先存入片上 FIFO；若 CPU 来不及通过 DMA 搬运到内存中的 rx ring，FIFO 满了就会丢弃新到的数据包，计数器 rx_fifo_errors 自增。

• 常见于高吞吐（如 >10Gbps 持续流）、低延迟场景，或中断处理被抑制（如 irqbalance 配置不当、CPU 忙于其他任务）
• 和 rx_dropped 不同：rx_dropped 多是内核 sk_buff 分配失败或 netdev backlog 溢出，而 rx_fifo_errors 是更底层的硬件级丢包
• 部分网卡（如 Intel ixgbe、i40e）可通过 ethtool -S 查看更细粒度计数，例如 rx_fifo_errors 或 rx_over_errors

怎么确认是 rx ring 太小导致 FIFO 溢出

增大 rx ring 是缓解 rx_fifo_errors 最直接的手段，但前提是当前 ring size 确实不足。不能盲目调大——过大的 ring 会增加内存占用和中断延迟，还可能触发某些驱动的 bug。

用 ethtool -g 查看当前设置和硬件上限：

ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX:	4096 TX:	4096 Current hardware settings: RX:	256 TX:	256

如果当前 RX 值远低于 Pre-set maximums，且业务流量常达线速 30% 以上，大概率是瓶颈。

• 建议初始调整为最大值的 1/2～3/4（例如上限 4096，先设 2048）
• 必须用 ethtool -G rx 设置，且需 root 权限；部分驱动要求接口 down 后才能改（ip link set eth0 down && ethtool -G eth0 rx 2048 && ip link set eth0 up）
• 修改后观察 sar -n DEV 1 中 rx_fifo_errors 是否停止增长，并用 cat /proc/interrupts | grep eth0 看对应 IRQ 是否更均匀分发到多个 CPU

增大 rx ring 后仍涨 rx_fifo_errors？检查这些点

ring size 调大不等于问题自动解决。常见漏掉的关键环节包括：

• rx-usecs 和 rx-frames 的 interrupt coalescing 设置过激（如 ethtool -C eth0 rx-usecs 50），导致中断太稀疏，DMA 搬运滞后，FIFO 还是会满
• CPU 绑定不合理：网卡 IRQ 只绑在单个 CPU，而该 CPU 正在跑高优先级任务（如实时进程、大量 softirq），无法及时处理 NAPI poll
• NUMA 不匹配：网卡在 node 1，但 rx ring 内存分配在 Node 0，DMA 访问跨 NUMA，延迟升高
• 驱动未启用 RSS（Receive Side Scaling）：多队列网卡只用了 1 个 RX queue，所有流量挤在一个 ring 上，再大也扛不住

验证 RSS 是否生效：ethtool -l eth0 看 Current hardware settings 下 RX 队列数是否 >1；再用 cat /sys/class/net/eth0/device/sriov_numvfs（如为 0）排除 SR-IOV 干扰。

为什么有些场景调大 rx ring 反而让 rx_fifo_errors 更快上涨

这不是反直觉，而是暴露了更深层的资源错配。典型情况是：

• ring size 从 256 扩到 4096，但 net.core.netdev_max_backlog 仍为默认 1000，导致 softnet backlog 溢出，引发 NAPI_POLL 被延迟调度，反而拉长了 ring 清空周期
• 启用了 Generic-receive-offload (GRO)，但 net.ipv4.tcp_rmem 太小，导致 GRO 合并后的巨型帧在 socket buffer 拥塞，阻塞整个 RX path
• 应用层收包太慢（如单线程 recvfrom 循环 + 高延迟处理逻辑），ring 再大也只是把丢包点从硬件 FIFO 推迟到内核 socket buffer，最终仍体现为 rx_fifo_errors（因 backlog 积压 → NAPI 停止 poll → ring 满 → FIFO 溢出）

此时真正要调的是 net.core.netdev_max_backlog、net.core.somaxconn、甚至应用层的并发模型，而不是继续堆大 rx ring。