timewait过多怎么办(time wait过多如何处理)

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

大家好，今天来介绍timewait过多怎么办(time_wait过多的原因和解决方案)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

TIME_WAIT过高的处理

相信很多人都遇到过服务器出现大量TIME_WAIT的情况，大多数的解决办法是sysctl修改如下参数

net.ipv4.tcp_timestamps = 1 #上述两项生效的前提是TCP连接两端都要启用TCP时间戳

过一会发现TIME_WAIT数量直线下降后，服务貌似也没出扰裂问题，ok问题解决！其实不然。想真正理解所谓“大量的TIME_WAIT的问题”，我们要先理解TIME_WAIT。

TIME_WAIT是有友好的，不是多余的，是主动关闭TCP连接的一方在调用socker的close操作后最终会进入TIME_WAIT状态。服务器在处理客户端请求的时候，如果你的程序设计为服务器主动关闭，那么你才有可能需要关注这个TIMEWAIT状态过多的问题。如果你的服务器设计为被动关闭，那么你首先要关注的是CLOSE_WAIT。

换句话说：在一台负载均衡的服务器上(以Nginx为例)，客户端向Nginx的请求，作为服务器来看属于被动连接；Nginx向Web服务器的请求属于主动连接。在讨论TIME_WAIT优化时，我们应该关注的是主动连接，即Nginx对Web服务器的连接。

1、防止前一个连接延迟的数据被后面复用的连接错误的接收；

2、可靠的关闭TCP连接；

关于TIME_WAIT作用的深入理解需要配合Socket连接五元组、RFC 793等概念，本文不重点讨论，感兴趣的童鞋请移步 老男孩博客 。

内核里有保存所有连接的一个hash table，这个hash table既包含TIME_WAIT状态的连接，也包含其它状态的连接。主要用于有新的数据到来的时候，从这个hash table里快速找到这条连接。还有一个hash table用来保存所有的bound ports，主要用于可以快速的找到一个可用的端口或者随机端口。

因此，内核保存这些数据必然会占用一定的内存，同理每次找到一个随机端口需要遍历一遍bound ports，必然需要一些CPU时间!

TIME_WAIT很多，既占内存又耗CPU，但其实进一步研究，1万条TIME_WAIT连接，也就多消耗1M左右的内存，对于现在的服务器来说已经不算什么。至于CPU，也不至于因为1万多的hash item就担忧。最起码在TIME_WAIT达到几千的量级上不必过多紧张，因为TIME_WAIT所占用的内存很少很少，同时记录和寻找可用的local port所消耗的CPU也基本可以忽略。

TIME_WAIT的存在是很重要的，如果强制忽略TIME_WAIT，还是有很高的机率，造成数据粗乱，或者短暂性的连接失败。比较直接的现象是，通过NAT后的IP大量访问服务的时候容易出现静置几分钟后连接失败或者多个客户端同时访问有的访问频繁失败的情况。

还有一种情况是：在 客户端-服务器 一对一的时候，没有任何问题，但是当源IP是经过NAT后的地址或服务器在负载均缓知闭衡器后面时，源地址为同一ip假如恰巧先后两次连接源端口相同，这台服务器先后收到两个包，第一个包的timestamp被服务器保存着，第二个包又来了，一对比，发现第二个包的timestamp比第一个还老——客户端时间不一致。服务器基于PAWS，判断第二个包是重复报文，丢弃之。反映出来的情况就是在服务器上抓包，发现有SYN包，但服务器就是不回ACK包，因为SYN包已经被丢弃了。可用如下命令验证，查看输出里面的 packets rejects in established connections because of timestamp 一项的数量变化。

写了这么多，那么猛镇tw_recycle参数到底该怎么用呢？在这里，引用 老男孩博客 里给出的两个典型场景的配置方案作为参考

在这种情况下，因为负载均衡服务器对Web服务器的连接（注意，负载均衡器向Web服务器发起的主动连接），TIME_WAIT大都出现在负载均衡服务器上，所以，在负载均衡服务器上的配置：

在这种情况下，Web服务器变成TIME_WAIT的重灾区。负载均衡对Web服务器的连接，由Web服务器首先关闭连接，TIME_WAIT出现在Web服务器上；Web服务器对DB服务器的连接，由Web服务器关闭连接，TIME_WAIT也出现在它身上，此时，负载均衡服务器上的配置：

http://blog.oldboyedu.com/tcp-wait/

http://blog.chinaunix.net/uid-24517549-id-4048652.html

