存储服务器大流量写入由于 Ring Buffer 设置不合理导致丢包、断流的处理

存储服务器大流量写入由于 Ring Buffer 设置不合理导致丢包、断流的处理

现象：业务使用某厂商的私有云对象存储方案来存储大量的数据，此前已有合作的成功经验，这是另外一批存储服务器组成新的对象存储集群供业务使用，像往常一样业务并发写入大量的数据时，出现了丢包、断流的情况，严重影响业务的正常运行。

发生故障时，登录某个存储服务器上 node1 上：

• 存储服务器与业务的服务器都是“电口” + “光口”的模式，电口（万兆）用于非存储行为小流量，光口（10G-25G）用于存储行为大流量。
• 这个不一定总是 node1，其它节点也会出现类似问题，比如 node2 或 node30。
• 在该节点上 ping 其它节点的 IP 地址（本文说的 IP 地址均指光口的地址），部分节点的 IP 地址可以 ping 通，部分节点的 IP 地址无法 ping 通，并且相隔时间很短的情况下，ping 同一个 IP 地址会出现通和不通两种情况。

• 查看多个节点的监控，系统负载正常，防火墙并无任何策略，也没有开启 selinux 等安全机制，在高峰写入时出现不确定节点、不规律地出现节点断流的情况。
• 查看整个集群的统计监控，集群总流量未达到上层交换机 100G 的阈值，有大量的重传。

接下来分析、排查一下，涉及的知识仅供参考，不一定对。

网络包的流转

网络包的接收流程是 “硬件（网卡）-> 内核空间（协议栈/缓冲区）-> 用户空间（应用）” 的逐层流转，每个环节都有核心配置项影响收发效率，且可能成为丢包点。

核心流转路径：

网卡硬件接收 -> 网卡预处理（校验 + 过滤） -> DMA 传输写入 RX Ring -> 网卡触发“接收完成中断（RX IRQ）” -> 内核硬中断处理（最小化核心操作） -> 数据包放入“对应 CPU 的 netdev_max_backlog 队列” -> 软中断（ksoftirqd 线程）唤醒处理 -> 内核协议栈逐层解析（L2->L3->路由->L4->netfilter） -> 匹配目标 socket，放入 socket 接收缓冲区（sk_receive_queue） -> 应用通过 recv()/read() 系统调用读取（用户空间拷贝）

• 网卡硬件接收
  • 网卡物理层接收电信号/光信号，转换为二进制网络帧（Ethernet 帧），此时帧还未做任何校验。
• 网卡预处理（校验 + 过滤）
  • CRC 校验：网卡硬件自动校验帧的 CRC 字段，确认帧在传输过程中未被篡改（校验失败直接丢弃，不进入后续流程，计数到 rx_crc_errors）。
  • 帧过滤：按配置过滤无效帧（如 MAC 地址过滤、VLAN 标签过滤），只保留目标为本机的帧（过滤失败直接丢弃，计数到 rx_dropped）。
  • 帧长度检查：判断帧长度是否符合 Ethernet 标准（64-1518 字节，超范围则标记为 rx_over_errors 或 rx_frame_errors）。
• DMA 传输写入 RX Ring
  • DMA（直接内存访问）无需 CPU 参与，直接将网卡缓冲区的帧写入“内核态的 RX Ring 缓冲区”。
    • RX Ring 缓冲区是由网卡驱动在内存中创建的“环形队列”（物理上由网卡硬件寄存器 + 内核态内存共同构成），大小可通过 ethtool -G 调整。
  • RX Ring 有固定容量（默认 256/512），若帧到达速度超过后续处理速度，会触发 overrun 错误。
• 网卡触发“接收完成中断（RX IRQ）”
  • DMA 写入完成后，网卡向 CPU 发送“接收完成中断”，通知内核 “有新包待处理”。
  • 可配置“中断合并（Interrupt Coalescing）”：累计一定数量/时间的包后再触发中断（减少 CPU 上下文切换，高流量场景推荐开启，通过 ethtool -C 配置）。
