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设置，且需 root 权限；部分驱动要求接口 down 后才能改（rx 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。
