偶发性丢包大概率卡在网卡驱动层：rx_over_errors上升表明Ring Buffer溢出，rx_missed_errors上升多因vCPU调度延迟或IRQ affinity不当；二者均需通过ethtool -S和/proc/net/dev秒级观测，且不会被tcpdump捕获。
偶发性丢包大概率卡在网卡驱动层，尤其是 Ring Buffer 溢出或 NAPI 调度不及时——这类丢包不会出现在 tcpdump 里，但 ethtool -S 和 /proc/net/dev 会留下明确痕迹。
看 rx_over_errors 和 rx_missed_errors 是否跳变
这两项是驱动层丢包最直接的信号：
-
rx_over_errors上升 → Ring Buffer 溢出，典型表现是网卡收包速率高、CPU 单核软中断（si）持续 >70%，且中断集中在某一个 CPU 核上 -
rx_missed_errors上升 → 虚拟机场景常见，vCPU 调度延迟导致驱动没来得及从 Ring Buffer 取包，物理机上也可能因 IRQ affinity 配置不当引发 - 注意：这些计数器只在
ethtool -S eth0或cat /proc/net/dev的Rx-OVR列体现，ifconfig已弃用且不显示 OVR
查 NAPI poll 是否被压垮
Linux 用 NAPI 机制批量收包，一旦 poll 函数执行超时或被抢占，就会丢弃后续 skb：
- 运行
watch -n1 'cat /proc/interrupts | grep eth0'，观察对应网卡 IRQ 编号的中断计数是否“卡住”或突增后停滞——说明软中断处理不过来 - 检查
/proc/sys/net/core/netdev_budget（默认 300），值太小会导致单次 poll 提前退出；值太大则可能饿死其他 softirq - 临时调高可试：
echo 600 > /proc/sys/net/core/netdev_budget，但治标不治本，需配合 IRQ balance 或 RPS
验证 Ring Buffer 深度是否够用
驱动从网卡 DMA 区域读包依赖 Ring Buffer 容量，过小会在流量毛刺时直接溢出：
- 查当前大小：
ethtool -g eth0，关注Current hardware settings下的Rx值 - 商用万兆卡常见默认是 256～512，突发流量下极易打满；建议调至 4096（需驱动支持）：
ethtool -G eth0 rx 4096 - 调大后务必观察
rx_no_buffer_count（ethtool -S eth0输出）是否归零，否则说明内存分配失败或驱动限制
警惕虚拟化环境下的隐性瓶颈
在 KVM/QEMU 或容器中，rx_missed_errors 上涨不代表网线或驱动问题：
- vCPU 绑核不合理、宿主机 CPU steal time 高、或 virtio 驱动未启用
indirect descriptors都会导致 missed - 检查
cat /proc/vmstat | grep pgpgin和steal时间，若pgpgin持续飙升 +steal>5%，说明宿主机内存压力传导到了 vNIC - 对比宿主机
ethtool -S virbr0或tap*设备的rx_dropped，若远高于 guest 内eth0的rx_missed_errors，问题就在宿主机侧
真正难缠的偶发丢包，往往不是参数没调对，而是多个条件叠加触发：比如某次流量尖峰恰逢 vCPU 被调度出去 200μs，Ring Buffer 满了，而 netdev_budget 又刚好耗尽——此时 rx_over_errors 和 rx_missed_errors 可能只各加 1，监控采样间隔却为 15 秒，直接漏掉。盯住这两个字段的秒级变化，比看平均值有用得多。