• 内核硬中断处理（最小化核心操作）
  • 最小化处理：仅标记数据包在 RX Ring 中的位置，不进行复杂解析（如校验帧头），更新网卡统计（如 rx_packets 计数）、唤醒软中断（NET_RX_SOFTIRQ）。
  • 快速释放 CPU：避免硬中断占用太久，导致其他任务延迟。
  • 唤醒软中断：将处理任务交给软中断处理，由 ksoftirqd 线程处理。
• 数据包放入“对应 CPU 的 netdev_max_backlog 队列”
  • 硬中断处理完成后，将包封装为 skb（socket buffer，内核中描述数据包的核心结构体）。
  • 放入“当前 CPU 对应的 netdev_max_backlog 队列”（非全局队列！每个 CPU 独立队列，大小由 net.core.netdev_max_backlog 配置）。
  • 队列满则丢弃新包（计数到 rx_dropped）。
• 软中断（ksoftirqd 线程）唤醒处理
  • 硬中断唤醒软中断后，由内核的 ksoftirqd 内核线程（每个 CPU 一个）处理软中断。
  • 核心动作：从 RX Ring 读取 skb、剥离 L2 帧头（Ethernet 头）、将 skb 提交到内核协议栈。
  • 软中断优先级低于硬中断，但高于普通应用线程（可通过 chrt 调整优先级，避免被应用抢占）。
• 内核协议栈逐层解析（L2->L3->路由->L4->netfilter）
  • L2 解析：剥离 Ethernet 头，提取源/目的 MAC、协议类型（如 IPv4/ARP）。
  • L3 解析：剥离 IP 头，提取源/目的 IP、协议类型（如 TCP/UDP），执行路由判断（确认包是本地接收还是转发）。
  • netfilter 过滤：经过 iptables/ip6tables 规则链（raw -> mangle -> filter），若被规则 DROP，直接丢弃（计数到 rx_dropped）。
  • L4 解析：剥离 TCP/UDP 头，提取源/目的端口，通过“四元组（源 IP: 端口 -> 目的 IP: 端口）”匹配对应的 socket。
• 匹配目标 socket，放入 socket 接收缓冲区（sk_receive_queue）
  • 找到对应的 socket 后，将 skb 放入 socket 的“接收缓冲区（sk_receive_queue）”。
  • 缓冲区大小受双重限制：内核全局配置（net.core.rmem_default/net.core.rmem_max）+ 应用层配置（SO_RCVBUF 选项），两者取最小值。
  • 若缓冲区满（应用未及时读取），新包会被丢弃（计数到 rx_dropped），触发 TCP 窗口关闭（对端停止发送数据）或重传。
• 应用通过 recv()/read() 系统调用读取（用户空间拷贝）
  • 应用调用 recv()/read() 后，内核将 sk_receive_queue 中的数据从“内核态拷贝到用户态”（若开启 MSG_ZEROCOPY 可避免拷贝，存储场景推荐开启）。
  • 读取模式：
    • 阻塞模式：若缓冲区无数据，应用会阻塞等待。
    • 非阻塞模式：无数据则返回 EAGAIN，需配合 epoll/kqueue 事件驱动（存储集群高并发场景必用）。
  • 应用读取后，内核会清理 socket 缓冲区，释放空间接收新包。

网络问题的简单排查思路

看完上面网络包的流转，网络问题的排查大致是这样：

硬件层检查：

• 检查物理连接（网线、交换机端口、网卡指示灯）。
• 检查网卡健康状态，比如使用 ethtool 来查看网卡配置、统计信息。
• 验证交换机端口配置（速率、双工、MTU、VLAN）。
• 执行硬件自测试（若支持）。

链路层检查：

• 检查系统日志查看网卡驱动状态。
• 验证 MTU 配置（确保全网一致）。
• 检查 VLAN 配置（VLAN ID、802.1Q 支持）。
• 确认链路聚合状态（Bond）。

网络层检查：

• 查看路由表（确认默认路由和可达性）。
• 检查防火墙规则（iptables/nftables 规则）。
• 验证 IP 地址配置（IP、子网掩码、网关）。
• 检查 ARP 和邻居表。

传输层和应用层检查：

