1. 首页>
  2. 腾讯云代理

[经验分享] 一个解决time_wait&time_close问题的经典案例

腾讯云 2017年04月26日 浏览566

腾讯云代理 腾讯云直播申请 游戏上云

摘要:

一.问题描述
  网站(linux-apache)打不开,登陆数据库服务器(windows),发现很卡
二.定位过程
step1 重启了下服务器
进入系统后,没过一会问题依旧
step2 查看了系统进程
发现mysql占用率达到99%,可以肯定的是mysql连接出现问题
netstat -an
192.168.12.13:3306      192.168.12.12:30443      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30444      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30445      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30446      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30447      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30448      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30449      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30450      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30451      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30452      TIME_WAIT
… …
step3 调整mysql服务器参数
     根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务. TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证.
      在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名为TcpTimedWaitDelay的DWORD键,设置为60,以缩短TIME_WAIT的等待时间
step4 调整web服务器内核参数
登陆到web服务器(linux) netstat -ae |grep mysql
tcp        0      0 aaaa:53045               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53044               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53051               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53050               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53049               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53048               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53055               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53054               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53053               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53052               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53059               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53058               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53057               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53056               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53063               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53062               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53061               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53060               192.168.12.3:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53067               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53066               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53065               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53064               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa53071               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53070               192.168.12.13:mysql           TIME_WAIT   root       0
tcp        0      0 aaaa:53069               192.168.12.13:mysql           TIME_WAIT   root       0
发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决,
vi /etc/sysctl.conf

编辑文件,加入以下内容:
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
然后执行 /sbin/sysctl -p 让参数生效。
上面各参数的解释
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 = 1024 65000
//表示用于向外连接的端口范围。缺省情况下很小: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套接字拖死。


step5 配置生效
执行以下命令使配置生效:
/sbin/sysctl -p
step6 查看调整效果
再次web服务器上查看建立的链接
netstat -ae|grep mysql
tcp        0      0 aaaa:50408               192.168.12.13:mysql           ESTABLISHED nobody     3224651
tcp        0      0 aaaa:50417               192.168.12.13:mysql           ESTABLISHED nobody     3224673
tcp        0      0 aaaa:50419               192.168.12.13:mysql           ESTABLISHED nobody     3224675
发现大量的TIME_WAIT 已不存在,mysql进程的占用率很快就降下来的,各网站访问正常!!


三.小结
3.1 TCP状态机
在服务器的日常维护过程中,会经常用到下面的命令:
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'   
它会显示例如下面的信息:
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1
常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。
具体每种状态什么意思,其实无需多说,看看下面这种图就明白了,注意这里提到的服务器应该是业务请求接受处理的一方:
这么多状态不用都记住,只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:
1.服务器保持了大量TIME_WAIT状态
2.服务器保持了大量CLOSE_WAIT状态
因为linux分配给一个用户的文件句柄是有限的而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,应用崩溃。。。


3.2 上述两种现象的解决之道
  下面来讨论下这两种情况的处理方法,网上有很多资料把这两种情况的处理方法混为一谈,以为优化系统内核参数就可以解决问题,其实是不恰当的,优化系统内核参 数解决TIME_WAIT可能很容易,但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法:
1.服务器保持了大量TIME_WAIT状态
  这种情况比较常见,一些爬虫服务器或者WEB服务器(如果网管在安装的时候没有做内核参数优化的话)上经常会遇到这个问题,这个问题是怎么产生的呢?
从 上面的示意图可以看得出来,TIME_WAIT是主动关闭连接的一方保持的状态,对于爬虫服务器来说他本身就是“客户端”,在完成一个爬取任务之后,他就 会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment lifetime)时间之后,彻底关闭回收资源。为什么要这么做?明明就已经主动关闭连接了为啥还要保持资源一段时间呢?这个是TCP/IP的设计者规定 的,主要出于以下两个方面的考虑:
1.防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
2. 可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。
2.服务器保持了大量CLOSE_WAIT状态
休息一下,喘口气,一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别,没想到越挖越深,这也是写博客总结的好处,总可以有意外的收获。
  TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。
但 是CLOSE_WAIT就不一样了,从上面的图可以看出来,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程 序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直 被程序占着。个人觉得这种情况,通过服务器内核参数也没办法解决,服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。
  来举个例子:服 务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完 资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设 请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了。
  所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在服务器程序里头啊。



腾讯云服务商邀请关注:

http://partners.qcloud.com/invitation/99377079157835da208bd0

关注服务商的链接,提供下您关注的QQ,我们这边审核下即可快速回复您的工单问题与技术支持! 感谢您的信任与支持!

auto_1452.png

腾讯云技术交流群


ps:本站信息来源于 bbs.qcloud.com

相关文章

在线客服
淘宝购买
腾讯云直播申请 title=
+成为腾讯云VIP客户 腾讯云直播申请 客服电话

15818558013

0755-33940501-803

0755-33940501-808