1. 监控的php错误日志，发现大量无法连接其他服务的错误

[21-Sep-2012 03:29:31 UTC] PHP Warning:

mysql_connect(): Can't connect to MySQL server on

'10.0.101.170' (4) in

/data/www/framework/lib/plugins/orm/parser/OrmMysqlParser.class.php

on line 185

[21-Sep-2012 03:29:31 UTC] PHP Warning:

mysql_connect(): Can't connect to MySQL server on

'10.0.101.170' (4) in

/data/www/framework/lib/plugins/orm/parser/OrmMysqlParser.class.php

on line 185

[21-Sep-2012 03:29:31 UTC] PHP Warning:

fsockopen(): unable to connect to

10.0.101.80:1218 (Connection timed out) in

/data/www/framework/modules/Queue/Queue.class.php on line 143

[21-Sep-2012 03:29:32 UTC] PHP Warning:

mysql_connect(): Can't connect to MySQL server on

'10.0.101.171' (4) in

/data/www/framework/lib/plugins/orm/parser/OrmMysqlParser.class.php

on line 185

[21-Sep-2012 03:29:34 UTC] PHP Warning:

mysql_connect(): Can't connect to MySQL server on

'10.0.101.171' (4) in

/data/www/framework/lib/plugins/orm/parser/OrmMysqlParser.class.php

on line 185

[21-Sep-2012 03:29:34 UTC] PHP Fatal error:

Uncaught exception 'RedisException' with message

'Redis server went away' in

/data/www/framework/lib/plugins/cache/RedisCache.class.php:78

2. 确认这些服务正常

因另一台相同配置和功能的服务器可以正常访问这些服务，并且没有php报错。

排除是其他服务器的原因。排除内网原因。

3.  检查该服务器的其他错误日志

当一个服务出错时，很有可能也留下了其他的蛛丝马迹。

查看最常用也最重要的日志 /var/log/message (系统日志)，发现如下信息：

Sep 20 21:29:59 hostname50 kernel: ip_conntrack: table full,

dropping packet.

Sep 21 11:20:47 hostname50 kernel: Removing netfilter NETLINK

layer.

Sep 21 11:20:47 hostname50 kernel: ip_tables: (C) 2000-2006

Netfilter Core Team

Sep 21 11:20:47 hostname50 kernel: Netfilter messages via

NETLINK v0.30.

Sep 21 11:20:47 hostname50 kernel: ip_conntrack version 2.4

(8192 buckets, 65536 max) - 304 bytes per conntrack

Sep 21 11:22:08 hostname50 kernel: printk: 232 messages

suppressed.

Sep 21 11:22:08 hostname50 kernel: ip_conntrack: table full,

dropping packet.

Sep 21 11:22:09 hostname50 last message repeated 9 times

Sep 21 11:22:13 hostname50 kernel: printk: 1368 messages

suppressed.

Sep 21 11:22:13 hostname50 kernel: ip_conntrack: table full,

dropping packet.

Sep 21 11:22:18 hostname50 kernel: printk: 1671 messages

suppressed.

Sep 21 11:22:18 hostname50 kernel: ip_conntrack: table full,

dropping packet.

Sep 21 11:22:23 hostname50 kernel: printk: 2079 messages

suppressed.

Sep 21 11:22:23 hostname50 kernel: ip_conntrack: table full,

dropping packet.

Sep 21 11:22:28 hostname50 kernel: printk: 2396 messages

suppressed.

4. 解决问题：

对于线上的服务器问题，解决问题是排在优先的。先解决问题，然后在进行进一步的优化和分析。

经过对问题的搜索，如下办法进行解决：

echo "262144" >

/proc/sys/net/ipv4/netfilter/ip_conntrack_max

echo "86400" >

/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

5. 分析和说明：

5.1 发现这个时间点，有进行iptables的重启操作。

5.2

看了这个帖子http://bbs.chinaunix.net/thread-2030285-1-1.html，发现该值的设置和iptables有关。

实验了下，果然重启iptables后，

/proc/sys/net/ipv4/netfilter/ip_conntrack_max 恢复成65535了。

5.3 重启iptables后保持该值的方法：修改iptables的启动脚本 /etc/init.d/iptables

，在start函数中，倒数第三行添加如下：

echo "262144" >

/proc/sys/net/ipv4/netfilter/ip_conntrack_max

echo "86400" >

/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

即：每次启动iptables时，都对该值进行设置。

6. 技术细节：

－允许的最大跟踪连接条目，在这篇文档中我们叫作CONNTRACK_MAX

－存储跟踪连接条目列表的哈西表的大小，在这篇文档中我们叫做HASHSIZE(下面是这个结构的描述)

CONNTRACK_MAX是在内核内存中netfilter可以同时处理的“任务”(连接跟踪条目)。

