码迷,mamicode.com
首页 > 其他好文 > 详细

[Nginx笔记]关于线上环境CLOSE_WAIT和TIME_WAIT过高

时间:2014-05-26 18:28:19      阅读:388      评论:0      收藏:0      [点我收藏+]

标签:c   class   blog   code   a   com   

运维的同学和Team里面的一个同学分别遇到过Nginx在线上环境使用中会遇到TIME_WAIT过高或者CLOSE_WAIT过高的状态

先从原因分析一下为什么,问题就迎刃而解了。

 

首先是TIME_WAIT:

  理解一下TIME_WAIT状态产生的原因,这个问题已经被很多很多的书说烂了,但是为什么很多人还是不能解决,究其原因还是因为

大多数都是学术派,并没有真正的遇到过这样的问题,因为TIME_WAIT大量产生很多都发生在实际应用环境中。

TIME_WAIT产生的原因还是因为在通讯过程中服务端主动关闭造成的,在服务端发送了最后一个FIN包后,系统会等待 Double时间

MSL(Max Segment Lifetime)用于等待接受客户端发送过来的FIN_ACK和FIN,这段时间服务端的对应的socket的fd是不能够重新

利用的,这样在大量的短连接服务中,会出现TIME_WAIT过多的现象。

解决方案:

  调整TIME_WAIT超时时间

  

1
vi /etc/sysctl.conf

  

1
2
3
4
5
6
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
 
 
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
 
net.ipv4.tcp_fin_timeout = 20

 

其次是CLOSE_WAIT:

  CLOSE_WAIT产生的原因是客户端主动关闭,收到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;

 

[Nginx笔记]关于线上环境CLOSE_WAIT和TIME_WAIT过高,布布扣,bubuko.com

[Nginx笔记]关于线上环境CLOSE_WAIT和TIME_WAIT过高

标签:c   class   blog   code   a   com   

原文地址:http://www.cnblogs.com/Bozh/p/3752476.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!