http://blog.chinaunix.net/uid-28337979-id-4107112.html

写在最后，内核的优化不能想当然，需要配合相应的业务场景。当然，这是一个长期积累的过程，需要不断的研究摸索，也需要众位同道多多分享多多赐教！与君共勉！

转自： https://blog.51cto.com/cangzihu/1888622

TIME_WAIT过多的危害以及解决TIME_AWAIT过多方案

TIME_WAIT过多危害
网大卖络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接；
同样网络情况不好并且无TIME_WAIT等待，关闭连接后无新连接，碧毕当接收到被动方重传或延迟的FIN包后，会给被动方回一个RST包，可能会影响被动方其它的服务连接。
过多的话会占用内存，一个TIME_WAIT占用4k大小
解决方法
相关参数优化调整（当然得根据服务器的实际情况配置，这里着重讲参数意义）：
既然知道了TIME_WAIT的用意了，尽量按照TCP的协议规定来调悔仿芹整，对于tw的reuse、recycle其实是违反TCP协议规定的，服务器资源允许、负载不大的条件下，尽量不要打开，当出现TCP: time wait bucket table overflow，尽量调大下面参数：
vim /etc/sysctl.conf

调整次参数的同时，要调整TIME_WAIT_2到TIME_WAIT的超时时间，默认是60s，优化到30s：

其它TCP本身的配合参数类似与synack重传次数、syn重传次数等以后介绍，优化后也是有所益处的。

机器作为客户端时起作用，开启后time_wait在一秒内回收

windows批量杀timewait

方法如下：
1.打开Windows任务管理器的方法有薯虚,按Ctrl+shift+Esc组合键,或右键点击任务栏空白处,在打开的菜单项中,选择启动任务管理器,
2.Windows任务悔手模管理器中,可以在进程选项卡下,找到需要批量结束碧缓的进程,比如这里红色框标记的notepad.exe记事本进程,
3.既然知道需要结束那个进程,那就按Win+R组合键,打开运行,并输入:cmd命令,确定或回车,可以快速打开命令提示符窗口,
4.命令提示符窗口中,输入:taskkill/f/imnotepad.exe命令,然后按回车执行命令。
5、回车执行taskkill/f/imnotepad.exe命令，成功的话，会提示成功：已终止进程，还有PID为多少那样，
6、最后，再打开Windows任务管理器，按进程选项卡，可以发现刚才的notepad.exe记事本进程已经被结束。

系统产生大量timewaite的处理

Timewait 和 TCP 连接的关系:

主动关闭的一端向服务端发送第 1 次挥手的请求，被动方返回了一个 ACK 的包，可以看到被动关闭端再一次发送完 FIN 和 ACK 包以后，主动关闭端就会会先发送一个 ACK 响应回去，然后进入 TIME_WAIT 状态。

我们看到在它进入 TIME_WAIT 状态之前，理派姿论上 4 次挥手已经完成了，为什么 TIME_WAIT 还需要保留一段时间？

这是因为 TCP的协议标准，需要保证4 次挥手尘告绝过程中最后一次连接发送的稳定性，如果ACK包发送不成功，就需要再次发送 ACK 包。

大量的 Timewait 产生会造成文件句柄、内存和端口的占用，由于系统会把过多的 time-wait socket 删除、回收，在网络条件不好的情况下，就可能会导致数据包重复的进行发送。

如何对 TimeWait 进行优化

了解了 Timewait 的影响（结论：通常不会直接造成服务连接的影响，但是会造成一些资源上及新建连接风险），为了避免过多的 Timewait 产生，我们需要考虑去进行一些优化。在单机系统上做性能优化的话，我们需要考虑两点：

第 1 点就是考虑把Timewait 队列加大。在操作系统资源、硬件资源能满足的情况下，我们可以把 tcp_max_tw_buckets 的值数调高，它的缓冲值也就越大。这个数字是我们可以进行操作系统内核优化的。

第 2 点即我们需要尝试修改操作系统内核优化的内容，也就是调整 TIME_WAIT 超出时间，如果它的操作时间能够更快地让操作系统进行回收，那么它就可以更快地释放资源。当然这个时间也不能调的太小，要不然 Timewait 的作用的意义就很友则小了。所以我建议操作系统内核的参数 tcp_fin_timeout 这个值调到 30，这就是一个比较合理的优化空间。

参考链接： https://kaiwu.lagou.com/course/courseInfo.htm?courseId=42#/detail/pc?id=1563