• 优化 TCP 参数（缓冲区、拥塞控制）。
• 检查端口状态（监听、占用、连通性）。
• 分析应用层协议（使用 Wireshark/tcpdump）。
• 查看应用程序日志。

性能监控和分析：

• 监控网络流量（nload、iftop）。
• 查看系统资源使用（top、htop）。
• 分析丢包统计（netstat -s、ethtool -S）。
• 进行网络性能测试（iperf3、netperf）。

上面的看着有点晕是吧，先来一个简单的思路（使用的工具或者关注的指标不限于提示的这些，仅供参考）：

• 先看监控告警：确认丢包现象（如业务超时、ping 丢包、接口错误率高），缩小影响范围（单服务器/全集群）。
• 网卡层快速排查：ip -s link 看 rx_dropped/errors，ethtool -S eth0 看详细统计，排除硬件/速率问题。
• 内核层排查：top/mpstat/vmstat 看 CPU 负载（sy、si 等），/proc/net/softnet_stat 看软中断丢包，ss -s 看 TCP 队列丢包，若涉及 IO 等待的问题还会用到 iostat 等工具。
• 应用层排查：ss -plnt 看 Recv-Q，strace -p pid -e recv,read 跟踪应用读取行为，排查应用逻辑问题。
• 抓包验证：用 tcpdump 之类的工具抓包，确认丢包环节。
• 配置优化：根据排查结果调整对应配置（如增大缓冲区、开启多队列、优化应用读取策略），验证效果。

查看网卡统计（重点看 rx 相关错误）：

# 查看速率、双工、自动协商状态
ethtool eth0# 查看 RX Ring 大小
ethtool -g eth0# 查看网卡中断是否集中在单个 CPU（中断风暴：某 CPU %sy 高）
cat /proc/interrupts | grep eth0# 查看统计
# rx_dropped（缓冲区满丢包）、rx_errors（硬件系列错误如 rx_crc_errors）、rx_over_errors（帧过长，也就是 overrun）、rx_fifo_errors（FIFO 缓冲区满）、rx_missed_errors（未及时处理的数据包）
ip -s link show enp0s8
ethtool -S eth0# 查看网络接口统计
cat /proc/net/dev | column -t
netstat -i | column -t

ip -s link show enp0s8 中 RX/TX 错误计数是“网卡硬件 + 驱动程序 + 内核网络子系统”共同维护的，每个字段对应特定的故障场景：

• RX（接收方向）错误
  • errors
    • 接收过程中“数据包本身无效”或“硬件/驱动故障”导致无法接收的总错误数（汇总类字段）。
    • 包含以下子错误（需用 ethtool -S enp0s8 看细分）：
      • CRC 校验失败（帧完整性损坏）。
      • 帧长度异常（小于 64 字节/大于 MTU）。
      • 帧对齐错误（数据字节不对齐）。
      • 接收超时（硬件等待数据超时）。
      • overrun 超限错误（子错误之一）。
    • 网卡接收数据包时，硬件会自动校验帧的 CRC、长度、对齐性。
      • 若校验失败，硬件标记该帧为“无效”，并将 RX_ERR 寄存器 +1。
      • 驱动处理接收中断时，读取 RX_ERR 寄存器，同步到内核 stats.rx_errors。
      • 无效帧会被硬件直接丢弃，不会进入内核缓冲区。
  • dropped
    • 接收过程中“数据包本身有效”，但由于资源（比如内存）不足/配置限制等系统原因，导致在拷贝到内存的过程中被丢弃的总错误数（汇总类字段）。
    • 触发场景：
      • 网卡 RX Ring 缓冲区满（硬件缓冲区，DMA 写入的地方）。
      • 内核 netdev_max_backlog 队列满（硬中断 -> 软中断的临时队列）。
      • RPS 队列满（软件负载均衡的队列）。
      • 配置过滤规则（如 VLAN 过滤、网卡 MAC 过滤）拒绝接收。
      • 内核协议栈资源不足（如 socket 缓冲区满但应用未读取）。
    • 统计逻辑：
      • 数据包已被网卡硬件正确接收（CRC/长度/对齐均正常，所以 errors 不 +1）。
      • 驱动/内核尝试处理时，发现无可用资源（如 RX Ring 满）或不符合配置，主动丢弃该包。
      • dropped 是“能收但处理不了”，errors 是“收都收不了（包无效）”。
  • overrun
    • 接收缓冲区超限错误，属于 errors 的子错误，仅统计“硬件缓冲区满”导致的丢包。
    • 触发场景：网卡硬件接收缓冲区（RX Ring/FIFO）的“数据包写入速度”超过了“驱动程序读取速度”，导致新到达的数据包无法存入缓冲区，触发硬件层面的 “超限错误”。
    • 统计逻辑：
      • 网卡接收数据时，DMA 会持续将数据写入 RX Ring 缓冲区。
      • 若 CPU 被其他任务占用（如硬中断风暴、软中断阻塞），驱动无法及时从 RX Ring 读取数据，导致缓冲区满。
      • 新数据包到达时无可用缓冲区，网卡硬件触发“overrun 错误”，将 RX_OVERRUN 寄存器 +1。
      • 驱动同步该值到 stats.rx_over_errors，同时累加 stats.rx_errors（因为是子错误）。

