网卡丢包但 ping 正常：突发流量的影子

发布时间:2026-02-10 22:29

## 症状 业务报网络断续，监控里网卡丢包计数持续增长，但反复 ping 却一路通畅，小包测试给不出任何异常。丢包统计与连通测试结果矛盾，排查陷入僵局：统计说有病，测试说没病。这类矛盾在流量形态起伏大的业务上尤其常见，比如短视频上传、批量同步、时段性的数据推送。 ## 定位 小包通、大流量丢的形态，指向缓冲区与中断处理能力。ping 包小且速率低，对缓冲与处理能力毫无压力；业务流量里的大包与突发洪峰才是真考验，它们才是把缓冲填满的那批客人。两类计数器分头看：驱动层面的丢弃计数与协议层面的错误统计。 ``` ip -s link show eth0 ethtool -S eth0 | grep -i drop ``` 丢弃集中在接收方向且伴随突发流量时段，基本是接收环形缓冲不够大或中断处理被合并延迟，洪峰一到缓冲溢出，来得慢的 ping 反而次次赶上空位。 ## 解决 先扩大接收缓冲，容纳突发。 ``` ethtool -G eth0 rx 4096 ``` 观察丢包计数是否停止增长。仍丢则查中断合并参数，在吞吐与延迟之间重新找平衡点；虚拟化环境还要看宿主侧的限速与队列，实例内部的调整解决不了上层瓶颈。调整后用真实业务流量的重放或压测验证，而非 ping，验证口径与故障口径保持一致，结论才作数。 ## 预防 带宽利用率的监控要看峰值而不是均值，长期贴近上限的链路早晚出现突发丢包，扩容窗口提前规划。驱动层丢包计数纳入采集，它与用户体感的相关性比连通性探测更高，计数只增不减时用户已经在受影响。压测场景里专门设计突发模型，把缓冲余量测出来留足。顺云云服务器上排查这类矛盾现象时，先看实例规格的包处理能力上限，超过上限的流量形态要先从架构分流，单机调参救不了规格天花板。