Greenplum数据库故障分析——UDP Packet Lost（packet reassembles failed）

雨点打透心脏的1/2处 2022-10-13 02:00 147阅读 0赞

最近在项目中遇到SQL挂死，业务无法继续进行下去的情况。在经过几次测试验证（将挂死主机节点踢出集群、将udpifc切换为tcp），该问题会消失。将挂死主机节点加入集群会直接复现。但是将udp切换为tcp后，经过一段时间再切换为udp后，不会复现，但是经过一段时间后，该问题又会复现。  
经过排查后，定位在于udp无法成功组包，主要表现在某台主机packet reassembles failed增长量和速度远高于其他主机。

## 一. Packet reassemble ##

当发送的UDP报文长度大于MTU大小时，IP层会将报文进行分片，当接收端收到分片后，会进行分片重组，生成一个完整的UDP报文，分片重组的过程由内核协议栈完成的，协议栈需要一个buffer来存储已经到达的分片，等待所有分片到达，再进行重组。  
如上图所示，在MTU=1500的情况下，一个length=3200的大包，将被拆分为3个小包进行发送。在接收方将会对小包进行重组，由于Ethernet的特性，在分片到达接收方时：分片有可能乱序；任意分片也有可能丢失。

## 二. 确认是否是packet reassembles failed 导致UDP丢包 ##

packet reassembles failed导致丢包的前提是发送的报文是大于MTU的大包  
在上一篇文章中有提到netstat -s可以看到内核协议栈的计数信息：

#netstat -s
    Ip:
        1075974066 total packets received
        0 forwarded
        0 incoming packets discarded
        137873343 incoming packets delivered
        3803720 requests sent out
        48 dropped because of missing route
        1411 fragments dropped after timeout
        1072078860 reassemblies required
        133978164 packets reassembled ok
        239741 packet reassembles failed
        215 fragments received ok
        1720 fragments created

*  fragments dropped after timeout: 分片在reassemble buffer中超时后被丢弃的计数
 *  packet reassembles failed: 报文重组失败计数。该值包含timeout的计数

## 三. packet reassembles failed原因分析 ##

### 1. fragments dropped after timeout 场景 ###

IP 某个分片丢失，始终无法重组成一个完整的报文，在reassemble buffer中的其他分片就会一直滞留，直到timeout被丢弃。当系统中有大量的fragments dropped after timeout计数的增长时，我们一般需要确认的是底层链路是否存在一定的丢包率。

#### 1.1 模拟timeout方法 ####

# 服务端
    iperf -s -i 1 -u -w 4M -l 32360
    # 客户端
    iperf -c 172.16.128.6 -i 1 -u -b 128M -l 32360 -t 1000 -P1

在压测的过程中的某个瞬间，将客户端机器 power reset掉，在接收端查看，确认是否有timeout计数增加。

#### 1.2 协议栈代码 ####

/* * Oops, a fragment queue timed out. Kill it and send an ICMP reply. */
    static void ip_expire(unsigned long arg)
    { 
    ...
            IP_INC_STATS_BH(net, IPSTATS_MIB_REASMTIMEOUT);
            IP_INC_STATS_BH(net, IPSTATS_MIB_REASMFAILS);
    ...
    }

#### 1.3 超时时间配置 ####

# 内核默认值为30s
    #cat /proc/sys/net/ipv4/ipfrag_time
    30
    
    # 动态调整 
    #echo 60 >/proc/sys/net/ipv4/ipfrag_time
    
    # sysctl.conf
    net.ipv4.ipfrag_time = 60

### 2. packet reassembles failed 场景一 ###

#### 2.1. packet reassemble buffer ####

*  Linux 内核协议栈使用 reassemble buffer来缓存IP fragment
 *  ipfrag\_high\_thresh 来配置buffer的最大值
 *  当buffer内存使用量达到最大值时，会丢弃buffer中的分片，直到空间降到 ipfrag\_low\_thresh 的值

