主题:【求助】关于网站大量 Error 001 应对 -- 铁手

公告建议 导读 复 48 阅 36044

O 比较多数量的 FIN_WAIT1 铁手 字48 2012-01-04 19:44:38
O 奇怪的是,netstat里面的 铁手 字150 2012-01-04 19:53:46
O 查了一下,第一个是1,其余两个是0 铁手 字284 2012-01-04 19:56:22
O 这个脚本执行了老半天才出结果 铁手 字223 2012-01-04 20:01:18
O 我的猜测 2 代码ABC 字556 2012-01-04 20:15:58
O 你统计一下tcp连接中time_wait的比例 1 向前向前 字243 2012-01-04 20:57:38
O 协议解释——看看是否有帮助 1 代码ABC 字946 2012-01-04 22:27:01
O 试试限制单个IP最大并发连接和单位时间内最大允许新连接数 西电鲁丁 字98 2012-01-05 01:04:21
O 这个数据应该算正常的 2 季侯 字701 2012-01-05 01:13:51
O 出问题那个,绝大部分在WAIT1,一部分在TIME 铁手 字297 2012-01-05 02:10:51
O max值我已经增加过好几次,但是记录数不断增加 铁手 字287 2012-01-05 02:36:42
O 这个timeout_established是默认标准 代码ABC 字74 2012-01-05 03:20:42
O ip_conntrack 2 子功能 字2826 2012-01-05 05:02:33
O 不好意思,多打个了0 1 季侯 字860 2012-01-05 06:50:12
O ip_contrack中是历史记录,所以几天内累计出现 季侯 字83 2012-01-05 06:51:56
3641253 复 3640666
铁手
比较多数量的 FIN_WAIT1

和TIME_WAIT,相对而言,ESTABLISHED的数量并不多。


  • 本帖 1 回复
2012-01-04 19:44:38
2012-01-04 19:53:46
3641262 复 3641119
铁手
铁手`352`/bbsIMG/upload/face/352.gif`70`45489`39485`493309`正四品上:正议大夫|忠武将军`2003-05-03 11:59:57`0
奇怪的是,netstat里面的

Established状态 的不多。主要是 ip_conntrack 里面的记录数量在不断增加,而且大部分是“Established”,而这些“Established” time out 的时间又是比较长的。


  • 本帖 1 回复
2012-01-04 19:53:46
2012-01-04 19:56:22
3641264 复 3639447
铁手
铁手`352`/bbsIMG/upload/face/352.gif`70`45489`39485`493309`正四品上:正议大夫|忠武将军`2003-05-03 11:59:57`0
查了一下,第一个是1,其余两个是0

网上查了一下,似乎net.ipv4.tcp_tw_recycle=1这个比较容易导致问题,建议使用net.ipv4.tcp_tw_recycle = 1。我试试这个看看。

不过我估计还是没用,因为问题似乎不在 netstat 里面的内容,而是和 ip_conntract 相关,这两个似乎不一样。我的理解,后者是和防火墙有关系的,前者只是一般意义上的链接状态。


  • 本帖 1 回复
2012-01-04 19:56:22
2012-01-04 20:01:18
3641272 复 3640688
铁手
铁手`352`/bbsIMG/upload/face/352.gif`70`45489`39485`493309`正四品上:正议大夫|忠武将军`2003-05-03 11:59:57`0
这个脚本执行了老半天才出结果

cat /proc/net/ip_conntrack | awk '{print substr($5, index($5,"=")+1) }' | awk '{a[$1]+=1};END {for( i in a){print i,a[ i ] }}' | sort -n -k 2

结果里面,在某些 ip 后面,有几千的值。至少有500个IP,后面的数值在几十到几百之间。


  • 本帖 2 回复
2012-01-04 20:01:18
2012-01-04 20:15:58
3641291 复 3641262
代码ABC
代码ABC`20207`/bbsIMG/face/0012.gif`70`5901`8879`160370`从八品上:承奉郎|御武(侮)校尉`2007-10-25 19:14:32`0
我的猜测 2

手头没有iptables的详细资料。我的猜测是iptables里的established和Tcp的established概念不同。

iptables作为一个防火墙可能带有一个连接代理的功能。当连接进来时先代理连接(或者建立连接管理数据表项),之后再转发到TCP/IP的协议栈。这样从Iptable的established指的是防火墙处理的连接。而netstate看到的就是已经过滤的本机的TCP连接。具体的要看iptables的详细说明。如果我猜测正确的话,那些timeout值都是为了遵循TCP协议规定的默认值。可以很放心地根据实际情况缩短。

另外,看看规则上能不能过滤掉这些多余的established连接。

我是最近才正式开始在linux上干活,以上都是猜测,仅做参考。


