ethtool -S 显示 rx_missed_errors 或 rx_no_buffer_count 增长的处理

12次阅读

rx_missed_errors或rx_no_buffer_count持续增长表明网卡接收队列满、内核处理不及,需调大RX Ring Buffer、启用RSS/IRQ均衡、优化内核参数并排查应用读取瓶颈。

ethtool -S 显示 rx_missed_errors 或 rx_no_buffer_count 增长的处理

ethtool -S 显示 rx_missed_errorsrx_no_buffer_count 持续增长,说明网卡接收队列已满,内核来不及处理数据包,导致丢包。这不是线缆或物理层问题,而是系统资源(CPU、内存、驱动、配置)无法跟上网络流量节奏。

检查当前接收队列深度与中断负载

这些计数器增长通常源于 Ring Buffer 不足或中断处理不过来:

  • ethtool -g ethX 查看当前 RX ring buffer 大小;常见默认值为 256,高吞吐场景下往往不够
  • cat /proc/interrupts | grep ethX 观察对应网卡中断号的触发次数,若单个 CPU 上中断过于集中(比如每秒几十万次),可能造成软中断
  • 配合 top -Hpidstat -wksoftirqd/X 线程 CPU 占用是否持续偏高

增大 RX Ring Buffer 并启用 RSS/IRQ balance

给网卡更多缓冲空间,并把负载分散到多个 CPU:

  • 执行 ethtool -G ethX rx 4096(支持的上限需查 ethtool -g ethX 的 max 值),避免频繁触发 rx_no_buffer_count
  • 确认网卡支持 RSS(Receive Side Scaling):ethtool -l ethX,若支持则启用多队列:ethtool -L ethX rx N(N 通常设为 CPU 核心数)
  • sudo sh -c 'echo "0-15" > /sys/class.net/ethX/queues/rx-0/rps_cpus' 类似方式将不同 RX 队列绑定到不同 CPU,再配合 rps_sock_flow_entriesrps_flow_cnt 调优

调优内核网络参数与驱动行为

减少协议处理延迟,提升整体吞吐能力:

  • 增大 socket 接收队列:net.core.rmem_maxnet.core.netdev_max_backlog(例如设为 262144 或更高)
  • 关闭低效特性:如非必要,禁用 rx offloadethtool -K ethX rx off),某些老旧驱动在开启 LRO/GRO 时反而加剧 buffer 压力
  • 检查驱动版本和固件:过旧的 ixgbe、i40e、mlx5 驱动可能存在 ring refill 效率问题,升级到厂商推荐版本常能缓解

定位是否是应用瓶颈或突发流量冲击

排除硬件和驱动后,关注上层是否“拖慢”了接收路径:

  • 运行 ss -i 查看应用 socket 的 rcv_space 是否长期接近 0,说明用户态读取太慢(如进程阻塞、未及时 recv()
  • tcpdump -i ethX -w cap.pcap 抓包比对:如果抓包看到大量重复 ACK 或 retransmit,但 rx_missed_errors 也在涨,大概率是软中断或协议来不及处理
  • 监控流量模式:用 iftop -Pvnstat 确认是否周期性突发(如备份、日志推送),可考虑限速或错峰

不复杂但容易忽略:这类丢包不会报 link down,也不会出现在 ifconfig 的 errors 字段里,必须依赖 ethtool -S 主动观测。关键是在 buffer 耗尽前,让数据流、中断、CPU、内存四者节奏对齐。

text=ZqhQzanResources