centos系统大量time wait占用的解决

betacat 发布于2019-07-01 11:22 / 2589人阅读

摘要：发现存在大量状态的连接通过调整内核参数解决编辑文件，加入以下内容然后执行让参数生效。当出现等待队列溢出时，启用来处理，可防范少量攻击，默认为，表示关闭表示开启重用。

统计在一台前端机上高峰时间TCP连接的情况，统计命令：
netstat -n | awk "/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}"

除了ESTABLISHED，可以看到连接数比较多的几个状态是：FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV和LAST_ACK；下面的文章就这几个状态的产生条件、对系统的影响以及处理方式进行简单描述。

发现存在大量TIME_WAIT状态的连接
tcp 0 0 127.0.0.1:3306 127.0.0.1:41378 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41379 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39352 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39350 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:35763 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39372 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39373 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41176 TIME_WAIT

通过调整内核参数解决
vi /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

然后执行/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修改系統默认的TIMEOUT时间

修改之后，再用命令查看TIME_WAIT连接数
netstat -ae|grep “TIME_WAIT” |wc –l

发现大量的TIME_WAIT 已不存在，mysql进程的占用率很快就降下来的，网站访问正常。
不过很多时候，出现大量的TIME_WAIT状态的连接，往往是因为网站程序代码中没有使用mysql.colse()，才导致大量的mysql TIME_WAIT.

根据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_MACHINESYSTEMCurrentControlSetServicesTcpipParameters,添加名为TcpTimedWaitDelay的

DWORD键,设置为60,以缩短TIME_WAIT的等待时间

http://kerry.blog.51cto.com/1...

修改之后，再用

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进程的占用率很快就降下来的，各网站访问正常！！

以上只是暂时的解决方法，最后仔细巡查发现是前天新上线的一个系统，程序代码中没有使用mysql.colse()，才导致大量的mysql TIME_WAIT

服务器托管云服务器 TIME_WAIT 大量数据存储的解决方案 centos查看端口占用内存占用高怎么解决

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/30166.html

服务器TIME_WAIT和CLOSE_WAIT分析和解决办法

摘要：服务器出现异常最长出现的状况是服务器保持了大量的状态。此时主动关闭一方必须保持一个有效的状态下维持状态信息，以便可以重发。这就意味着，一个成功建立的连接，必须使得之前网络中残余的数据报都丢失了。，维持这些状态给服务器端带来巨大的负担。 showImg(https://segmentfault.com/img/bV9DQk?w=732&h=563); showImg(https://se...

LeanCloud 2019-07-25 14:15 评论0 收藏0
服务器TIME_WAIT和CLOSE_WAIT分析和解决办法

摘要：服务器出现异常最长出现的状况是服务器保持了大量的状态。此时主动关闭一方必须保持一个有效的状态下维持状态信息，以便可以重发。这就意味着，一个成功建立的连接，必须使得之前网络中残余的数据报都丢失了。，维持这些状态给服务器端带来巨大的负担。 showImg(https://segmentfault.com/img/bV9DQk?w=732&h=563); showImg(https://se...

helloworldcoding 2019-07-24 10:45 评论0 收藏0
服务器TIME_WAIT和CLOSE_WAIT分析和解决办法

摘要：服务器出现异常最长出现的状况是服务器保持了大量的状态。此时主动关闭一方必须保持一个有效的状态下维持状态信息，以便可以重发。这就意味着，一个成功建立的连接，必须使得之前网络中残余的数据报都丢失了。，维持这些状态给服务器端带来巨大的负担。 showImg(https://segmentfault.com/img/bV9DQk?w=732&h=563); showImg(https://se...

Faremax 2019-06-21 15:22 评论0 收藏0
[tcp] WEB服务,Linux下的内核参数调优

摘要：如果客户端发送了最后的报文不进入而是立即释放连接，那么就无法收到客户端重发的报文段。前言:web类应用一般会部署像nginx、tomcat、php等应用程序，使用默认的内核参数设置满足大部分场景，如果优化内核参数，也可以释放不少服务器性能，尤其是在高并发下一.SYN状态的内核参数调优大量SYN_SENT这种是主动连接服务端，而未得到响应，也就是SYN超时，一般是服务端根本不存在或...

waruqi 2019-08-08 11:58 评论0 收藏0
记一次ZABBIX监控JMX故障

摘要：最近偶然发现线上其中一个服务的图形没有出来，点开发现报了一个错初步怀疑是端口占用，然后看了端口，发现端口并没有被占用。在网络下，会导致大量的连接建立错误。看来，出现问题的时候一定要考虑全面，不然就会埋下隐患。最近偶然发现线上其中一个服务的zabbix图形没有出来，点开发现报了一个错： java.rmi.ConnectIOException: error during JRMP con...

SwordFly 2019-07-31 14:56 评论0 收藏0