linux端口TIME_WAIT以及close_wait过多-系统参数调整

http://www.linuxidc.com/Linux/2011-05/36374.htm

网络详细介绍

http://blog.csdn.net/xifeijian/article/category/1493871

情景描述：系统产生大量“Too many open files” 
原因分析：在服务器与客户端通信过程中，因服务器发生了socket未关导致的closed_wait发生，致使监听port打开的句柄数到了1024个，且均处于close_wait的状态，最终造成配置的port被占满出现“Too many open files”，无法再进行通信。 
close_wait状态出现的原因是被动关闭方未关闭socket造成，如附件图所示：

解决办法：有两种措施可行 
一、解决： 
原因是因为调用ServerSocket类的accept()方法和Socket输入流的read()方法时会引起线程阻塞，所以应该用setSoTimeout()方法设置超时（缺省的设置是0，即超时永远不会发生）；超时的判断是累计式的，一次设置后，每次调用引起的阻塞时间都从该值中扣除，直至另一次超时设置或有超时异常抛出。
比如，某种服务需要三次调用read()，超时设置为1分钟，那么如果某次服务三次read()调用的总时间超过1分钟就会有异常抛出，如果要在同一个Socket上反复进行这种服务，就要在每次服务之前设置一次超时。 
二、规避： 
调整系统参数，包括句柄相关参数和TCP/IP的参数；

注意： 
/proc/sys/fs/file-max 是整个系统可以打开的文件数的限制，由sysctl.conf控制； 
ulimit修改的是当前shell和它的子进程可以打开的文件数的限制，由limits.conf控制； 
lsof是列出系统所占用的资源,但是这些资源不一定会占用打开文件号的；比如：共享内存,信号量,消息队列,内存映射等,虽然占用了这些资源,但不占用打开文件号； 
因此，需要调整的是当前用户的子进程打开的文件数的限制，即limits.conf文件的配置； 
如果cat /proc/sys/fs/file-max值为65536或甚至更大，不需要修改该值； 
若ulimit -a ；其open files参数的值小于4096（默认是1024), 则采用如下方法修改open files参数值为8192；方法如下： 
1.使用root登陆，修改文件/etc/security/limits.conf 
vi /etc/security/limits.conf 添加 
xxx - nofile 8192 
xxx 是一个用户，如果是想所有用户生效的话换成 * ，设置的数值与硬件配置有关，别设置太大了。 
#<domain>      <type>     <item>         <value>

*         soft    nofile    8192 
*         hard    nofile    8192

#所有的用户每个进程可以使用8192个文件描述符。 
2.使这些限制生效 
确定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行： 
session required pam_limits.so 
然后用户重新登陆一下即可生效。 
3. 在bash下可以使用ulimit -a 参看是否已经修改：

一、 修改方法：（暂时生效,重新启动服务器后,会还原成默认值） 
sysctl -w net.ipv4.tcp_keepalive_time=600   
sysctl -w net.ipv4.tcp_keepalive_probes=2 
sysctl -w net.ipv4.tcp_keepalive_intvl=2

注意：Linux的内核参数调整的是否合理要注意观察，看业务高峰时候效果如何。

二、 若做如上修改后，可起作用；则做如下修改以便永久生效。 
vi /etc/sysctl.conf

若配置文件中不存在如下信息，则添加： 
net.ipv4.tcp_keepalive_time = 1800 
net.ipv4.tcp_keepalive_probes = 3 
net.ipv4.tcp_keepalive_intvl = 15

编辑完 /etc/sysctl.conf,要重启network 才会生效 
/etc/rc.d/init.d/network restart 
然后，执行sysctl命令使修改生效，基本上就算完成了。

------------------------------------------------------------ 
修改原因：

当客户端因为某种原因先于服务端发出了FIN信号，就会导致服务端被动关闭，若服务端不主动关闭socket发FIN给Client，此时服务端Socket会处于CLOSE_WAIT状态（而不是LAST_ACK状态）。通常来说，一个CLOSE_WAIT会维持至少2个小时的时间（系统默认超时时间的是7200秒，也就是2小时）。如果服务端程序因某个原因导致系统造成一堆CLOSE_WAIT消耗资源，那么通常是等不到释放那一刻，系统就已崩溃。www.linuxidc.com 因此，解决这个问题的方法还可以通过修改TCP/IP的参数来缩短这个时间，于是修改tcp_keepalive_*系列参数： 
tcp_keepalive_time： 
/proc/sys/net/ipv4/tcp_keepalive_time 
INTEGER，默认值是7200(2小时) 
当keepalive打开的情况下，TCP发送keepalive消息的频率。建议修改值为1800秒。

tcp_keepalive_probes：INTEGER 
/proc/sys/net/ipv4/tcp_keepalive_probes 
INTEGER，默认值是9 
TCP发送keepalive探测以确定该连接已经断开的次数。(注意:保持连接仅在SO_KEEPALIVE套接字选项被打开是才发送.次数默认不需要修改,当然根据情形也可以适当地缩短此值.设置为5比较合适)

tcp_keepalive_intvl：INTEGER 
/proc/sys/net/ipv4/tcp_keepalive_intvl 
INTEGER，默认值为75 
当探测没有确认时，重新发送探测的频度。探测消息发送的频率（在认定连接失效之前，发送多少个TCP的keepalive探测包）。乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒，也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值)

【检测办法】 
1. 系统不再出现“Too many open files”报错现象。

2. 处于TIME_WAIT状态的sockets不会激长。

在 Linux 上可用以下语句看了一下服务器的TCP状态(连接状态数量统计)：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

http://blog.csdn.net/xifeijian/article/details/44284675

1.服务器异常

如果服务器出了异常，十之八九都是以下两种情况：

1.服务器保持了大量TIME_WAIT状态

2.服务器保持了大量CLOSE_WAIT状态

 

因为linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，一旦达到句柄数上限，新的请求就无法被处理了，接着应用程序可能返回大量Too Many Open Files异常。

2.Close_Wait引发的问题

Close_Wait会占用一个连接，网络可用连接小。数量过多，可能会引起网络性能下降，并占用系统非换页内存。 尤其是在有连接池的情况下(比如HttpRequest)

会耗尽连接池的网络连接数，导致无法建立网络连接。

3.解决方法

下面来讨论下这两种情况的处理方法，优化系统内核参数解决TIME_WAIT可能很容易，可以通过修改/etc/sysctl.conf文件解决；

但是应对CLOSE_WAIT的情况还是需要从程序本身出发。因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。从上面的图可以看出来，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出FIN信号，一般原因都是TCP连接没有调用关闭方法。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行，一定程度上，可以使用TCP的KeepAlive功能，让操作系统替我们自动清理掉CLOSE_WAIT连接。

返回结果范例如下：

ESTABLISHED 1423 
FIN_WAIT1 1 
FIN_WAIT2 262 
SYN_SENT 1 
TIME_WAIT 962