ip_conntrack_max值的疑问
/proc/sys/net/ipv4/ip_conntack_max控制ip_conntrack跟踪的最大连接数,但是该值设成很大,像1000000,然后再使用iptables进行连接状态跟踪,对系统有影响不?好象这个值跟状态跟踪表的hash数有关,但设太大到底有何副作用,还望指点一二. 有影响, /proc 下的值不能没有理由的随意调大, 一般造成内存使用不合理.
ip_conntrack_max对系统性能的影响可参考这里:[url]http://www.wallfire.org/misc/netfilter_conntrack_perf.txt[/url] 翻译：NetDC <fjdc AT 163 DOT com>
如果您有什么好的想法可以和我交流。
转载注明出处，谢谢。
Netfilter conntrack 性能调整，v0.6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herv?Eychenne <rv _AT_ wallfire _DOT_ org>
这篇文档说明了对netfilter conntrack（还有NAT）性能调整时你必须知道的一些事情。
本文档最新版可以在下面这个地址找到：
[url]http://www.wallfire.org/misc/netfilter_conntrack_perf.txt[/url]
------------------------------------------------------------------------------
这里我们可以调整两个参数：
－允许的最大跟踪连接条目，在这篇文档中我们叫作CONNTRACK_MAX
－存储跟踪连接条目列表的哈西表的大小，在这篇文档中我们叫做HASHSIZE（下面是这个结构的描述）
CONNTRACK_MAX是在内核内存中netfilter可以同时处理的“任务”（连接跟踪条目）。
一个跟踪连接的条目是存储在一个链接起来的列表的一个节点上，每个列表都是一个哈西表的元素。因此每个哈西表的条目（也叫一个桶－bucket）包含了一个链接起来的跟踪连接条目。
要访问一个特定包的跟踪连接条目，内核必须：
－针对一个包中的已经定义的一些字符计算哈西值。这是一个不间断的计算。
这个哈西值就会被当作哈西表的索引来使用，而跟踪连接条目的列表就存储在这里。
－反复的查看链接列表中的跟踪连接条目以找到匹配的那一个。
这是一个耗资源的操作，依赖于列表的大小（也依赖于列表中被操作的跟踪连接条目的位置）。
哈西表包含了HASHSIZE大小的链接条目。当条目满的时候（总的跟踪连接条目数达到了CONNTRACK_MAX），理想状态下，每个列表（在最优化的条件下）将包含大约CONNTRACK_MAX/HASHSIZE的条目数。
不管你是否有连接，哈西表都将占用一个固定大小的非交换内核内存。但是最大连接跟踪条目会检测最多可以存储多少条目（globally into the
linked lists），也就是说他们最多可以占用多少的内核内存。
这篇文档将给你一些关于为了达到最好的netfilter conntracking/NAT系统性能，如何调优HASHSIZE和CONNTRACK_MAX值的提示。
CONNTRACK_MAX和HASHSIZE的默认值
============================================
一般来说，CONNTRACK_MAX和HASHSIZE都会设置在“合理”使用的值上，依据可使用的RAM的大小来计算这个值。
CONNTRACK_MAX的默认值
------------------------------
在i386架构上，CONNTRACK_MAX = RAMSIZE (以bytes记) / 16384 =
RAMSIZE (以MegaBytes记) * 64，
因此，一个32位的带512M内存的PC在默认情况下能够处理512*1024^2/16384 = 512*64 = 32768个并发的netfilter连接。
但是真正的公式是：
CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32)
这里x是指针的bit数，（例如，32或者64bit）
请注意：
－默认的CONNTRACK_MAX值不会低于128
－对于带有超过1G内存的系统，CONNTRACK_MAX的默认值会被限制在65536（但是可以手工设置成更大的值）
HASHSIZE的默认值
-------------------------
通常，CONNTRACK_MAX = HASHSIZE * 8。这意味着每个链接的列表平均包含8个conntrack的条目（在优化的情况并且CONNTRACK_MAX达到的情况下），每个链接的列表就是一个哈西表条目（一个桶）。
在i386架构上，HASHSIZE = CONNTRACK_MAX / 8 =
RAMSIZE (以bytes记) / 131072 = RAMSIZE (以MegaBytes记) * 8。
举例来说，一个32位、带512M内存的PC可以存储512*1024^2/128/1024 =
512*8 = 4096 个桶（链接表）
但是真正的公式是：
HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes记) / 131072 / (x / 32)
这里x是指针的bit数，（例如，32或者64bit）
请注意：
－默认HASHSIZE的值不会小于16
－对于带有超过1G内存的系统，HASHSIZE的默认值会被限制在8192（但是可以手工设置成更大的值）
读取CONNTRACK_MAX和HASHSIZE
==================================
现在通过/proc文件系统我们可以在运行时读取CONNTRACK_MAX的值。
在Linux kernel 2.4.23版本前，使用：
# cat /proc/sys/net/ipv4/ip_conntrack_max
在Linux kernel 2.4.23版本后，使用：
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
(旧的 /proc/sys/net/ipv4/ip_conntrack_max是不建议使用的!)
当前的HASHSIZE总是可以在syslog信息中找到（对任何一个内核版本），桶（也就是HASHSIZE）的数目是在ip_conntrack初始化的时候显示出来的。
对于linux内核2.4.24以后，当前的HASHSIZE值可以在运行时使用下面的命令读取：
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
修改CONNTRACK_MAX和HASHSIZE
====================================
默认的CONNTRACK_MAX和HASHSIZE的值都会因主机的不同而不同，但你可以在只做防火墙的高负载的系统上增加他们。
因此CONNTRACK_MAX和HASHSIZE值如果需要的话可以手工更改。
读取桶是一个连续性的操作（我们的兴趣在于得到一个哈西列表），请记得内核需要不停的遍历一个链接的列表去查找一个跟踪连接条目。因此一个链接列表（CONNTRACK_MAX/HASHSIZE的值在优化的状态下并且达到上限）的平均值不能设置太大。这个比值默认值是8（当值是自动计算的时候）。
在系统有足够的内存并且性能真的很重要的时候，你可以试着使平均值是一个跟踪连接条目配一个哈西桶，这意味着HASHSIZE = CONNTRACK_MAX。
设置CONNTRACK_MAX
---------------------
跟踪连接的条目是存储在链接的表中的，因此最大的跟踪链接条目（CONNTRACK_MAX）可以很容易的动态调整。
linux内核2.4.23之前，使用：
# echo $CONNTRACK_MAX > /proc/sys/net/ipv4/ip_conntrack_max
linux内核2.4.23之后，使用：
# echo $CONNTRACK_MAX > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
这里$CONNTRACK_MAX是一个整数。
设置HASHSIZE
----------------
因为数学上的原因，哈西表占有固定的大小。因此HASHSIZE必须在哈西表被创建和开始填充之前就确定。
在linux内核2.4.21之前，必须使用素数作为哈西表的大小，而且要保证这个哈西表能够有效并通用。非素数的奇数或者其他的数值都是强烈不推荐使用的，因为这样哈西的分配不能达到最优化的状态。
从linux内核2.4.21（还有2.6内核）跟踪连接使用jenkins2b算法，这样就可以使用所有的数值，但是使用2^n次方运作的最有效。
如果netfilter的跟踪连接是被编译进内核中的，哈西表的大小就可以在编译的时候设置，或者（2.6内核之后）可以作为一个启动选项ip_conntrack.hashsize=$HASHSIZE。
如果netfilter的跟踪连接是编译成一个模块，哈西表的大小可以在加载模块的时候设置，使用下面的命令：
# modprobe ip_conntrack hashsize=$HASHSIZE
这里$HASHSIZE是一个整数。
一个理想的例子：只做防火墙的机器
------------------------------------
在理想的例子中，你有一台机器只做包过滤和NAT（也就是说，基本上没有用户空间的使用，至少不会有象代理这样会不断的耗费内存空间的东西......）
netfilter跟踪连接使用的内核内存大小是：
size_of_mem_used_by_conntrack (以bytes记) =
CONNTRACK_MAX * sizeof(struct ip_conntrack) +
HASHSIZE * sizeof(struct list_head)
－这里：sizeof(struct ip_conntrack)可以有很大的区别，依赖于机器的体系架构，内核版本和编译时间的配置。要想知道它的大小，可以查看ip_conntrack初始化时候kenel的日志信息。sizeof(struct ip_conntrack)在i386架构、 2.6.5内核上大约是300bytes，但是在2.6.10的内核上，这个值可以在352至192bytes之间变化！
－sizeof(struct list_head) = 2 * size_of_a_pointer
在i386上，size_of_a_pointer是4bytes。
因此在i386，2.6.5内核上，size_of_mem_used_by_conntrack大约是CONNTRACK_MAX * 300 + HASHSIZE * 8 (bytes)。
如果我们使HASHSIZE = CONNTRACK_MAX（如果我们将大部分的内存用来做防火墙的工作，参见“修改 CONNTRACK_MAX和HASHSIZE”部分），在i386架构、2.6.5内核上， size_of_mem_used_by_conntrack大概是CONNTRACK_MAX * 308 bytes。
现在我们假定你使用512M的内存拿来做一个只做防火墙的机器，并且使用128MB以外的内存来做跟踪连接，对于使用终端模式只做防火墙来说应该是足够的大的，例如：
你可以同时设置CONNTRACK_MAX和HASHSIZE大致如下：
(512 - 128) * 1024^2 / 308 =~ 1307315 (instead of 32768 for CONNTRACK_MAX,
and 4096 for HASHSIZE by default)。
对于linux2.4.21（和linux2.6），哈西算法最好使用“2的次方”大小（之前是使用素数）。
因此在这里我们可以将CONNTRACK_MAX和HASHSIZE设置成1048576（2^20）。
这样，你可以存储默认值32倍的跟踪连接条目，而且可以得到更好的跟踪连接性能。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
最后更新：2005年1月20日
修正历史：
Revision history:
0.6 Hashsize parameter can be set at boot time with Linux 2.6. Thanks to
Tobias Diedrich for pointing this out.
0.5 Added further notice about the varying length of the conntrack structure.
0.4 Since Linux 2.4.21, hash algorithm is happy with all sizes, not only
prime ones. However, power of 2 is best.
0.3 Various small precisions.
0.2 Information about Linux kernel versions and corresponding /proc entries.
(/proc/sys/net/ipv4/netfilter/ip_conntrack_{max,buckets}).
0.1 Initial writing, largely based on my discussions with Harald Welte
(netfilter maintainer) on the netfilter-devel mailing-list. Many thanks
to him!
页:
[1]