ethtool -S 里的 rx_missed_errors：收包队列溢出导致的 P99 抖动，一条命令就能定位

作者顾望舒-334

网络工程ethtoolrx_ringsoftirq可观测性

结论先行：「应用侧看不到丢包、ping 也正常、带宽也没跑满，但 P99 每隔几分钟抖一次」——十有八九是网卡 RX ring buffer 溢出了。内核把环里没来得及取的包直接丢掉（rx_missed_errors / rx_dropped），这类丢包不会出现在应用层任何 socket 统计里，ss -ti 的 rto 也完全正常，因为它根本不是 TCP 重传。下面是一次真实排查，以及一套可复现的定位与加固动作。

一、现象：P99 每 5 分钟抖一次，所有常规指标都"正常"

我们一条 10G 内网链路（Linux kernel 5.15 / 双口 Intel X710，驱动 i40e 2.8），承载一个日志采集网关，常态 QPS 约 1.8w，P50 稳定在 6ms。但监控里 P99 每隔 4~6 分钟就尖刺到 40~60ms，持续 200~400ms 回落。

诡异的地方在于，我把能看的都看了，全是绿的：

ping 对端 1ms 稳定，无丢包；
iperf3 单向打满 9.6Gbps，吞吐没问题；
应用侧 ss -ti 里 rto、retrans 全 0；
网关 CPU 整体负载 0.4，内存充足；
交换机端口 ifInErrors、ifInDiscards 都是 0。

按常规思路（带宽、链路、TCP 重传）全查一遍都指向"网络没问题"。但 P99 确实在抖，说明丢包发生在某个不被上面任何一条指标覆盖的位置。

二、根因：RX ring 太小 + 软中断抢占，内核"静默丢包"

关键转折是去看网卡自己的计数器，而不是交换机或应用：

$ ethtool -S eth0 | grep -E 'drop|miss|fifo|ring'
     rx_missed_errors:      18423911      # 关键：收包环溢出
     rx_dropped:            18423911
     rx_fifo_errors:              37
     rx_out_of_buffer:      18423948

rx_missed_errors 累计 1800 万，和 P99 尖刺的次数几乎完全对得上。机制是这样的：

网卡收到帧后先放进硬件 RX ring（默认 256 个描述符）；
内核 softirq（NET_RX）负责从环里取包、走协议栈；
一旦某个 CPU 被业务线程抢占（比如 GC、计算密集任务），softirq 响应变慢，环被写满；
环满了，新到的帧没有地方放，网卡直接丢弃——这一步发生在 sk_buff 还没建立之前，所以 ss、netstat、应用层统统看不见。

rx_out_of_buffer（18423948）比 rx_missed_errors 还多，印证了是"缓冲跟不上"而非"物理坏帧"（rx_fifo_errors 只有 37，基本可排除线速/信号问题）。

三、具体做法：先定位，再加固

第一步：确认是不是 ring 溢出（30 秒）

$ ethtool -g eth0
Ring parameters for eth0:
RX:     256          # 当前值，偏小
RX Max: 8192
TX:     256

第二步：把 RX ring 调大（立即见效，可回滚）

# 调到 8192（该网卡上限）
$ sudo ethtool -G eth0 rx 8192 tx 8192
$ ethtool -g eth0 | grep RX
RX:     8192

第三步：把软中断打散，别让它挤在少数几个核上

# 看当前 softirq 分布
$ cat /proc/softirqs | grep NET_RX
# 观察哪些核 CPU 高
$ mpstat -P ALL 1 3

如果发现 NET_RX 集中在 2~3 个核且这几个核 load 高，用 irqbalance 或手工绑中断：

# 确认中断号
$ grep eth0 /proc/interrupts
# 把该网卡的 NAPI/MSI-X 中断分散到一组 CPU（示例：12-23）
for cpu in 12 13 14 15 16 17 18 19 20 21 22 23; do
  echo $cpu > /proc/irq/$(grep -n 'eth0' /proc/interrupts | awk -F: '{print $1}' | head -1)/smp_affinity_list
done

第四步：持久化（写进 rc 或 systemd 单元）

# /etc/sysconfig/network-scripts/ifcfg-eth0 追加（RHEL 系）
ETHTOOL_OPTS="ring rx 8192 tx 8192"

验证：重启压测后复看计数器增长速率

$ watch -n 5 "ethtool -S eth0 | grep rx_missed"

调优后 30 分钟内 rx_missed_errors 增量从 ~1800/s 降到 0，P99 尖刺消失，稳定回 8ms。

四、踩过的坑 / 反直觉之处

别只看 ping 和 iperf：这俩走的是"单流、无竞争"路径，几乎永远正常；ring 溢出是多包突发 + softirq 被抢占才触发的，单流压测根本复现不出来。
rx_dropped 和 rx_missed_errors 别混：前者是"进环但没被取走"，后者是"环满了直接丢"，两者都指向 ring/softirq，但 rx_fifo_errors/rx_crc_errors 才是物理层问题——我一开始差点往重插网线方向查，rx_fifo_errors 只有 37 才把我拉回来。
ethtool 调大 ring 不是万能的：如果根因是 CPU 被抢占（GC / 线程绑核撞车），ring 再大也只是把尖刺从"丢包"推迟成"排队延迟"。我们后来发现真正的触发器是业务线程恰好绑在了跑 NET_RX 的核上，把业务线程挪开之后，尖刺才彻底归零——ring 是止血，绑核错位才是病根。
ethtool -G 是运行时生效，重启就丢，务必持久化，否则半夜重启后问题原样回来，排查成本翻倍。

五、结论与可复用清单

当 P99 间歇抖动、但 ping / 带宽 / TCP 重传 / 应用层全绿时，优先查网卡自身计数器，按这个顺序：

[ ] ethtool -S <iface> 看 rx_missed_errors / rx_out_of_buffer 是否在涨（涨 = ring 溢出）；
[ ] ethtool -g <iface> 看 RX ring 是否偏小（很多默认 256），能调大就调大；
[ ] cat /proc/softirqs | grep NET_RX + mpstat -P ALL 看软中断是否扎堆、对应核是否被业务抢占；
[ ] 确认业务线程 / 中断绑核是否撞车，错位就挪开；
[ ] 调优写进配置持久化，重启后复验；
[ ] 物理层用 rx_fifo_errors / rx_crc_errors 排除（这两个高才是线/网卡问题）。

一句话记忆：应用层看不见的丢包，多半丢在网卡的 RX ring 里；ethtool -S 是你唯一能直接"看见"它的位置。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。