Linux dropped案例研究

Linux dropped 案例研究

一 概念与判读要点

• ifconfig 的 rx_dropped：自 Linux 内核 2.6.37 起，该计数主要统计在协议栈之前被丢弃的帧，例如 软网队列（softnet backlog）满、错误的 VLAN 标签、未知/未注册协议 等。这类计数上升通常不代表硬件故障，而是内核输入路径拥塞或配置不匹配的信号。快速验证方法是在问题窗口运行 tcpdump 观察：若 rx_dropped 停止增长，多为 softnet backlog 满导致的“可见丢弃”。
• /proc/net/dev 的 RX dropped 与 ifconfig 的 rx_dropped 并非同一含义：前者常包含驱动/RX 队列层面的丢包（如 RX fifo/overruns 等），后者偏向协议栈前的输入丢弃。两者需结合查看，避免误判根因。
• UDP 专项：当 netstat -s -u 中的 receive buffer errors 增长，通常意味着 socket receive buffer 不足 或应用消费不及时；而 packet receive errors 增长则可能是更底层（驱动/硬件/队列）问题。
• 队列与过滤相关计数：/proc/net/softnet_stat 第二列反映 netdev_max_backlog 溢出 导致的丢弃；rp_filter 配置不当会引发反向路由校验丢包；iptables/nf_conntrack 规则或连接跟踪表满同样会造成入站丢包（常见于高并发/NAT 场景）。

二 案例一 软网队列满导致服务健康检查异常

• 现象：某业务出现 Consul 健康检查大量超时，跨机 ping 显示 36% 丢包，但 RTT 极小（0.129–2.849 ms），呈现“有序号间隔”的丢包特征，疑似中间设备或本机输入路径拥塞。
• 排查与定位：
  • 查看接口统计：ifconfig 显示 RX errors 0、dropped 增长、overruns 0，初步排除硬件 FIFO 溢出，指向内核输入路径拥塞。
  • 检查网卡 Ring Buffer：ethtool -g 发现 RX 仅 256，在高带宽/突发流量下偏小，易加剧软网队列压力（虽非本案例根因，但属于风险点）。
  • 检查软网队列：cat /proc/net/softnet_stat 关注第二列（backlog 溢出计数），若某核持续递增，即指向 netdev_max_backlog 不足或软中断处理不过来。
• 处置与验证：
  • 提升软网队列容量：sysctl -w net.core.netdev_max_backlog=2000–5000，并观察 softnet_stat 第二列是否回落。
  • 优化中断与软中断处理：将网卡中断 亲和性 分散到多个 CPU，必要时临时关闭 irqbalance 或为关键 IRQ 设置 smp_affinity 掩码，避免单核过载。
  • 适度增大 Ring Buffer：ethtool -G eth0 rx 2048（视网卡/驱动而定），缓解突发流量下的描述符耗尽。
  • 回归验证：在故障时段再次 ping/健康检查，并对比 /proc/net/softnet_stat 与 ifconfig dropped 的趋势是否收敛。

三 案例二 UDP 大流量下 socket 缓存不足导致 rx_dropped 增长

• 现象：使用 iperf3 进行 UDP 1 Gbps、5 秒 测试时，接收端出现 rx_dropped 与 UDP receive buffer errors 增长，吞吐仅 600+ Mbps。
• 排查与定位：
  • 接口层：ifconfig 显示 RX errors/dropped 增长；ethtool -S 未见明显 rx_fifo_errors，排除 NIC 硬件 FIFO 溢出。
  • 传输层：netstat -s -u 中 receive buffer errors 与 InErrors 同步增长，指向 socket receive buffer 不足 或应用读取不及时。
  • 队列/中断：检查 /proc/net/softnet_stat 第二列（backlog 溢出）与 中断亲和性/中断合并，确认软中断与队列未成为主要瓶颈。
• 处置与验证：
  • 增大 socket 接收缓冲：提高 net.core.rmem_default / rmem_max，并在应用或测试工具中设置更大的 SO_RCVBUF，观察 UDP receive buffer errors 是否下降。
  • 提升 Ring Buffer：ethtool -G rx 2048，为突发流量提供更多描述符空间（收益视场景而定）。
  • 中断负载均衡：将网卡中断分散到多核，避免单核软中断饱和。
  • 回归验证：再次运行 iperf3，关注 rx_dropped / receive buffer errors / 吞吐 是否同步改善。

四 案例三 MTU 配置错误引发“能握手但收不到数据”的丢包

• 现象：对某服务 hping3 -S 能正常收到 SYN-ACK，但 curl 访问 HTTP 超时；接口统计显示 RX-DRP 增长。
• 排查与定位：
  • 抓包确认：TCP 三次握手可见，但后续 HTTP GET 数据未见到达；怀疑 MTU/分片 问题。
  • 接口检查：ip/ifconfig 发现 MTU 仅 100（异常偏小），导致大数据包被丢弃或频繁分片失败。
• 处置与验证：
  • 修正 MTU：ifconfig eth0 mtu 1500（或按实际网络环境设置），随后 curl 正常返回页面，RX-DRP 停止增长。
• 经验要点：对 UDP/TCP 大报文业务，务必确保 端到端 MTU 一致；在 容器/虚拟化 环境中尤其要核对 veth/bridge 的 MTU 继承与策略。

五 可复用的排查流程与关键命令

• 快速分层定位：
  • 物理/驱动层：ethtool -S | grep rx_ | grep errors；ethtool -g （检查 RX/TX ring、是否支持 LRO/GRO）。
  • 接口计数层：ifconfig ；cat /proc/net/dev（区分 RX dropped 与 RX fifo/overruns）。
  • 软网队列层：cat /proc/net/softnet_stat（第二列是否为 backlog 溢出）。
  • 传输层：netstat -s -u（关注 receive buffer errors / packet receive errors）；ss -lunpt（检视 Recv-Q 是否长期打满）。
  • 策略/过滤层：iptables -S；sysctl net.netfilter.nf_conntrack_max / nf_conntrack_count；cat /proc/sys/net/ipv4/conf/all/rp_filter。
  • 抓包验证：tcpdump -i -nn -vv port < 业务端口> ；必要时在问题窗口对比 ifconfig dropped 是否继续增长。
• 常见处置要点（按场景选择）：
  • 软网队列拥塞：sysctl -w net.core.netdev_max_backlog=2000–5000；优化 RPS/RFS 或中断亲和性。
  • Ring Buffer 不足：ethtool -G rx 2048（视驱动/网卡上限）。
  • Socket 缓冲不足：提高 net.core.rmem_default / rmem_max 并在应用设置 SO_RCVBUF。
  • 连接跟踪/NAT 压力：调大 nf_conntrack_max，优化短连接/连接复用，清理无效规则。
  • 反向路由校验：根据拓扑将 rp_filter 设为 0/2，避免误丢合法入包。
  • MTU 不一致：统一 物理口/桥/veth/容器 的 MTU，必要时启用 PMTU 发现。

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