overrun 增加的原因：

• 硬中断风暴（单 CPU 核心被占满）
  • 网卡未开启多队列（RSS），所有接收中断都绑定到同一个 CPU 核心。
  • 高流量场景下（如每秒 10 万 + 数据包），该 CPU 核心的“系统态 CPU（% sy）”持续 90%+，甚至被硬中断完全占满，驱动根本没有时间执行 “读取缓冲区” 的操作。
  • 验证：cat /proc/interrupts 查看网卡中断（如 enp0s8 对应的中断号），观察是否某一个中断号的计数增长极快；top -H 看对应 CPU 核心的 % sy 占比。
• 软中断阻塞/抢占
  • 驱动处理硬中断时，仅做 “标记数据包位置” 的最小化操作，后续的数据包解析依赖软中断（ksoftirqd 线程）。
  • 若软中断线程被高优先级应用/进程抢占（如 CPU 被数据库、Java 应用占满），或软中断本身负载过高（多个网卡共享一个 CPU 核心处理软中断），会导致驱动 “不敢快速读缓冲区”（怕读出来后软中断处理不了，内核队列溢出），间接导致 RX Ring 满。
  • 验证：mpstat -P ALL 1 看某 CPU 核心的“软中断 CPU（% si）”持续高；top -H 看 ksoftirqd/XXX 线程的 CPU 占用接近 100%。
• CPU 资源被非核心进程抢占
  • 生产环境中，数据库、大数据任务、挖矿程序等 “吃 CPU” 的进程，占用了大量 CPU 资源，导致驱动中断处理函数、软中断线程无法获得足够的 CPU 时间片。
  • 验证：top 查看进程 CPU 占用，若非核心进程（如非业务应用）的 % CPU 持续 80%+，且与 overrun 增长时间点吻合。
• RX Ring 缓冲区本身配置过小
  • 例如：RX Ring 大小为 256 个帧，每个帧 1500 字节（MTU=1500），缓冲区总容量仅 256*1500=384KB。
  • 高并发小数据包场景下（如每个包 100 字节），256 个帧仅能存 25KB 数据，每秒 1 万包就会占满缓冲区（10000*100=1MB/s，远超缓冲区容量），导致 overrun 增加。
  • 验证：ethtool -g enp0s8 查看 RX: max 4096, current 256

内核硬中断/软中断丢包：CPU 处理能力不足导致丢包排查：

# 查看 CPU 负载（重点看 %sy 系统态 CPU）
# 查看 ksoftirqd 线程（如 ksoftirqd/0）的 CPU 占用，若 >=80% 说明软中断压力大
top -H# 查看每个 CPU 的 %sy（系统态）、%si（软中断），若某 CPU %si 持续高，说明软中断集中在该 CPU
mpstat -P ALL 1# 查看软中断统计
# 每行对应一个 CPU，第 1 列是接收数据包数，第 2 列是丢包数（非 0 则软中断丢包）
cat /proc/net/softnet_stat# 查看中断负载
# 观察网卡中断（eth0 相关）的增长速度，若某中断号增长过快，说明硬中断集中
watch -n 1 cat /proc/interrupts

