发现存在大量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_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名为TcpTimedWaitDelay的
DWORD键,设置为60,以缩短TIME_WAIT的等待时间

http://kerry.blog.51cto.com/172631/105233/

修改之后,再用
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 

如果你的服务器是Windows平台,可以修改下面的注册表键值:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e

此值是TIME_WAIT状态的最长时间。缺省为240秒,最低为30秒,最高为300秒。建议为30秒。
 
注释:

1,TCP结束的过程如下:

Server                             Client

-------------- FIN -------------->  server: fin_wait_1

<------------- ACK --------------- client: close_wait  server:fin_wait_2

<------------- FIN  --------------- client发出fin之后就关闭

-------------- ACK ------------->  server发出ack后进入time_wait状态

Time_Wait的默认时间是2倍的MLS,就是240秒钟。MLS是TCP片在网上的最长存活时间。
TIME_Wait的主要作用是保证关闭的TCP端口不立即被使用。因为当网络存在延迟时,可能当某个端口被关闭后,网络中还有一些重传的TCP片在发向这个端口,如果这个端口立即建立新的TCP连接,则可能会有影响。所以使用2倍的MSL时间来限制这个端口立即被使用。

现在的问题在于,4分钟的时间有点长。
因此,Time_wait的影响,我想,首先每个TCP连接都各自有个数据结构,叫TCP Control Block.Time_wait的时候这个数据结构没有被释放。所以当有太多的TCP连接时,内存可能会被占用很多。
 
 
 
2,To ValorZ:TIME_WAIT状态也称为2MSL等待状态,而不是2MLS,笔误吧!

每个TCP报文在网络内的最长时间,就称为MSL(Maximum Segment Lifetime),它的作用和IP数据包的TTL类似。

RFC793指出,MSL的值是2分钟,但是在实际的实现中,常用的值有以下三种:30秒,1分钟,2分钟。

注意一个问题,进入TIME_WAIT状态的一般情况下是客户端,大多数服务器端一般执行被动关闭,不会进入TIME_WAIT状态,当在服务器端关闭某个服务再重新启动时,它是会进入TIME_WAIT状态的。

举例:
1.客户端连接服务器的80服务,这时客户端会启用一个本地的端口访问服务器的80,访问完成后关闭此连接,立刻再次访问服务器的80,这时客户端会启用另一个本地的端口,而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。

2.客户端连接服务器的80服务,这时服务器关闭80端口,立即再次重启80端口的服务,这时可能不会成功启动,原因也是服务器的连接还处于TIME_WAIT状态。

windows

TcpTimedWaitDelay和MaxUserPort设置
描述:确定 TCP/IP 可释放已关闭连接并重用其资源前,必须经过的时间。
关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期(2MSL)状态。
此时间期间,重新打开到客户机和服务器的连接的成本少于建立新连接。
减少此条目的值允许 TCP/IP 更快地释放已关闭的连接,为新连接提供更多资源。如果运行的应用程序需要快速释放和创建新连接,而且由于 TIME_WAIT 中存在很多连接,导致低吞吐量,则调整此参数。
如何查看或设置: 使用 regedit 命令访问 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注册表子键并创建名为 TcpTimedWaitDelay 的新 REG_DWORD 值。
将此值设置为十进制 30,其为十六进制 0x0000001e。
该值将等待时间设置为 30 秒。
停止并重新启动系统。 缺省值:0xF0,它将等待时间设置为 240 秒(4 分钟)。
建议值:最小值为 0x1E,它将等待时间设置为 30 秒。
MaxUserPort 描述:确定在应用程序从系统请求可用用户端口时,TCP/IP 可指定的最高端口号。
如何查看或设置: 使用 regedit 命令访问 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注册表子键并创建名为 MaxUserPort 的新 REG_DWORD 值。
停止并重新启动系统。
缺省值:无 建议值:至少十进制 32768。
注:当在 Windows NT 或 Windows 2000 操作系统上调整 WebSphere Application Server 时,同时使用这两个参数。
希望本站的知识能给您的工作、学习和生活带来方便和乐趣!  

http://blog.csdn.net/gzh0222/article/details/8491178

