rx_drop/tx_drop是sar -n DEV中网卡收发包被内核丢弃的计数器，单位包/秒；业务常无感知因丢的是冗余包、应用有重试、流量容忍高延迟或丢包率未达TCP重传阈值。
rx_drop/tx_drop 是什么，为什么业务可能没感知
rx_drop 和 tx_drop 是 sar -n DEV 输出中反映网卡收发包被内核丢弃的计数器，单位是「包/秒」。它们不等于网络不通或连接失败——很多丢包发生在协议栈高层（如 TCP 重传、应用层重试），或被静默吞掉（如 UDP 包无 ACK 机制）。业务无感知，往往因为：
- 丢的是冗余包（如 TCP 重复 ACK、SACK 覆盖范围外的乱序包）
- 应用使用重试逻辑（HTTP 客户端、gRPC、Kafka 生产者等自带重试）
- 流量本身低频、容忍高延迟（如定时上报、日志采集）
- 丢包率远低于 TCP 重传触发阈值（通常需连续丢 3 个 ACK 或 RTO 超时）
多少算“持续增长”？看 delta 而非绝对值
用 sar -n DEV 1 5 观察 5 秒内每秒变化更有效。重点关注：
- rx_drop 持续 > 100 pkt/s（千兆网卡）或 > 1000 pkt/s（万兆）且稳定不回落
- 同一设备上 rx_drop 增速明显高于 rx_packets 增速（例如 rx_packets 增 5%，rx_drop 增 20%）
- tx_drop 非零且随发包量线性上升（说明不是偶发队列溢出，而是驱动或硬件过滤逻辑异常）
注意：sar 默认采样间隔 1 秒，若用 10 秒间隔，小幅度持续丢包会被平滑掩盖。
常见真实原因和排查路径
别急着调 net.core.rmem_max，先快速排除高频根因：
- 网卡 offload 异常：执行
ethtool -k看rx offload是否开启；某些旧驱动在 LRO/GRO 启用时解析错误导致批量丢包 -
防火墙规则过载：检查
iptables -t raw -L -v或nft list ruleset，匹配计数突增的链可能隐式 drop - 软中断瓶颈：运行
cat /proc/interrupts | grep，确认单个 CPU 上 irq 过载（> 5000/s），再看mpstat -P ALL 1中 %soft 占比是否长期 > 30% - ring buffer 溢出：用
ethtool -S查rx_fifo_errors、rx_missed_errors，非零即说明硬件接收队列已满
阈值经验不是固定数字，而是结合速率与比例判断
没有通用“安全阈值”，但可参考以下组合条件：
- rx_drop / rx_packets > 0.1% 且持续 5 分钟以上 → 值得介入
- rx_drop 绝对值 > 500 pkt/s 且伴随
softirqCPU 升高 → 很可能影响新连接建立 - tx_drop > 0 且
tx_aborted_errors或tx_carrier_errors同步上升 → 物理链路或交换机端口问题 - 同一宿主上多个容器/进程共用网卡时，单个 pod 的 rx_drop 突增但宿主机总量平稳 → 可能是 cgroup net_cls 限速或 ebpf 程序误过滤