2012-01-04 20:15:58
2012-01-04 20:57:38
3641344 复 3641264
向前向前向前向前`49043`/bbsIMG/face/0000.gif`70`3901`8388`79604`从二品:光禄大夫|镇军大将军`2009-12-08 21:59:57`0
你统计一下tcp连接中time_wait的比例 1

如果比例比较大,超过30%的话,设这个参数就是有用的。

每个tcp连接都会占用iptable的entry,所以连接数是第一重要的,要先解决连接数问题。然后可能是iptable的entry超时时间的控制。默认的conntrak超时时间比较长。不过这个要看你的iptables具体使用环境而定。


最后于2012-01-04 21:20:24改,共1次;
2012-01-04 20:57:38
2012-01-04 22:27:01
3641466 复 3641253
代码ABC
代码ABC`20207`/bbsIMG/face/0012.gif`70`5901`8879`160370`从八品上:承奉郎|御武(侮)校尉`2007-10-25 19:14:32`0
协议解释——看看是否有帮助 1

看看你那几千个连接的Ip是不是都在Time_wait或FIN_WAIT1上

这个状态多出现在慢速的连接上,服务器主动关闭连接发送完FIN标志后就处在FIN_WAIT1状态,直到收到客户端的ACK,之后收到客户端发来的FIN,并送出ACK后进入TIME_WAIT状态。处于TIME_WAIT状态的时间是最大包生存时间(MSL for Maximum Segment Lifetime)的两倍。因此一般是2分钟到4分钟时间。

如果连接速度慢那么处在FIN_WAIT1的时间就比较长,搞不好还收不到——如果客户端断掉,或者客户端程序/NAT路由器没有正确处理TCP优雅关闭问题,那么服务器会试图多次重新传送FIN,直到超过重传次数。这个时间甚至可能比TIME_WAIT还长。

影响这两个时间的参数大致有:

MSL——看什么系统可能是30秒也可能是120秒

TCP重试次数,有两个,一个是决定多少次报错,另一个是决定多少次关闭

还有一个是FIN_WAIT2的时间,这个是服务器收到客户端对自己FIN的ACK后进入等待客户端FIN的时间。对于WEB服务器来说这个可以很短(10秒就足够了,因为HTTP客户端肯定不会再发数据过来)

调整这些参数可以缩短上述状态的时间,从而快速释放连接。但是需要注意这些参数同时影响正常的通信


  • 本帖 1 回复
2012-01-04 22:27:01
2012-01-05 01:04:21
3641643 复 3641272
西电鲁丁西电鲁丁`34208`/bbsIMG/face/0000.gif`70`13089`583`56871`正六品上:朝议郎|昭武校尉`2009-05-05 23:49:03`0
试试限制单个IP最大并发连接和单位时间内最大允许新连接数

一般用户不应该有几千个连接的。

看看下面的网页,希望有帮助

http://www.heartdemon.com/post/154.html


  • 本帖 1 回复
2012-01-05 01:04:21
2012-01-05 01:13:51
3641659 复 3641272
季侯季侯`4358`/bbsIMG/face/0000.gif`70`5327`1765`39594`正二品:特进|辅国大将军`2004-12-05 05:57:11`0
这个数据应该算正常的 2

因为ip_contrack中保存的是一段时间类的链接情况,是累计值。

再执行一下

netstat -an | grep ESTABLISHED | awk '{print substr($5, 1 , index($5,":")-1) }'| awk '{a[$1]+=1};END {for( i in a){print i,a[ i ] }}' | sort -n -k 2

看一下当前链接状态ip统计。

ipconntrack的另外一些参数也看一下,

sysctl -a | grep conntrack

注意ip_conntrack_tcp_timeout_established和ip_conntrack_max。

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000

net.ipv4.netfilter.ip_conntrack_max = 1048576

建议和我设成一样,缩小timeout,增加max。

另外有个大杀器,既然是table full,那么可以在crontab中加一个任务,定时清理ip_conntrack,呵呵。

当然这样做比较暴力,一般合理调整上面两个值就够了。


  • 本帖 1 回复
2012-01-05 01:13:51
2012-01-05 02:10:51
3641703 复 3641466
铁手
铁手`352`/bbsIMG/upload/face/352.gif`70`45489`39485`493309`正四品上:正议大夫|忠武将军`2003-05-03 11:59:57`0
出问题那个,绝大部分在WAIT1,一部分在TIME

这个应该也是一个问题,但是感觉上还不致命。致命的可能是

/proc/sys/net/ipv4/netfilter/ip_conntrack_count

越来越大,超过

/proc/sys/net/ipv4/ip_conntrack_max

一旦超过,就马上出现 error 001。

max 值我已经加大过好几次,虽然还有空间可以加,不过总是想知道到底是什么因素导致 ip_conntrack_count 不断增加。


2012-01-05 02:10:51
2012-01-05 02:36:42
3641715 复 3641659
铁手
铁手`352`/bbsIMG/upload/face/352.gif`70`45489`39485`493309`正四品上:正议大夫|忠武将军`2003-05-03 11:59:57`0
max值我已经增加过好几次,但是记录数不断增加

我注意了一下,在里面的ip 地址里,有不少是只有最后一个值不同,前三位都一样,这个看起来比较邪门。

