高并发问题下ip_conntrack: table full, dropping packet处理方案

最近发现Tracker所在的BuyVM服务器意外重启,于是调查重启原因时发现系统日志中持续出现大量的如下提示信息。

July 23 08:29:57 localhost kernel: [345379.839795] nf_conntrack: nf_conntrack: table full, dropping packet
July 23 08:29:57 localhost kernel: [345379.841751] nf_conntrack: nf_conntrack: table full, dropping packet
July 23 08:29:57 localhost kernel: [345379.848711] nf_conntrack: nf_conntrack: table full, dropping packet
July 23 08:29:57 localhost kernel: [345379.851790] nf_conntrack: nf_conntrack: table full, dropping packet
July 23 08:29:57 localhost kernel: [345379.864515] nf_conntrack: nf_conntrack: table full, dropping packet

才注意到TCP会话数超出了系统配置的最大值,然后开始丢包。由于Tracker服务器目前服务全网请求量确实很大,内核netfilter模块conntrack默认参数配置过低,导致新连接被drop掉。

查阅了资料后,发现nf_conntrack模块在Linux Kernel 2.6.15 被引入,同时支持IPV4和IPV6,取代只支持IPV4的ip_connktrack,主要用来跟踪连接的状态,以供其他模块使用,例如用于NAT和连接状态记录。
nf_conntrack用一个哈希表记录已建立的连接,包括其他机器到本机、本机到其他机器、本机内部的连接,如果连接进来比释放得快,把这个哈希表塞满了,新连接的数据包会被drop掉,此时netfilter变成了一个黑洞,导致拒绝服务,就像上面看到的结果。

和 nf_conntrack 相关的内核参数可以用下面的命令查看

sysctl -a | grep conntrack

nf_conntrack_buckets 使用情况查看

grep conntrack /proc/slabinfo

前四个数字分别为:当前活动对象数、可用对象总数、每个对象的大小(字节)、包含至少1个活动对象的分页数。

查看nf_conntrack表最大连接数

cat /proc/sys/net/netfilter/nf_conntrack_max

查看nf_conntrack_buckets哈希表最大大小

cat /proc/sys/net/netfilter/nf_conntrack_buckets

此时会发现两个值几乎相近(当然最大连接数必定略小于哈希表最大大小,毕竟多出来的都被drop了)。

那既然最大连接数过小,那么调大就好了。

注意一下 net.netfilter.nf_conntrack_max 不是越高越好,通常根据内存大小进行设置。一般来说网上通用的计算公式如下:

nf_conntrack_max计算公式(64位)
CONNTRACK_MAX = RAMSIZE (inbytes)/16384/2

例如你的机器是一个64GB 64bit的系统,那么最合适的值是
CONNTRACK_MAX = 64*1024*1024*1024/16384/2 = 2097152

nf_conntrack_buckets决定存储conntrack条目的哈希表大小,默认值是nf_conntrack_max的1/4,延续这种计算方式:BUCKETS = CONNTRACK_MAX/4,如64G内存可以设置524288,此时哈希表也可修改一下。

但是我算了下结果,貌似和我当前的默认值一样,因此索性把值提了一倍。

修改方法如下:

执行以下命令,使配置即时生效。(注意这里的两个值要根据实际修改一下)

sysctl -w net.netfilter.nf_conntrack_max=2097152

修改哈希表大小
echo 524288 > /sys/module/nf_conntrack/parameters/hashsize

执行以下命令可确保重启后配置仍然生效。

echo "net.netfilter.nf_conntrack_max = 2097152" >> /etc/sysctl.conf

可以顺便修改一下tcp_timeout_established,默认值长达五天之久。
echo "net.netfilter.nf_conntrack_tcp_timeout_established = 3600" >> /etc/sysctl.conf

修改后连接就不会被drop了。实际上如果云服务厂商有提供安全组、防火墙等功能,可以直接使用外部防火墙,此时可以直接撤掉机器内部的防火墙,也就没有这个问题了。亦或者如果不需要使用到涉及到状态链路相关或者NAT相关的应用,也可以直接设置不加载这个模块的。

点赞
  1. 李总的粉丝说道:
    Google Chrome Windows 10

    上了新文章 :huaji15:

    1. Hanada说道:
      Google Chrome Windows 10

      :yinxian: 怎么一天到晚盯着我的博客不放

发表评论

电子邮件地址不会被公开。必填项已用 * 标注