• 硬中断集中：绑定中断到空闲 CPU（echo 4 > /proc/irq/XXX/smp_affinity_list）。
• 软中断集中：开启 RPS/RFS，分散软中断到多个 CPU；提高 ksoftirqd 线程优先级。
• CPU 不足：扩容 CPU 核心，或限制非核心应用的 CPU 使用率（cpulimit -p 进程ID -l 50%）。

内核协议栈/缓冲区丢包，主要是由于转发/队列满导致：

# 查看 netfilter 丢包
# 查看各链的 DROP 计数，若有增长，说明规则丢包
iptables -L -n -v# 查看内核日志中的丢包信息（如 nf_conntrack 满导致丢包）
dmesg | grep -i "drop"# 查看连接跟踪数，对比 net.netfilter.nf_conntrack_max（满则丢包）
sysctl net.netfilter.nf_conntrack_count# 查看 TCP 统计
ss -s# 查看半连接队列丢包（如"SYNs to LISTEN sockets ignored"）
netstat -s | egrep -i "listen|syn"

• netfilter 丢包：清理冗余 DROP 规则，增大 nf_conntrack_max。
• TCP 队列丢包：增大 tcp_max_syn_backlog 和 somaxconn，同步调整应用的 backlog 参数（如 Nginx、Tomcat）。
• 内核缓冲区丢包：增大 net.core.rmem_max 和 netdev_max_backlog。

用户空间丢包：应用读取慢、socket 缓冲区过小、事件驱动模型配置不当：

# 查看应用的 socket 队列：Recv-Q（接收队列中未被应用读取的字节数），若持续非 0 且增大，说明应用读取慢
ss -plnt | grep 业务端口# 确认应用是否正常监听端口
lsof -i :业务端口# 查看应用是否频繁调用 recv/read，是否有阻塞
strace -p 应用PID -e recv,read

• 应用读取慢：优化应用逻辑（如减少数据库查询耗时、异步处理非核心流程）。
• socket 缓冲区过小：调整应用的 SO_RCVBUF 参数，确保 <= 内核 rmem_max。
• 事件驱动配置不当：改用 epoll ET 模式 + 非阻塞 socket，减少事件触发次数；增加应用工作线程数，提升并发处理能力。

我的情况是在基本可以排除物理层面的干扰后查看 overruns 和 dropped 计数时发现 overruns 的计数不断增加而且增加得很快：

for i in $(seq 1 100); do /sbin/ifconfig bond0 | grep RX | grep overruns; sleep 1; done

处理：

# 查看对应网卡的 RX buffer size ，默认的 RX buffer size 的值为 512
# 修改 RX buffer size ，提高网卡处理数据包能力，我这里的 eno1 和 eno2 是 bond0 的子接口
sudo /sbin/ethtool -G eno1 tx 2048 rx 2048
sudo /sbin/ethtool -G eno2 tx 2048 rx 2048/sbin/ethtool -g eno1
# Ring parameters for eno1:
# Pre-set maximums:
# RX:		4096
# RX Mini:	0
# RX Jumbo:	0
# TX:		4096
# Current hardware settings:
# RX:		2048
# RX Mini:	0
# RX Jumbo:	0
# TX:		2048/sbin/ethtool -g eno2
# Ring parameters for eno2:
# Pre-set maximums:
# RX:		4096
# RX Mini:	0
# RX Jumbo:	0
# TX:		4096
# Current hardware settings:
# RX:		2048
# RX Mini:	0
# RX Jumbo:	0
# TX:		2048

RX Buffer 配置持久化：

• 写到传统的开机自启配置文件中如 /etc/rc.local，个人不推荐这个。
• 写到系统的网卡配置中：
  • Centos 7.6
    • 修改 /etc/sysconfig/network-scripts/ifcfg-eno1

      ETHTOOL_OPTS="-G ${DEVICE} rx 2048 tx 2048"
      

    • 修改 /etc/sysconfig/network-scripts/ifcfg-eno2

      ETHTOOL_OPTS="-G ${DEVICE} rx 2048 tx 2048"
      

  • Ubuntu 20.04
    • 修改 /etc/udev/rules.d/59-net.ring.rules

    ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="eth*|en*", RUN+="/sbin/ethtool -G $name rx 4096 tx 4096"
    