linux 大量的TIME_WAIT解决办法的更多相关文章

  1. linux 大量的TIME_WAIT解决办法(转)

    发现存在大量TIME_WAIT状态的连接tcp        0      0 127.0.0.1:3306              127.0.0.1:41378             TIME ...

  2. (原创)Windows下编译的Shell脚本不能再Linux中运行的解决办法

    一.原理 Windows编译的文件和Linux编译的文件格式不太一样,导致在Linux运行Shell脚本的时候会提示:/bin/bash^M: bad interpreter: 没有那个文件或目录. ...

  3. Linux服务器 大量的CLOSE_WAIT、TIME_WAIT解决办法

    http://itindex.net/detail/50213-%E6%9C%8D%E5%8A%A1%E5%99%A8-time_wait-close_wait http://itindex.net/ ...

  4. Linux终端乱码的解决办法

    用SSH连接Linux时经常会遇到乱码的情况,痛苦了好久,在网上找到一个解决办法,编辑~/.bash_profile文件,加入下面两行: LANG="zh_CN.GB18030" ...

  5. 图形报表部署在Linux下出现乱码解决办法

     客户问题: 客户的操作系统SUSE LINUX Enterprise Server 10 (i586) 64位,服务器 weblogic8.1, JDK版本:jdk1.4.系统中只有图形报表展示 ...

  6. [Linux] - CentOS中文乱码解决办法

    CentOS 7 终端中文乱码解决办法: 1.使用vim编辑locale.config文件: vim /etc/locale.conf 2.将LANG="en_US.UTF-8"修 ...

  7. Linux 离奇磁盘爆满解决办法

    问题原因&通用解决步骤 频繁收到es数据节点磁盘使用监控告警,到es上查看,磁盘使用率40%,因此登录该告警服务器,df -h 查看,如图 发下根目录使用超过了80%,因此持续告警,按照以往办 ...

  8. 发现大量的TIME_WAIT解决办法

    存在一定的TIME_WAIT是正常的,个人认为如果超过了连接数的比例就不是很正常 服务器端与客户端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口状态变为TIME_WAIT.主动关闭的一方 ...

  9. 发现大量的TIME_WAIT解决办法 -- 修改内核参数

    今天早上一上班,有同事就反映公司好几个网站都打不开,登陆数据库 服务器(windows),发现很卡,于是重启了下服务器,进入系统后,没过一会问题依旧,查看了下系统进程,发现mysql占用率达到99%, ...

随机推荐

  1. IE点击tif,tiff文件,提示打开而不是查找

    IE点击tif或者tiff后缀的文件,提示窗口没有显示打开,而是现实查找.而下载到本地后,又能用acdsee之类的软件双击打开.在tif文件右键-属性中选择了打开程序,在IE中还是依然. 搜索网络资料 ...

  2. ionic 运行过程中动态切换API服务器地址

    ionic 运行过程中动态切换API服务器地址 keywords: ionic,phonegap,cordova,网络制式,动态切换,变更,API,服务器地址,$resource,localstora ...

  3. 设计模式之建造者模式(Builder)

    建造者模式原理:建造模式主要是用于产生对象的各个组成部分,而抽象工厂模式则用于产生一系列对象,建造者模式而且要求这些对象的组成部分有序. 代码如下: #include <iostream> ...

  4. ffmpeg iOS 编译

    编译模拟器版本1 到https://github.com/yuvi/gas-preprocessor下载gas-preprocessor.p并拷贝到/usr/sbin目录中2 下载ffmpeg源码.h ...

  5. iOS Automation Test

    google resource for KIF: http://www.oschina.net/translate/ios-ui-testing-with-kif

  6. TJU 4087. box

    题目:Tuhao and his two small partners participated in the tournament.But in the end, they lost the cha ...

  7. android SDK更新

    在proxy.ini里的[profile]下加上如下配置即可更新android SDK了 dl-ssl.google.com = nofakehttps Oct 26, 2014 #2 2828qw. ...

  8. 全自动化的 Android 编译管线

    [编者按]Nicolas Frankel 是 hybris 的高级顾问, 在Java / J2EE 领域拥有超过10年的管理经验,本文阐述了他在使用自动化工序去构建 Android 应用程序遇到的一些 ...

  9. UITableView中cell的圆角(第一个和最后一个)

    , , _width, _height)];     ;     view.clipsToBounds = YES;          _viewDetal = [[UIView alloc]init ...

  10. POJ 2070

    #include<iostream> #include<stdio.h> using namespace std; int main() { //freopen("a ...