.ip_conntrack_tcp_timeout_established = 432000 为什么还保留在5天?按我的理解,如果是 web 服务,5分钟应该到头了吧。保留时间长,是不是为了防火墙能够在一段时间内,比如5天内的链接情况来进行判断?


  • 本帖 2 回复
2012-01-05 02:36:42
3641736 复 3641715
代码ABC
这个timeout_established是默认标准

默认TCP空连接是4天到期,这个数值可以缩短。Web服务器的话5分钟是没有问题的。


2012-01-05 03:20:42
2012-01-05 05:02:33
3641788 复 3638751
子功能子功能`40780`/bbsIMG/face/0000.gif`70`4`863`6330`正八品上:给事郎|宣节校尉`2009-08-30 19:43:36`0
ip_conntrack 2

原理如下,采取何种措施,看具体情况。下面的“【整理】中文网站里面很多内容值得参考。”回帖也说的很详细了。

外链出处

Adrian Otto

28.07.09 at 10:19

Some readers may be interested to know what ip_conntrack is in the first place, and why it fills up. If you run an iptables firewall, and have rules that act upon the state of a packet, then the kernel uses ip_conntrack to keep track of what state what connections are in so that the firewall rule logic can be applied against them. If you have a system that's getting a lot of network activity (high rates of connections, lots of concurrent connections, etc) then the table will accumulate entries.

The entries remain until an RST packet is sent from the original IP address. If you have a flaky network somewhere between you, and the clients accessing your server, it can cause the RST packets to be dropped due to the packet loss, and leave orphaned entries in your ip_conntrack table. This can also happen if you have a malfunctioning switch or NIC card... not necessarily a routing problem out on the internet somewhere.

Typically when I've seen this trouble crop up is when a server is the target of a DDoS attack. Filling up the ip_conntrack table is a relatively easy way to knock a server off line, and attackers know this.

As Major suggested, you can get short term relief by increasing the size of the table. However, these entries are held in memory by the kernel. The bigger you make the table, the more memory it will consume. That memory could be used by your server to serve requests if you really don't need the stateful firewall capability. Don't waste resources on this feature if you really don't need it.

Another option to consider is turning OFF iptables rules that use ip_conntrack so the state able is not used at all. Anything with "-m state" or "-t nat" can be turned off. If you want to just flush all your iptables rules you can do an "iptables -P" to set a default allow policy and "iptables -F" to flush all the rules. On an RHEL or CentOS system you can just do "service iptables stop".

Once iptables is no longer using ip_conntrack, you can reclaim the memory the table was using by unloading the related kernel modules.

rmmod ipt_MASQUERADE

rmmod iptable_nat

rmmod ipt_state

rmmod ip_conntrack

Then you will have an empty ip_conntrack that will stay empty. I mention this because a lot of sysadmins have hordes of iptables rules installed as a matter of course, and don't recognize the downside of having them present. You can still use iptables, but to avoid the use of ip_conntrack simply don't use rules based on stateful logic.

man iptables 查看 --ctstate 内容,如果防火墙没有依赖这些东西,可以把内核关于 ip_conntrack 的模块黑名单了。


铁手 接纳。
2012-01-05 05:02:33
2012-01-05 06:50:12
3641846 复 3641715
季侯季侯`4358`/bbsIMG/face/0000.gif`70`5327`1765`39594`正二品:特进|辅国大将军`2004-12-05 05:57:11`0
不好意思,多打个了0 1

上次就说了是43200.

另外,目前我们生产环境中net.ipv4.netfilter.ip_conntrack_tcp_timeout_established设置为43200.不过我们前端有防dds攻击的策略。

设为5分钟对web服务器来说是可以的,但是不利于保留历史记录进行分析,当然了,如果不需要分析,那就设小一点。

另外netstat分析当前连接数情况如何,如果怀疑那批类似的ip是攻击方,可以在iptable中过滤,但是我觉得可能性不多。真正的ddos攻击不会这么麻烦。

现在看来ddos的攻击可能性不大,因为并发量还真不算大,要真是ddos攻击应该就打死了;而且ddos攻击讲究瞬间上很大的量,一般要打死位置,不会象现在这样还能用,而且一般也就持续几天几周。

06年我有个朋友自己做了婴童产品的网站,做的不错,国内做到前几名,结果被竞争对手请黑客进行ddos攻击。攻击持续一周,流量一直很大,导致这一周网站都打不开。等一周以后,ddos攻击没了,客户也流失的差不多了,就倒闭了。

09年时候他又做了个电子产品的b2c网站,也受到了ddos攻击,这次他就扛住了:-)


2012-01-05 06:50:12
2012-01-05 06:51:56
3641849 复 3641643
季侯季侯`4358`/bbsIMG/face/0000.gif`70`5327`1765`39594`正二品:特进|辅国大将军`2004-12-05 05:57:11`0
ip_contrack中是历史记录,所以几天内累计出现

几千个链接是可能的。

所以关键还是要用netstat看看当前ESTABLISHED链接的分ip统计情况。


2012-01-05 06:51:56
帖内引用