修改后，经过持续的观察，业务的存储流量恢复正常。

overruns、dropped 计数的额外说明

再絮絮叨叨一点。

ifconfig 之类的工具从 /proc/net/dev 获取原始数据统计信息，参考 https://elixir.bootlin.com/linux/v5.4.65/source/net/core/net-procfs.c#L78：

{struct rtnl_link_stats64 temp;const struct rtnl_link_stats64 *stats = dev_get_stats(dev, &temp);seq_printf(seq, "%6s: %7llu %7llu %4llu %4llu %4llu %5llu %10llu %9llu ""%8llu %7llu %4llu %4llu %4llu %5llu %7llu %10llu\n",dev->name, stats->rx_bytes, stats->rx_packets,stats->rx_errors,stats->rx_dropped + stats->rx_missed_errors,stats->rx_fifo_errors,stats->rx_length_errors + stats->rx_over_errors +stats->rx_crc_errors + stats->rx_frame_errors,stats->rx_compressed, stats->multicast,stats->tx_bytes, stats->tx_packets,stats->tx_errors, stats->tx_dropped,stats->tx_fifo_errors, stats->collisions,stats->tx_carrier_errors +stats->tx_aborted_errors +stats->tx_window_errors +stats->tx_heartbeat_errors,stats->tx_compressed);
}

• errs（Errors）
  • 表示总的收包的错误数量，这包括 too-long-frames 错误、 Ring Buffer 溢出错误、 crc 校验错误、帧同步错误、 fifo overruns 以及 missed pkg 等等。
    • 大多数情况下，rx_crc_errors 计数增加意味着问题在网络模型的第一层即物理层，当网卡接口接收到一个数据包时，它要经过一个数据完整性检查，称为循环冗余检查，若该数据包在检查中失败则会被标记为 rx_crc_errors，按照我自己的经验来看，若网卡配置在半双工模式下工作会导致这个错误计数增加，通常设置交换机告诉对端网卡在全双工模式下工作能解决这个问题。
• drop（Dropped）
  • 表示数据包已经进入了 Ring Buffer ，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
  • 不过需要注意的是，版本 2.6.37 之前的内核，比如当出现不支持的 protocol 时，内核会简单地 drop 掉，并不会增加 dev->stat.dropped 字段的计数，但是从 2.6.37 开始这种数据包也会统计到 dev->stat.dropped 中。
  • 另外 dropped 的计数也跟做了 bonding 的网卡的绑定模式有关，有时候看到计数增加，这并不是一个 bug，绑定模块丢弃在非活动接口接收到的重复帧是正常的，这个东西在排查过程中也会造成一定的干扰，比如若 eth0 和 eth1 都连到 bond0，看到 bond0 上 dropped 的计数一直有增加，但是 eth1 没有增加，要确认这个是否正常的步骤：
    • 使用命令 cat /sys/class/net/bond0/bonding/active_slave 来确认当前活跃的接口是哪个，比如目前是 eth0。
    • 若 eth0 的 dropped 计数没有增加，而非活动的 eth1 的 dropped 计数在增加，而且绑定配置为 active-backup 模式（或者其它会有一个非活动接口的模式），那么这个是正常的。
      • 默认情况下 /sys/class/net/bond0/bonding/all_slaves_active 的值为 0 ，即意味着非活动接口会丢弃数据帧，若设置为 1 的话则会避免这一问题。
    • 若 eth0 和 eth1 的计数均没有增加，那么得考虑是否其它的因素如错误的 vlan tag 导致的，同时若 bond0 上 dropped 的计数增加的比较慢，使用 tcpdump 对 bond0 抓包却发现计数不会增加的话，可以认为无影响。
• fifo（Overruns）
  • 这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer，很明显， overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，通常 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一。