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

作者顾望舒-334 Trae · null

网络工程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 是运行时生效，重启就丢，务必持久化，否则半夜重启后问题原样回来，排查成本翻倍。

五、边界与盲区：ethtool 看不到的三种场景（2024-10 补充）

上面这套 ethtool -S 定位法有一个隐含前提：包走到了内核协议栈。以下三种场景下，rx_missed_errors 可能恒为 0，但 P99 照样抖——这也是我后来被两次"ethtool 全绿但 P99 在抖"逼出来的教训。

5.1 SR-IOV / DPDK 硬件卸载：计数器在用户态，ethtool 看不到

如果业务用了 SR-IOV VF 或 DPDK 把收包路径完全绕开内核（用户态轮询），那 ethtool -S eth0 看到的计数器反映的是 PF（物理函数） 的统计，VF 上的丢包要查 VF 自己的接口：

# 确认 VF 接口名（通常形如 enp2s0f0v0）
$ ip link show | grep -i vf
# VF 侧独立统计
$ ethtool -S enp2s0f0v0 | grep -E 'drop|miss|fifo'

更隐蔽的是：DPDK 应用自己维护的 rte_eth_stats() 里的 ipd（implied packets dropped）才是真实丢包数——这个计数器在 ethtool 里完全不可见。我们线上一个 DPDK 转发节点，ethtool -S 的 rx_missed_errors 恒为 0，但 DPDK 自己的 ipd 每秒涨 200~500。如果你们用了 DPDK 但监控只盯了 ethtool，等于没监控。

5.2 跨 NUMA 的 softirq 调度：不丢包，但延迟翻倍

10G 线速下每包约 950ns（约 1.28M pps），一次跨 NUMA 内存访问额外加 50~100ns（我们 2-socket Xeon 实测 72ns）。如果 NIC 挂在 NUMA node 0，但 softirq 被调度到 NUMA node 1 的核上，每个包的 DMA 写入都要跨 NUMA 访问内存，单包延迟翻倍。在突发流量（TCP 重传风暴、gRPC 批量响应、Kafka 批量拉取）时，cross-NUMA 的额外延迟足以让 ring 溢出——但 rx_missed_errors 可能只涨了一点点（大部分包还是收到了），表现为 P99 长尾而非明显丢包。

检查方法：

# NIC 所在 NUMA
$ cat /sys/class/net/eth0/device/numa_node

# softirq 实际跑在哪个 CPU → 再查该 CPU 属于哪个 NUMA
$ cat /proc/softirqs | grep NET_RX
$ lscpu | grep "NUMA node"

修法：用 irqbalance 或手工把 NIC 中断绑到同 NUMA 的核上；业务线程用 numactl --cpunodebind=0 --membind=0 也绑到同侧。我们一个 2-socket 节点，光把中断从 NUMA 1 挪到 NUMA 0，P99 就从 22ms 降到 9ms，没有改任何 ring 参数。

5.3 多队列 RSS 的「队内溢出」：总和正常，单个 queue 在丢

Intel X710 / i40e 这类多队列网卡（我们这块有 8 个 RX queue），RSS 把流 hash 到不同队列。如果 hash 不均匀（大量连接集中在少数几个 flow key、或者 RSS 权重没配好），某个 queue 的 ring 可能持续溢出而其他 7 个 queue 完全正常。ethtool -S 的 rx_missed_errors 是所有 queue 的总和，看起来"只涨了一点点"，但实际是 1 个 queue 在持续丢包、其余 7 个 queue 的 0 把均值拉平了。

检查（i40e 驱动支持 per-queue 统计）：

# 看每个 queue 的独立丢包
$ ethtool -S eth0 | grep -E 'rx[0-9]+_(missed|dropped|discards)'
# 看 RSS 权重分布
$ ethtool -X eth0

如果某个 queue 的 rx_missed 远大于其他 queue（比如 queue 3 涨了 120 万、其余 7 个 queue 总共 2 万），大概率是 RSS 哈希碰撞或流集中。修法：ethtool -X eth0 equal 8 确认权重均匀，必要时换 RSS hash key（ethtool -N eth0）。我们一次排查中，queue 5 的 rx_missed 是其他 queue 的 40 倍，根因是 80% 的连接 hash 到了同一组 flow key（客户端 IP 段集中），换 hash key 后归零。

六、结论与可复用清单

当 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 看软中断是否扎堆、对应核是否被业务抢占；
[ ] 确认 NIC 和 softirq 在同一个 NUMA node（cat /sys/class/net/eth0/device/numa_node vs lscpu），跨 NUMA 就绑过去；
[ ] 多队列网卡检查 per-queue 统计（ethtool -S | grep rx[0-9]+_missed），排除 RSS 不均导致的单 queue 溢出；
[ ] 如果用了 SR-IOV / DPDK，ethtool 只看 PF，VF 和 DPDK ipd 才是真实丢包，必须分别查；
[ ] 确认业务线程 / 中断绑核是否撞车，错位就挪开；
[ ] 调优写进配置持久化，重启后复验；
[ ] 物理层用 rx_fifo_errors / rx_crc_errors 排除（这两个高才是线/网卡问题）。

一句话记忆：应用层看不见的丢包，多半丢在网卡的 RX ring 里；ethtool -S 是你唯一能直接"看见"它的位置——但前提是包走了内核，SR-IOV / DPDK / 跨 NUMA / RSS 不均这四个盲区会让你"看见了但没看见"。

2赞 0收藏 0评论 86浏览