网卡丢包率过高会直接压制网络吞吐，表现为带宽利用率低但延迟高、重传激增、连接卡顿；需用ethtool -s和/proc/net/dev查rx_missed_errors/rx_dropped/rx_over_errors确认是否网卡层丢包，再用tc qdisc show排查人为丢包策略，并结合iftop、ss -i、netstat -s验证丢包与吞吐下降的因果关系。
网卡丢包率过高会直接压制网络吞吐，表现为带宽利用率低但延迟高、重传激增、连接卡顿。排查关键不是“有没有丢包”，而是确认丢包是否发生在网卡层，以及它是否成为吞吐瓶颈的主因。
查网卡硬件与驱动级丢包计数
真正由网卡或驱动导致的丢包，往往不会进入协议栈，tcpdump 也抓不到。必须依赖底层统计：
- 运行
ethtool -S eth0 | grep -i "drop\|error\|over\|missed"，重点关注：
• rx_missed_errors：Ring Buffer 溢出（接收太快，CPU/NAPI 处理不过来）
• rx_dropped：NAPI 调度延迟或 softnet backlog 溢出
• rx_over_errors：同 rx_missed_errors，部分驱动用此字段
• tx_dropped：发送队列满或驱动拒绝入队 - 对照
cat /proc/net/dev中的 Rx-DRP（进 Ring Buffer 后丢）和 Rx-OVR（Ring Buffer 溢出丢）列，两者持续上涨即为强信号 - 虚拟环境注意：rx_missed_errors 上升大概率是 vCPU 过载，而非物理链路问题
区分真实丢包与人为丢包
很多“高丢包率”其实是 tc/qdisc 主动模拟的，和吞吐下降强相关但非故障：
- 执行
tc qdisc show dev eth0，若输出含netem、loss、corrupt等关键词，说明丢包是策略行为 - 加
-s查真实丢弃数：tc -s qdisc show dev eth0，看 dropped 字段是否随时间增长 - 常见误配：
tc qdisc add dev eth0 root netem loss 5%会导致出向吞吐恒定打不满，且不体现在 /proc/net/dev 中
验证丢包是否压制吞吐
仅看丢包率数字没意义，需结合吞吐表现做因果判断：
- 用
iftop -P或nethogs观察实时出口带宽——若峰值远低于链路标称带宽（如千兆口只跑 200Mbps），且ip -s link show eth0中 rx_missed_errors 或 tx_dropped 持续跳变，基本可锁定 - 运行
ss -i查单连接信息，若某 TCP 流的 cwnd 值长期卡在 10 MSS 以下、retransmits 快速上升，说明丢包已触发拥塞控制降速 - 对比
netstat -s | grep -i "retransmitted"的增量速率与吞吐下降节奏：若每秒重传段数增加 100+，而吞吐同步下跌 30%，高度相关
快速缓解与调优方向
确认是网卡层丢包后，优先尝试低成本见效的调整：
- 增大 Ring Buffer：
ethtool -G eth0 rx 4096 tx 4096（需驱动支持，部分网卡上限为 8192） - 调高内核处理阈值：
sysctl -w net.core.netdev_max_backlog=50000 - 关闭可能干扰的 offload：
ethtool -K eth0 gso off tso off gro off（尤其在虚拟化或旧网卡上） - 检查中断分布：
cat /proc/interrupts | grep eth0，若所有中断集中在一个 CPU，用irqbalance或手动绑核均衡
