转自：http://www.cnblogs.com/Bozh/p/3752476.html
运维的同学和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;