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

运维的同学和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超时时间

  

vi /etc/sysctl.conf

  

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;

上一篇:DirectX基础学习系列5 融合技术


下一篇:.NET项目版本号的小随笔