nginx:TIME_WAIT过多或者CLOSE_WAIT过多的状态

发布时间:2017-6-29 9:50:43编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"nginx:TIME_WAIT过多或者CLOSE_WAIT过多的状态",主要涉及到nginx:TIME_WAIT过多或者CLOSE_WAIT过多的状态方面的内容,对于nginx:TIME_WAIT过多或者CLOSE_WAIT过多的状态感兴趣的同学可以参考一下。

1 起因

线上服务器nginx日志运行一段时间后,会报如下错误:

1024 worker_connections are not enough

一般做法是修改worker_connections。
但实际上:该服务是用于时间比较短的连接里,并且一天最多才4000个请求。不可能会耗尽worker_connections。
除非每次连接都没有释放对应的连接。

shell>netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
CLOSE_WAIT 802
ESTABLISHED 106
shell>lsof -n | grep “nginx对应的一个进程id”
MvLogServ 31125 mv 111u IPv4 76653578 0t0 TCP 10.1.138.60:8996->10.1.138.60:51977 (CLOSE_WAIT)
MvLogServ 31125 mv 112u IPv4 76659698 0t0 TCP 10.1.138.60:8996->10.1.138.60:52015 (CLOSE_WAIT)
MvLogServ 31125 mv 113u IPv4 76662836 0t0 TCP 10.1.138.60:8996->10.1.138.60:52042 (CLOSE_WAIT)
MvLogServ 31125 mv 114u IPv4 76663435 0t0 TCP 10.1.138.60:8996->10.1.138.60:52051 (CLOSE_WAIT)
MvLogServ 31125 mv 115u IPv4 76682134 0t0 TCP 10.1.138.60:8996->10.1.138.60:52136 (CLOSE_WAIT)
MvLogServ 31125 mv 116u IPv4 76685095 0t0 TCP 10.1.138.60:8996->10.1.138.60:52159 (CLOSE_WAIT)
……………….

TIME_WAIT:表示主动关闭,通过优化系统内核参数可容易解决。
CLOSE_WAIT:表示被动关闭,需要从程序本身出发。
ESTABLISHED:表示正在通信
则可知:nginx:CLOSE_WAIT过多的状态

2 解决

2.1 TIME_WAIT 通过优化系统内核参数可容易解决

TIME_WAIT大量产生很多通常都发生在实际应用环境中。
TIME_WAIT产生的原因:在通讯过程中A主动关闭造成的,
在A发送了最后一个FIN包后,系统会等待 Double时间
的MSL(Max Segment Lifetime)【注:按不同的操作系统有不同时间】用于等待接受B发送过来的FIN_ACK和FIN,
这段时间A的对应的socket的fd是不能够重新利用的,
这样在大量的短连接服务中,会出现TIME_WAIT过多的现象。

解决方案:
调整TIME_WAIT超时时间
vi /etc/sysctl.conf
#表示开启SYN Cookies。
#当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
net.ipv4.tcp_syncookies = 1
#表示开启重用。
#允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
net.ipv4.tcp_tw_reuse = 1
#表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
net.ipv4.tcp_tw_recycle = 1
#表示如果套接字由本端要求关闭。
#这个参数决定了它保持在FIN-WAIT-2状态的时间
#生效,如下命令
/sbin/sysctl -p


  • 注:
    已经主动关闭连接了为啥还要保持资源一段时间呢?
    这个是TCP/IP的设计者规定的,主要出于以下两个方面的考虑:

  1. 防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
    即:允许老的重复分节在网络中消逝。
  2. 可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。
    另外这么设计TIME_WAIT 会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。
    即:可靠地实现TCP全双工连接的终止。(确保最后的ACK能让被关闭方接收)

2.2 CLOSE_WAIT 需要从程序本身出发

LOSE_WAIT产生的原因是客户端B主动关闭,
服务器A收到FIN包,应用层却没有做出关闭操作引起的。
CLOSE_WAIT在Nginx上面的产生原因还是因为Nagle’s算法加Nginx本身EPOLL的ET触发模式导致。

ET出发模式在数据就绪的时候会触发一次回调操作,Nagle’s算法会累积TCP包,如果最后的数据包和

FIN包被Nagle’s算法合并,会导致EPOLL的ET模式只触发一次。
然而在应用层的SOCKET是读取返回0才代表链接关闭,
而读取这次合并的数据包时是不返回0的,
然后SOCKET以后都不会触发事件,
所以导致应用层没有关闭SOCKET,
从而产生大量的CLOSE_WAIT状态链接。
关闭TCP_NODELAY,在Nginx配置中加上

tcp_nodelay on;

3 总结

  • TIME_WAIT状态可以通过优化服务器参数得到解决。
    因为发生TIME_WAIT的情况是服务器自身可控的,
    要么就是对方连接的异常,要么就是自己没有迅速回收资源,
    总之不是由于自己程序错误导致的。

  • CLOSE_WAIT需要通过程序本身。
    如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。
    即在对方连接关闭之后,程序里没有检测到,或者程序没有关闭连接,于是这个资源就一直被程序占着。
    服务器对于程序抢占的资源没有主动回收的功能。只能修改程序本身。
    代码需要判断socket,一旦读到0,断开连接,read返回负,
    检查一下errno,如果不是AGAIN,就断开连接。

参考来源:
【1】http://www.cnblogs.com/Bozh/p/3752476.html
作者联系方式:Email:zhangbolinux@sina.com QQ:513364476
【2】http://itindex.net/detail/50213-%E6%9C%8D%E5%8A%A1%E5%99%A8-time_wait-close_wait


上一篇:在android使用httpclient时出现“SocketException: Broken Pipe”的解决方法
下一篇:加载较大的本地文件作为背景图时 防止内存溢出

相关文章

相关评论

本站评论功能暂时取消,后续此功能例行通知。

一、不得利用本站危害国家安全、泄露国家秘密,不得侵犯国家社会集体的和公民的合法权益,不得利用本站制作、复制和传播不法有害信息!

二、互相尊重,对自己的言论和行为负责。

好贷网好贷款