Linux dropped现象详解

Linux dropped 现象详解

一 概念与分层定位

• 在 Linux 网络栈中，dropped表示数据包在某个阶段被丢弃，并非全部等价。常见分层与含义如下：
  • 网卡/驱动层：
    • RX dropped：包已进入网卡 Ring Buffer，但因系统资源不足等原因在拷贝到内存时被丢弃（如内存紧张、驱动未能及时取包）。
    • RX overruns / fifo：包未进入 Ring Buffer 前，因 NIC 内部 FIFO 满被丢弃，常见于中断/处理不及时或队列过小。
    • 注意：部分驱动/硬件会把 L2 地址过滤丢弃计入 RX dropped，而设备因缓冲耗尽丢弃的包可能计入 rx_missed_errors，不同驱动实现存在差异。
  • 内核网络层：
    • netdev_max_backlog 溢出：内核从网卡收包后、进入 IP 层前的每 CPU backlog 队列满导致丢包。
    • 邻居子系统（ARP）：如 arp_ignore/arp_filter 配置不当导致 ARP 丢弃。
  • 队列/策略层：
    • tc qdisc（如 netem）配置的丢包/延迟等并不会体现在网卡统计中，需要单独查看 qdisc 统计。
  • 防火墙/连接跟踪：
    • iptables/nftables DROP/REJECT 规则命中计数增长。
    • nf_conntrack 表满或超限导致后续包被丢弃。
  • 套接字/应用层：
    • UDP socket 接收/发送缓冲区不足（如 receive/send buffer errors）导致丢包。
    • **TCP 全连接队列（accept queue）/半连接队列（sync queue）**溢出导致握手失败或连接丢弃。

二 快速判断与常用命令

• 查看接口层计数（ifconfig/ethtool）
  • 命令：ifconfig eth0、ethtool -S eth0、netstat -i
  • 关注：RX dropped / RX overruns(fifo)、TX dropped 的增长趋势与峰值时段。
• 查看队列/策略层
  • 命令：tc -s qdisc show dev eth0（关注 dropped、overlimits）
• 查看防火墙/连接跟踪
  • 命令：iptables-save | grep -i drop、iptables -L -nv、nft list ruleset
  • 命令：sysctl net.netfilter.nf_conntrack_count、cat /proc/net/nf_conntrack | wc -l
• 查看内核丢包热点
  • 命令：perf record -g -a -e skb:kfree_skb & & perf script
  • 命令：dropwatch -l kas（启动后 start 抓取内核丢包位置）
• 查看协议栈与队列
  • 命令：netstat -s、ss -sti、ss -lntu
  • 命令：dmesg | grep -i "drop\|backlog\|syn"（如半连接队列溢出提示）
• 查看 CPU/中断负载
  • 命令：mpstat -P ALL 1、cat /proc/interrupts、ethtool -x eth0（RSS 队列分布）

三 常见成因与对应处理

• 网卡/驱动层
  • Ring Buffer/驱动来不及取包：表现为 RX dropped 增长。
    • 处理：增大驱动队列（如 ethtool -G 调大 rx/tx ring）、提升中断/软中断处理能力（RSS 多队列、中断绑核）、优化 CPU 亲和与调度。
  • NIC FIFO 溢出：表现为 RX overruns/fifo 增长。
    • 处理：提升处理速率（多队列+绑核）、适度增大 ring、降低突发流量冲击、检查驱动/固件版本。
• 内核网络层
  • netdev_max_backlog 溢出：高带宽/突发时内核输入队列满。
    • 处理：适度增大 net.core.netdev_max_backlog（如由 1000 提升到 2000/4000），并配合多队列与软中断均衡。
  • 邻居/ARP 策略不当：跨接口/多宿主环境下 ARP 应答异常导致后续报文丢弃。
    • 处理：按需设置 arp_ignore/arp_filter，确保回包路径与 MAC 一致性。
• 队列/策略层
  • tc/netem 人为丢包/限速：不会体现在 ifconfig，但在 tc -s 可见。
    • 处理：核对并移除/调整相关 qdisc 规则。
• 防火墙/连接跟踪
  • iptables/nftables DROP 规则命中：pkts 计数增长。
    • 处理：审计规则、临时停用可疑规则定位问题。
  • nf_conntrack 表满：高并发/大量短连接场景常见。
    • 处理：增大 nf_conntrack_max、优化连接超时、减少无谓连接、必要时分流出 conntrack 压力。
• 套接字/应用层
  • UDP 缓冲区不足：netstat -u 中 receive/send buffer errors 增长。
    • 处理：增大 net.core.rmem_max/wmem_max、net.ipv4.udp_rmem_min/udp_wmem_min，并优化应用读取/发送节奏。
  • TCP 队列溢出：SYN_RECV 堆积、dmesg 报 “drop open request”、ss -lnt 显示 Recv-Q 长期很高。
    • 处理：增大 net.ipv4.tcp_max_syn_backlog、net.core.somaxconn，优化应用 accept 能力，必要时启用 syncookies。

四 典型场景与优化建议

• 高带宽短突发/小包场景
  • 现象：RX overruns/fifo 与 RX dropped 同时上涨。
  • 优化：启用多队列（RSS）、中断绑核（SMP IRQ affinity）、适度增大 ring 与 netdev_max_backlog，并校准软中断预算（如 net.core.netdev_budget）。
• 深队列/长肥管道与 TCP 拥塞控制
  • 现象：随机丢包导致 cwnd 频繁下折、吞吐不稳。
  • 优化：在符合业务特征前提下评估 BBR（Linux 4.9+ 引入），其基于 最大带宽 Max BW 与 最小 RTT 的乘积 BDP 做速率与窗口控制，对随机丢包更具鲁棒性；实时音视频等对延迟敏感场景需谨慎评估其 ProbeRTT 阶段影响。
• NAT/移动网络下的时间戳问题
  • 现象：同 NAT 内多客户端时间戳不一致，服务端丢弃后续包（如 SYN 不回 ACK）。
  • 处理：避免启用 net.ipv4.tcp_tw_recycle（在 NAT 场景易引发问题），必要时开启 tcp_tw_reuse（客户端侧更常用），并合理调大 tcp_max_tw_buckets。
• 人为策略/测试引入的丢包
  • 现象：tc netem loss、iptables random drop 等导致业务波动。
  • 处理：排查并移除相关规则，恢复基线配置后再验证业务。

五 排查顺序与关键指标

• 建议顺序
  1. 观察接口层：ifconfig/ethtool -S 看 RX dropped/overruns 是否增长。
  2. 检查队列/策略：tc -s qdisc 是否有 dropped；iptables/nft 是否有命中。
  3. 检查内核热点：perf record -e skb:kfree_skb 或 dropwatch 定位丢包位置。
  4. 检查协议栈：netstat -s、ss -sti/lntu、dmesg 看 backlog/syn 溢出。
  5. 检查 CPU/中断：mpstat -P ALL 1、/proc/interrupts、ethtool -x 评估软硬中断与 RSS 均衡。
  6. 校验应用层：UDP 看 buffer errors，TCP 看 accept 队列与业务读取/发送速率。
• 关键指标与阈值示例
  • RX overruns/fifo > 0：优先怀疑处理/中断跟不上或队列偏小。
  • netdev_max_backlog 溢出计数增长：适度增大队列并做多队列+绑核。
  • iptables DROP 计数增长：审计并临时下线可疑规则。
  • nf_conntrack_count 接近 nf_conntrack_max：增大上限或优化连接生命周期。
  • SYN_RECV 高、accept 队列满：增大 tcp_max_syn_backlog/somaxconn 并提升应用 accept 能力。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！