rx_missed_errors 是网卡因处理不过来而丢弃已接收帧的计数器，反映ring buffer溢出、驱动瓶颈或硬件故障；持续增长意味着真实丢包，TCP重传掩盖问题，UDP直接丢失。
rx_missed_errors 是什么，为什么它重要
rx_missed_errors 是 ethtool -S eth0 输出中一个关键接收错误计数器，表示网卡已收到数据帧，但因驱动或硬件来不及处理而丢弃的包数量。它不反映链路层 CRC 错误或物理断连，而是典型的「处理不过来」信号——哪怕 rx_packets 看似正常增长，这个值持续上升就说明有真实丢包，且应用层可能完全感知不到（TCP 会重传，UDP 就直接没了）。
ring buffer 设置过小是最常见原因
Linux 内核通过环形缓冲区（ring buffer）暂存网卡 DMA 过来的数据帧，大小由 rx 队列长度控制。如果应用读包慢（如高吞吐下 CPU 被抢占、软中断延迟高），或 ring buffer 本身太小，新帧就会覆盖未消费的旧帧，触发 rx_missed_errors 增加。
- 用
ethtool -g eth0查看当前 rx ring 大小；多数千兆卡默认是 256，万兆卡可能为 4096，但实际往往不够 - 增大前先确认驱动是否支持：运行
ethtool -i eth0，检查driver是否为ixgbe、i40e、ice或较新atlantic；老驱动（如部分e1000e）对大 ring 支持不稳定 - 临时调大：例如
ethtool -G eth0 rx 4096；注意总内存占用 ≈rx ring size × skb buffer size（通常 2KB 左右），别设到吃光内存 - 持久化需写入 udev 规则或 systemd service，不能只靠 /etc/network/interfaces
驱动 bug 或中断处理瓶颈同样会导致该计数器上涨
即使 ring buffer 足够大，若驱动未能及时从 ring 中取走数据（比如 NAPI poll 轮询时间太短、软中断被压制、或驱动在某个路径上死锁），帧仍会被丢弃。典型表现是：rx_missed_errors 上涨的同时，rx_dropped 也同步增加，且 softirq 时间占比高（top -H 看 ksoftirqd CPU 占用 >30%）。
- 检查内核日志是否有驱动报错：
dmesg | grep -i "eth0\|napi\|ixgbe\|i40e" - 确认是否启用了 RPS/RFS：
cat /sys/class/net/eth0/queues/rx-0/rps_cpus；多队列网卡建议开启 RPS 分散软中断到多核，避免单核瓶颈 - 某些驱动版本存在已知问题（如 ixgbe 5.3.7 之前在 LRO 启用时漏处理部分帧），升级到厂商推荐驱动或主线较新内核（≥5.10）常能缓解
- 禁用 LRO/GRO 测试是否改善：
ethtool -K eth0 lro off gro off；虽然降低吞吐效率，但可排除聚合逻辑干扰
硬件层面可能性虽低但必须排除
真实硬件故障或固件缺陷也会导致该计数器异常增长，尤其在更换网卡、升级 BIOS/UEFI 或服务器电源策略变更后出现。此时往往伴随其他指标异常，比如 rx_crc_errors、rx_length_errors 同步上升，或 ethtool eth0 显示 link 反复抖动。
- 运行厂商诊断工具：Intel 网卡用
intel-nvm-update检查固件版本，执行ixgbe_diag；Mellanox 用mlxburn+mstflint - 换插槽测试：有些主板 PCIe 插槽供电或带宽不足（尤其是 x4 通道插在 x8 插槽），导致 DMA 超时
- 关闭节能特性：
echo 'performance' > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor，并禁用 ASPM：setpci -s 00:1c.0 0xa0.b=00（需根据lspci -tv找对上游桥地址） - 对比同型号网卡在另一台机器上的行为；若仅此卡异常，基本可定位硬件或固件
真正难判断的是 ring buffer、驱动和硬件问题交织的情况——比如 ring 设大了暂时压住计数器，但某次流量突发又暴涨，这时得结合 /proc/interrupts 中 eth0 对应中断号的分布、perf record -e irq:softirq_entry 抓软中断热点，再决定优先调哪一层。
