linux 增加 ip_conntrack_max 造成内核内存问题

古城微笑少年丶 2021-08-26 14:30 354阅读 0赞

### 1.由ip\_conntrack引出的Linux内存映射 ###

有很多文章在讨论关于ip\_conntrack表爆满之后丢弃数据包的问题，对此研究深入一些的知道Linux有个内核参数ip\_conntrack\_max，在拥有较大内存的机器中默认65536，于是疯狂的增加这个参数，比如设置成10000…00，只要不报设置方面的错误，就一定要设置成最大值。这种方式实在是将软件看成大神了，殊不知软件的技术含量还不如锅炉呢！  
       如果考虑的再全面一些，比如经验丰富的程序员或者网管，可能会想到内存的问题，他们知道所有的连接跟踪信息都是保存于内存中的，因此会考虑单纯放大这个ip\_conntrack\_max参数会占据多少内存，会权衡内存的占用，如果系统没有太大的内存，就不会将此值设置的太高。  
       但是如果你的系统有很大的内存呢？比如有8G的内存，分个1G给连接跟踪也不算什么啊，这是合理的，然而在传统的32位架构Linux中是做不到，为什么？因为你可能根本不懂Linux内核的内存管理方式。  
       内存越来越便宜的今天，linux的内存映射方式确实有点过时了。然而事实就摆在那里，ip\_conntrack处于内核空间，它所需的内存必须映射到内核空间，而传统的32位Linux内存映射方式只有1G属于内核，这1G的地址空间中，前896M是和物理内存一一线性映射的，后面的若干空洞之后，有若干vmalloc的空间，这些vmalloc空间和一一映射空间相比，很小很小，算上4G封顶下面的很小的映射空间，一共可以让内核使用的地址空间不超过1G。对于ip\_conntrack来讲，由于其使用slab分配器，因此它还必须使用一一映射的地址空间，这就是说，它最多只能使用不到896M的内存！  
       为何Linux使用如此“落后”的内存映射机制这么多年还不改进？其实这种对内核空间内存十分苛刻的设计在64位架构下有了很大的改观，然而问题依然存在，即使64位架构，内核也无法做到透明访问所有的物理内存，它同样需要把物理内存映射到内核地址空间后才能访问，对于一一映射，这种映射是事先确定的，对于大小有限(实际上很小)非一一映射空间，需要动态创建页表，页目录等。另外还有一个解释，那就是“内核本来就不该做ip\_conntrack这种事”，那是协议栈的事，而不巧的是，Liunx的协议栈完全在内核中实现，可能在skb接收软中断中处理的ip\_conntrack不能睡眠，因此也就不能将此任务交给进程，也就不能利用进程地址空间(进程地址空间\[用户态+内核态\]可以访问所有的物理内存)。

Linux之所以对内核内存要求如此苛刻，目的就是不想让你随意使用，因为它宝贵，你才更要珍惜它们。

###    2.在32位架构Linux系统上的实验 ###

以下是为了证明以上的事实所作的实验，可能实验中使用的一些手段仍然不符合常识，然而我觉得成一家之言即可，毕竟这种方案永远不会也不可能出现在公司的标准文档上，那样会让人学会投机取巧或者称偷懒，但是为了备忘，还得有个地方留着，那就写成博客吧。  
       还有一个参数会影响查找连接跟踪的时间复杂度和空间复杂度，那就是ip\_conntrack\_buckets。该值描述了哈希桶的数量，理论上，这个值越大，哈希碰撞就会越小，查找时间就会越快，但是需要为每一个桶预分配一块不是很大的内存，如果桶数量很大，就会占用很大的内存，并且这些内存还都是宝贵的“仅有1G空间内的内核内存”，和ip\_conntrack结构体的分配策略不同，这个哈希桶可以分配在vmalloc空间而不一定非要在一一线性映射空间。

2.1.快速压满ip\_conntrack的方法  
使用loadrunner绝对是一种方式，然而术业有专攻，工作之余我又很讨厌windows上的一切，因此需要采用其它方式，下班在家，只身一人，也不想使用netcat之类的“瑞士军刀”，我怕端口占满，又怕我的macbook狂热，因此需要再想办法。由于目的只是想测试ip\_conntrack最多能占用多少内存，其实这个我早就知道了，只是想证实一下子，那么办法也就有了，那就是增加ip\_conntrack结构体的大小，而这很容易，只需要在结构体后面增加一个很大的字段即可。下面的修改基于Red Hat Enterprise 5的2.6.18内核

2.2.测试前对ip\_conntrack内核模块的修改  
编辑$build/include/linux/netfilter\_ipv4/ip\_conntrack.h文件，在结构体ip\_conntrack的最后加上下面一句：  
char aaa\[102400\]; //这个102400是通过二分法得到的，如果设置成2xxxxx则在加载的时候就会使内核crash，因为这个数组是直接分配(类似栈上分配)的而不是动态分配的，它载入的时候很可能会冲掉内核的关键数据，因此还是选取一个可行的数值，然后慢慢加连接吧，毕竟扩大了起码100000倍呢~~  
进入$src/net/ipv4/netfilter，执行：

make –C /lib/modules/2.6.18-92.e15/build SUBDIRS=`pwd` modules

如此一来加载ip\_conntrack.ko之后，内核日志将打印出：  
ip\_conntrack version 2.4 (8192 buckets, 65536 max) - 102628 bytes per conntrack  
由此看出ip\_conntrack结构体已经增大了，这样撑满整个可用内存所需的网络连接压力就大大减小了，也就不用什么loadrunner之类的东西了。为了尽快撑满可以使用的内存，还要将关于ip\_conntrack的所有timeout设置的比较长，相当长：

sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=600000
    sysctl -w net.ipv4.netfilter.ip_conntrack_icmp_timeout=300000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=1000000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=120000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack=300000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=60000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait=120000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=432000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=600000
    sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent=120000

这样既有的一个流就会“永久保持”了，一直占着ip\_conntrack结构体不放，直到可用的内存溢出。  
       在加载了ip\_conntrack模块之后，所有过往的数据包就会自动被追踪，下面编写以下脚本：

for (( i=1; i<255; i++));
    do
        for (( j=1; j<255; j++));
        do
            ping 192.168.$i.$j -c 1 -W 1
            curl --connect-timeout 1 http://138.$i.$j.80/
            curl --connect-timeout 1 http://38.$i.$j.80/
            curl --connect-timeout 1 http://$i.1.$j.80/
            curl --connect-timeout 1 http://$j.$i.9.8/
        done
    done

2.3.测试过程  
本机配置：  
内存：3032M，free命令识别3003M  
执行上述脚本，抽根烟，拉一脬(pao)，得到下列的数据：  
封顶连接数：6149个  
使用内存：886M  
此时在本机ping 127.0.0.1也不通了，说明ip\_conntrack已经达到了极限，同时由于在alloc ip\_conntrack的地方插入了打印语句(肯定是一堆\#号)，内核打印了内存分配失败的信息。一共3G的内存，仅仅使用了886M(而且我不断使用sysctl –w vm.drop\_caches=3清楚cache)，剩余的都无法给ip\_conntrack使用。为了使结果更有说服力，我在ip\_conntrack模块的初始化函数中插入了下列代码：

for (j=0; I < 400; j++)
        __get_free_pages(GFP_KERNEL, 8);

意思是我先占去内核空间的400M内存，看看最终总的连接跟踪数量是否也会减少相应的，得到数据如下：  
封顶连接数：3421个  
使用内存：879M  
可见，内核内存被额外占据了，能分给ip\_conntrack的就少了。更进一步，保持上述的\_\_get\_free\_pages不变，再增加下列的代码：

for (j=0; I < 400; j++)
        __get_free_pages(GFP_HIGHUSER, 8);

最终的结果如下：  
封顶连接数：3394个  
使用内存：1203M  
可见，HIGHUSER内存并不会怎么影响内核内存，要知道用户进程的内存几乎都是使用这个HIGHUSER标识分配的。如果去掉GFP\_KERNEL的分配，仅仅保留GFP\_HIGHUSER的分配，得到下列结果：  
封顶连接数：6449个  
使用内存：1312M  
可见，HIGHUSER内存的分配尽力在高端进行，不会怎么影响内核的一一映射空间。

2.4.测试结果  
综上所述，32位架构上Linux的ip\_conntrack使用的内存只能在内核地址空间的一一映射区，换句话说，它只能使用物理内存的前896M，除掉ip\_conntrack结构体的添加的char aaa\[\]，也是这个结果，只不过要想压满所有的可用内存，不是很容易，需要动用几台机器以及loadrunner之类的压力工具。

###    3.结论 ###

最后，需要说明的是，ip\_conntrack\_max的初始值是内核根据你机器的内存计算出来的，包括ip\_conntrack\_buckets也是这样算出来的，内核之所以设置这样的初始值，那是经过精心测试的经验值，因此除了非要改不可，不要去提高这个值。如果你的机器面临大量连接，你提高了ip\_conntrack\_max的值，那么代价就是占用了大量可贵的内核内存，可能会引起其它的内核内存分配失败，并且，一旦内核内存使用超过了内核内存空间映射的阀值，那么系统会默默的丢弃你的数据包，而不会报出：  
table full, dropping packet error and solution  
之类的错误，这是可悲的一件事。  
       操作系统内核影响协议栈行为带来了一种错觉：我有这么多内存，为何不让我使用？！事实上，不是你要使用，而是内核要使用，你可以控制的只是进程，对于内核，程序员是没法控制的。当然你可以重新编译，甚至修改内核，甚至修改ip\_conntrack的内存分配方式，不再使用伙伴系统的slab内存，而是重定向一个userspace，然则，然则这个开发需要成本，一个人日几百块，没有几个公司愿意花这笔钱。因此，最终的结论：不要盲目增加ip\_conntrack\_max。呼应了题目。

附：  
1.关于GFP\_XXX  
GFP\_ATOMIC：设置这个标识，在内核映射区域的紧急池分配，不成功则简单返回NULL，不释放其它内存，也就不kill进程，分配路径不睡眠。ip\_conntrack结构体就是使用这个标识分配的(它大多数处于软中断路径)  
GFP\_KERNEL：设置这个标识，在内核映射区域分配，不成功则尝试释放可以释放的内存，尝试调用oom\_killer，可以睡眠  
GFP\_HIGHUSER：设置这个标识，可以分配到所有的物理内存(排除很小一部分固定内存以及用于总线IO的内存，这个在x86上很明显，具体参见/proc/iomem获得详细物理内存映射信息)。一般而言，用户态进程所需的内存都使用这个标识来分配，尽量使用内核“很难”使用的高端内存(1G以后的物理内存，内核还要动态映射，这要操作页表)，从而将前896M(32位架构)尽量留给内核使用

2.关于ip\_conntrack的哈希  
Linux的ip\_conntrack使用了 jhash函数来进行哈希计算，关于该函数的实现可以参考下面这个网址：  
http://burtleburtle.net/bob/hash/doobs.html