一个跟踪连接的条目是存储在一个链接起来的列表的一个节点上，每个列表都是一个哈西表的元素。因此每个哈西表的条目(也叫一个桶－bucket)包含了一个链接起来的跟踪连接条目。

要访问一个特定包的跟踪连接条目，内核必须：

－针对一个包中的已经定义的一些字符计算哈西值。这是一个不间断的计算。

这个哈西值就会被当作哈西表的索引来使用，而跟踪连接条目的列表就存储在这里。

－反复的查看链接列表中的跟踪连接条目以找到匹配的那一个。

这是一个耗资源的操作，依赖于列表的大小(也依赖于列表中被操作的跟踪连接条目的位置)。

哈西表包含了HASHSIZE大小的链接条目。当条目满的时候(总的跟踪连接条目数达到了CONNTRACK_MAX)，理想状态下，每个列表(在最优化的条件下)将包含大约CONNTRACK_MAX/HASHSIZE的条目数。

不管你是否有连接，哈西表都将占用一个固定大小的非交换内核内存。但是最大连接跟踪条目会检测最多可以存储多少条目(globally

into the linked lists)，也就是说他们最多可以占用多少的内核内存。

6.1 CONNTRACK_MAX和HASHSIZE的默认值

============================================

一般来说，CONNTRACK_MAX和HASHSIZE都会设置在“合理”使用的值上，依据可使用的RAM的大小来计算这个值。

6.1.1 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(但是可以手工设置成更大的值)

6.1.2 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(但是可以手工设置成更大的值)

6.2 读取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

6.3 修改CONNTRACK_MAX和HASHSIZE

====================================

默认的CONNTRACK_MAX和HASHSIZE的值都会因主机的不同而不同，但你可以在只做防火墙的高负载的系统上增加他们。

因此CONNTRACK_MAX和HASHSIZE值如果需要的话可以手工更改。

读取桶是一个连续性的操作(我们的兴趣在于得到一个哈西列表)，请记得内核需要不停的遍历一个链接的列表去查找一个跟踪连接条目。因此一个链接列表(CONNTRACK_MAX/HASHSIZE的值在优化的状态下并且达到上限)的平均值不能设置太大。这个比值默认值是8(当值是自动计算的时候)。

在系统有足够的内存并且性能真的很重要的时候，你可以试着使平均值是一个跟踪连接条目配一个哈西桶，这意味着HASHSIZE =

CONNTRACK_MAX。

6.3.1 设置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是一个整数。

6.3.2 设置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

7. 设置该值的方法

7.1 方法一：

echo 262144 >

/proc/sys/net/ipv4/netfilter/ip_conntrack_max

重新启动或切换系统级别即失效

可以写到/etc/rc.d/rc.local

7.2 方法二:

或是在 /etc/sysctl.conf 加入: net.ipv4.ip_conntrack_max =数值

重新启动有效

或使用指令: sysctl -w net.ipv4.ip_conntrack_max=数值

调用iptables前执行有效，也可以写到/etc/rc.d/rc.local

7.3 方法三:

在grub(或者lilo)的启动项中添加这个参数

kernel /boot/vmlinuz-2.4.18-3 ro root=/dev/hda1 hdc=ide-scsi

增加ip_conntrack.hashsize=数值

7.4 方法四:

重启iptables后保持该值的方法，修改iptables的启动脚本 /etc/init.d/iptables

，在start函数中，倒数第三行添加如下：

echo "262144" >

/proc/sys/net/ipv4/netfilter/ip_conntrack_max

echo "86400" >

/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

即：每次启动iptables时，都对该值进行设置。

8. ip_conntrack 相关查看命令

8.1 查看目前 ip_conntrack buffer 的使用状况

> grep ip_conntrack /proc/slabinfo

ip_conntrack  38358  64324  304  13  1 : tunables  54

27  8 :

slabdata  4948  4948

216

其中各个数字的含义为：

38358 the number of currently active objects

64324 the total number of available objects

304 the size of each object in bytes

13 the number of pages

with at least one active object

8.2 查出目前 ip_conntrack 记录最多的前十名 IP

> cat /proc/net/ip_conntrack | cut -d ' ' -f 10

| cut -d '=' -f 2 | sort | uniq -c | sort -nr | head -n 10

# 结果示例

#  6801 127.0.0.1

#  3993 122.224.190.62

#  1101 183.28.42.100

#  1004 222.73.254.95

#  549 120.42.98.143

#  483

114.135.81.206

#  460

123.154.46.196

#  431

222.242.121.122

#  410 125.33.21.174

#  312

222.211.218.59

8.3 查看目前的ip_conntrack相关设定的值：

> cat

/proc/sys/net/ipv4/netfilter/ip_conntrack_max

262144

> cat

/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

86400

9. 参考：

文章主要部分为永福原创，参考和借鉴了下面的网文，转载请注明。