apache服务器中出现大量的time_wait的解决方法

发布时间:2019-09-08编辑:脚本学堂
本文介绍下,linux中apache服务器出现大量的time_wait信息,应该如何解决呢?请参考本文给出的方法吧。

公司最近新增的一批apache/ target=_blank class=infotextkey>apache服务器上线以来,用netstat -an命令发现服务器中有大量状态为TIME-WAIT的TCP连接。
用/sbin/sysctl -a查看了一下linux的各项内核参数,决定修改其中的两项参数,以达到减少TCP连接中TIME-WAIT sockets的目的。

操作方法如下:
vi /etc/sysctl.conf

编辑/etc/sysctl.conf文件,增加四行:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000

说明:
net.ipv4.tcp_syncookies = 1 #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
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 = 30 #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。
net.ipv4.ip_local_port_range = 102465000 表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。默认为 180000,改为5000。对于Apache、nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于Squid,效 果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。

再执行以下命令,让修改结果立即生效:
/sbin/sysctl -p

查看服务器的TCP状态:
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

返回结果:
ESTABLISHED 1423
FIN_WAIT1 1
FIN_WAIT2 262
SYN_SENT 1
TIME_WAIT 962

效果:处于TIME_WAIT状态的sockets从原来的10000多减少到1000左右。处于SYN_RECV等待处理状态的sockets为0,原来的为50~300。

附,TIME_WAIT状态的意义:

客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口状态为TIME_WAIT

是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢?
有没有什么情况使主动关闭的socket直接进入CLOsed状态呢?

主动关闭的一方在发送最后一个 ack 后
就会进入 TIME_WAIT 状态,停留2MSL(max segment lifetime)时间,这个是TCP/IP必不可少的,也就是“解决”不了的。

主要有两个原因
1,防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
2,可靠的关闭TCP连接
在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。TIME_WAIT 并不会占用很大资源的,除非受到攻击。还有,如果一方 send 或 recv 超时,就会直接进入 CLOSED 状态。

>>>您可能感兴趣的文章:
如何解决linux Time_wait过多的问题
解决系统中TIME_WAIT过多的问题
大量tcp端口处于TIME_WAIT状态的解决方法
linux中出现大量的TIME_WAIT连接的解决方法
大量TIME_WAIT的解决办法
系统中出现大量的TIME_WAIT的解决办法