#### 2.2 packet reassemble buffer 满导致 reassembles failed ####

*  协议栈默认reassemble的大小为4M，相对来说较小
 *  当接收端收到了大量的经过IP 分片的报文时，很容器导致buffer满
 *  或者当接收端的CPU使用率非常高，导致内核进行分片重组的任务等待时，同样会造成buffer满

#### 2.3 通过netstat -s 判断是否需要调整ipfrag\_high\_thresh值 ####

PS: 由于没有找到如何查看reassemble buffer当前的使用量，所以采用了下面这种不直接的方法  
packet reassembles failed 计数一直在增长  
通过fragments dropped after timeout 的计数排除掉是timeout 造成的failed增长，或者timeout的计数只是failed中的一部分  
通过packet reassembles failed 增长的规律进行判断，因为buffer满后丢包的过程是会有大量丢包的，所以这个时候 packet reassembles failed 是一次性巨量的增长，而非1、2的增加

#### 2.4 iperf 模拟reassemble buffer满造成failed计数 ####

# 服务端
    iperf -s -i 1 -u -w 4M -l 32360
    # 客户端
    iperf -c 172.16.128.6 -i 1 -u -b 128M -l 32360 -t 1000 -P10

这里和之前的区别在于加大了客户端的并行度，增加了吞吐量。这个并行可以根据实际情况调整。

#### 2.5 调整reassemble buffer大小 ####

# 动态调整 
    echo 31457280 >/proc/sys/net/ipv4/ipfrag_low_thresh
    echo 33554432 >/proc/sys/net/ipv4/ipfrag_high_thresh
    # sysctl.conf
    net.ipv4.ipfrag_low_thresh=31457280
    net.ipv4.ipfrag_high_thresh=33554432

#### 2.6 内核代码 ####

/* Memory limiting on fragments. Evictor trashes the oldest * fragment queue until we are back under the threshold. */
    static void ip_evictor(struct net *net)
    { 
            int evicted;
    
            evicted = inet_frag_evictor(&net->ipv4.frags, &ip4_frags, false);
            if (evicted) { 
                    IP_ADD_STATS_BH(net, IPSTATS_MIB_REASMFAILS, evicted);
            }
    }

### 3. packet reassembles failed 场景二 ###

该场景造成packet reassembles failed计数增加，一开始并没有发现，是在内核中增加了调试信息，才发现了该场景。 网上一些关于IP 分片重组的文章也并没有提及  
我们将接收端收到的IP分片依次排队标号，属于同一个UDP报文的两个相邻IP分片，如果它们编号差(距离)超过ipfrag\_max\_dist，也会导致重组失败。  
如上图所示，蓝色的两个分片为同一个UDP报文的相邻分片，由于网络中有很多其他的流量，所以在两个分片到达目标的中间夹杂着其他报文的分片。上图中的这两个分片距离为95， 如果ipfrag\_max\_dist值设置的小于95，就会造成该分片重组失败。

#### 3.1 Redhat 对ipfrag\_max\_dist的解释 ####

ipfrag_max_dist - INTEGER
            ipfrag_max_dist is a non-negative integer value which defines the
            maximum "disorder" which is allowed among fragments which share a
            common IP source address. Note that reordering of packets is
            not unusual, but if a large number of fragments arrive from a source
            IP address while a particular fragment queue remains incomplete, it
            probably indicates that one or more fragments belonging to that queue
            have been lost. When ipfrag_max_dist is positive, an additional check
            is done on fragments before they are added to a reassembly queue - if
            ipfrag_max_dist (or more) fragments have arrived from a particular IP
            address between additions to any IP fragment queue using that source
            address, it's presumed that one or more fragments in the queue are
            lost. The existing fragment queue will be dropped, and a new one
            started. An ipfrag_max_dist value of zero disables this check.
    
            Using a very small value, e.g. 1 or 2, for ipfrag_max_dist can
            result in unnecessarily dropping fragment queues when normal
            reordering of packets occurs, which could lead to poor application
            performance. Using a very large value, e.g. 50000, increases the
            likelihood of incorrectly reassembling IP fragments that originate
            from different IP datagrams, which could result in data corruption.
            Default: 64

