不要盲目增加ip_conntrack_max-理解Linux内核内存

2024-05-12 12:18

本文主要是介绍不要盲目增加ip_conntrack_max-理解Linux内核内存,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

http://blog.csdn.net/dog250/article/details/7107537

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.在64位架构Linux系统上做的实验
MD!由于我大动了内核数据结构,加载模块没有成功,至今仍在调试,排错,已几个时辰有余…
4.结论
最后,需要说明的是,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
作者的解释很清晰

这篇关于不要盲目增加ip_conntrack_max-理解Linux内核内存的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/982609

相关文章

linux如何复制文件夹并重命名

《linux如何复制文件夹并重命名》在Linux系统中,复制文件夹并重命名可以通过使用“cp”和“mv”命令来实现,使用“cp-r”命令可以递归复制整个文件夹及其子文件夹和文件,而使用“mv”命令可以... 目录linux复制文件夹并重命名我们需要使用“cp”命令来复制文件夹我们还可以结合使用“mv”命令总

Linux使用cut进行文本提取的操作方法

《Linux使用cut进行文本提取的操作方法》Linux中的cut命令是一个命令行实用程序,用于从文件或标准输入中提取文本行的部分,本文给大家介绍了Linux使用cut进行文本提取的操作方法,文中有详... 目录简介基础语法常用选项范围选择示例用法-f:字段选择-d:分隔符-c:字符选择-b:字节选择--c

Nginx实现动态封禁IP的步骤指南

《Nginx实现动态封禁IP的步骤指南》在日常的生产环境中,网站可能会遭遇恶意请求、DDoS攻击或其他有害的访问行为,为了应对这些情况,动态封禁IP是一项十分重要的安全策略,本篇博客将介绍如何通过NG... 目录1、简述2、实现方式3、使用 fail2ban 动态封禁3.1 安装 fail2ban3.2 配

Linux使用nload监控网络流量的方法

《Linux使用nload监控网络流量的方法》Linux中的nload命令是一个用于实时监控网络流量的工具,它提供了传入和传出流量的可视化表示,帮助用户一目了然地了解网络活动,本文给大家介绍了Linu... 目录简介安装示例用法基础用法指定网络接口限制显示特定流量类型指定刷新率设置流量速率的显示单位监控多个

ElasticSearch+Kibana通过Docker部署到Linux服务器中操作方法

《ElasticSearch+Kibana通过Docker部署到Linux服务器中操作方法》本文介绍了Elasticsearch的基本概念,包括文档和字段、索引和映射,还详细描述了如何通过Docker... 目录1、ElasticSearch概念2、ElasticSearch、Kibana和IK分词器部署

Linux流媒体服务器部署流程

《Linux流媒体服务器部署流程》文章详细介绍了流媒体服务器的部署步骤,包括更新系统、安装依赖组件、编译安装Nginx和RTMP模块、配置Nginx和FFmpeg,以及测试流媒体服务器的搭建... 目录流媒体服务器部署部署安装1.更新系统2.安装依赖组件3.解压4.编译安装(添加RTMP和openssl模块

linux下多个硬盘划分到同一挂载点问题

《linux下多个硬盘划分到同一挂载点问题》在Linux系统中,将多个硬盘划分到同一挂载点需要通过逻辑卷管理(LVM)来实现,首先,需要将物理存储设备(如硬盘分区)创建为物理卷,然后,将这些物理卷组成... 目录linux下多个硬盘划分到同一挂载点需要明确的几个概念硬盘插上默认的是非lvm总结Linux下多

golang内存对齐的项目实践

《golang内存对齐的项目实践》本文主要介绍了golang内存对齐的项目实践,内存对齐不仅有助于提高内存访问效率,还确保了与硬件接口的兼容性,是Go语言编程中不可忽视的重要优化手段,下面就来介绍一下... 目录一、结构体中的字段顺序与内存对齐二、内存对齐的原理与规则三、调整结构体字段顺序优化内存对齐四、内

Ubuntu固定虚拟机ip地址的方法教程

《Ubuntu固定虚拟机ip地址的方法教程》本文详细介绍了如何在Ubuntu虚拟机中固定IP地址,包括检查和编辑`/etc/apt/sources.list`文件、更新网络配置文件以及使用Networ... 1、由于虚拟机网络是桥接,所以ip地址会不停地变化,接下来我们就讲述ip如何固定 2、如果apt安

linux进程D状态的解决思路分享

《linux进程D状态的解决思路分享》在Linux系统中,进程在内核模式下等待I/O完成时会进入不间断睡眠状态(D状态),这种状态下,进程无法通过普通方式被杀死,本文通过实验模拟了这种状态,并分析了如... 目录1. 问题描述2. 问题分析3. 实验模拟3.1 使用losetup创建一个卷作为pv的磁盘3.