Linux 大量的TIME_WAIT解决办法

发现存在大量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.
 
  如果你的服务器是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 时,同时使用这两个参数。

希望本站的知识能给您的工作、学习和生活带来方便和乐趣!

时间: 2024-10-12 17:20:30

Linux 大量的TIME_WAIT解决办法的相关文章

Centos7安装完后,重新启动系统提示Initial setup of CentOS Linux 7 (Core)的解决办法

今天安装完Centos7(CentOS-7-x86_64-DVD-1511.iso)后,重新启动系统提示Initial setup of CentOS Linux 7 (Core): 解决办法: 按提示步骤分别输入"1"."2"."q"."yes"即可.

linux 中文显示乱码解决办法

linux 中文显示乱码解决办法, 其实是有多种情况的, 有一部分是由于终端默认的设置造成的 vi /etc/sysconfig/i18n将内容改为LANG="en_US.UTF-8"SUPPORTED="zh_CN.UTF-8:zh_CN:zh:en_US.UTF-8:en_US:en"SYSFONT="latarcyrheb-sun16"将内容改为LANG="zh_CN.GB18030"LANGUAGE="zh_

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

一.原理 Windows编译的文件和Linux编译的文件格式不太一样,导致在Linux运行Shell脚本的时候会提示:/bin/bash^M: bad interpreter: 没有那个文件或目录. 原因是这样的: 1.Windows编译的文件结束时(回车+换行) 2.Linux编译的文件结束时(换行)             这样导致了Windows编译的文件放在Linux中会有[noeol]和[dos]的Flag标示. 如果运行CAT命令可以更直观的看到两个不同操作系统产生的文件差异,Win

通过cifs方式配置Windows共享文件给Linux使用 暨乱码解决办法

一.    准备环境 主机IP 平台 用户名 密码 192.168.0.185 Windows Xp 32bit Administrator A12345678 192.168.0.186 Linux 5.8 x64 root 123456 二.    Windows XP设置 2.1 关闭防火墙和安全软件等 2.2 设置文件夹共享 三.    Linux配置 3.1 修改字符配置 备注:使用SecureCRT软件连接,不要用putty 修改/etc/sysconfig/i18n文件 将 #LA

Linux终端乱码的解决办法

用SSH连接Linux时经常会遇到乱码的情况,痛苦了好久,在网上找到一个解决办法,编辑~/.bash_profile文件,加入下面两行: LANG="zh_CN.GB18030" LANGUAGE="zh_CN.GB18030" 用了一段时间后发现,这样更改后在VI中是正常显示中文的,可是其他地方还是乱码,比如重启服务等.为了让所有界面都正常显示中文,需要编辑/etc/sysconfig/i18n,将原来的LANG="zh_CN.UTF-8"注释

关于 xshell ssh登录 virtualbox linux虚拟机问题的解决办法

解决办法是: 在virtualbox里做端口转发 具体的请参考: http://www.2cto.com/os/201212/172712.html

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

CentOS 7 终端中文乱码解决办法: 1.使用vim编辑locale.config文件: vim /etc/locale.conf 2.将LANG="en_US.UTF-8"修改为: LANG="zh_CN.GB18030" LANGUAGE="zh_CN.GB18030:zh_CN.GB2312:zh_CN" SUPPORTED="zh_CN.UTF-8:zh_CN:zh:en_US.UTF-8:en_US:en" SY

codeblocks linux编译告警乱码解决办法

现场描述: 近期服务器上的codeblocks编译告警日志乱码,本来warning级别的告警都变成了error级别,满篇红色,完全没法看是什么问题.如下图所示: 解决办法: 1.Settings->Enviromet->Enviroment Variables 2.Add  "LC_ALL" with value "C" 3.->Set Now -> Ok 如图所示:

Linux常见bug及解决办法(2019-10-20)

1.  物理机可以ping通其他域名,虚拟机之间也可以ping通,但物理机无法ping通虚拟机? 解决办法:修改物理机与虚拟机的网络连接IP. 若物理机与虚拟机通过NAT模式连接,则需修改VMnet8的IP: 原文地址:https://www.cnblogs.com/garacy/p/11711511.html