核心思想为：

*  协议栈认为如果来自同一个Source IP的其他分片，有很多个(>ipfrag\_max\_dist)已经收到了，那么可以推断出之前那个分片的后续分片可能已经丢失了。这个时候就不需要再继续等待了，直接可以将之前收到的分片丢弃，并增加packet reassembles failed计数
 *  以上做法的好处是，如果后续分片确实已经丢失，这样可以快速的废弃掉已接收的分片，而不用等待timeout时间，节约内存
 *  ipfrag\_max\_dist内核默认值为64. 配置为0时，disable该功能。

问题来了：

*  以上讲的特性，在一些场景下其实并不适用：
 *  有大量的网络报文交互
 *  发送端的并发度很高，同时SMP架构，导致很容易造成这种乱序情况

#### 3.2 模拟并确认 由ipfrag\_max\_dist机制导致的 reassemble failed ####

##### 3.2.1 模拟 #####

# 服务端
    ## 将reassemble buffer调大，防止buffer过小的问题干扰
    echo 62914560 >/proc/sys/net/ipv4/ipfrag_low_thresh
    echo 67108864 >/proc/sys/net/ipv4/ipfrag_high_thresh
    iperf -s -i 1 -u -w 4M -l 32360
    # 客户端
    iperf -c 172.16.128.6 -i 1 -u -b 128M -l 32360 -t 1000 -P10

##### 3.2.2 确认 #####

PS：并没有直接的统计计数，我之前定位问题时，通过增加内核打印，确认了该情况。在不增加内核打印的情况下，可以通过其他方式判断。

问题发生时，packet reassembles failed 计数增量很小，一般为1、2。 同时 timeout计数没有增加排除这方面的干扰。通过抓包分析，确认同一个UDP报文中的分片’距离’。  
分析脚本：

# 抓包分析
    tcpdump -i ib0 -s 64 -vvv -nn > packet.log
    # 执行一个分析距离脚本，输出所有距离超过ipfrag_max_dist的报文id
    python dist.py
    # 根据输出id，在报文中最后查看确认
    cat packet.log | grep "offset" | grep -rn --color "id 31567"

dist.py

#!/usr/bin/env python
    # -*- coding:UTF-8
    if __name__ == '__main__':
        coll = dict()
        n = 0
        with open('./packet.log') as input_file:
            for line in input_file.readlines():
                if 'offset' in line:
                    n = n + 1
                    line_list = line.split(',')
                    id = int(line_list[2].split()[1])
                    offset = int(line_list[3].split()[1])
                    if offset == 0:
                        coll[id] = n
                    else:
                        if n - coll[id] >= 64:
                            print("id = %d, dist = %d, line = %d\n" % (id, n - coll[id], n))
                        coll[id] = n

#### 3.3 内核代码 ####

/* Is the fragment too far ahead to be part of ipq? */
    static inline int ip_frag_too_far(struct ipq *qp)
    { 
            struct inet_peer *peer = qp->peer;
            unsigned int max = sysctl_ipfrag_max_dist;
            unsigned int start, end;
    
            int rc;
    
            if (!peer || !max)
                    return 0;
    
            start = qp->rid;
            end = atomic_inc_return(&peer->rid);
            qp->rid = end;
    
            rc = qp->q.fragments && (end - start) > max;
    
            if (rc) { 
                    struct net *net;
    
                    net = container_of(qp->q.net, struct net, ipv4.frags);
                    IP_INC_STATS_BH(net, IPSTATS_MIB_REASMFAILS);
            }
    
            return rc;
    }