内核编译解决 TCP连接大量 TIMEWAIT

随着业务量的增长,业务服务器网络压力不断增大,查看后端服务器网络连接状态,发现TIME_WAIT状态连接巨多,TIME_WAIT 占用大量的连接端口不释放,影响业务服务响应速度。同时大量的每个TCP连接都各自有个数据结构,叫TCP Control Block.Time_wait的时候这个数据结构没有被释放。所以当有太多的TCP连接时,内存可能会被占用很多。

网络密集型后台服务器,网络连接状态:

av.com                                   #    av.com

TIME_WAIT       47144                    #    TIME_WAIT       45920

SYN_SENT        1                        #    SYN_SENT        1

ESTABLISHED     104                      #    ESTABLISHED     94

LISTEN          7                        #    LISTEN          7

av.com                                   #    av.com

TIME_WAIT       45670                    #    TIME_WAIT       48396

ESTABLISHED     102                      #    ESTABLISHED     99

LISTEN          7                        #    LISTEN          7

av.com                                   #    av.com

TIME_WAIT       45671                    #    TIME_WAIT       46268

SYN_SENT        2                        #    ESTABLISHED     100

ESTABLISHED     93                       #    LISTEN          7

LISTEN          7

超过三四万。这个时候,我们需要修改 linux kernel 的 tcp time wait的时间,有个 可以调整 /etc/sysctl.conf网络控制相关的参数,网上资料很多。

但是修改内核参数效果甚微。经过测试高并发的服务器调整内核参数,我们这边业网络环境,tcp time_wait 能降低%10左右,后期业务压力不断攀升,内核参数优化后的服务器tcp time_wait 会再次爬到一个高点,如上图。

这时该如何解决问题那? 先看一下time_wait 在什么环境下会生成?

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,MLS(Maximum Segment Lifetime)是TCP片在网上的最长存活时间,它的作用和IP数据包的TTL类似。 主要作用是保证关闭的TCP端口不立即被使用。因为当网络存在延迟时,可能当某个端口被关闭后,网络中还有一些重传的TCP片在发向这个端口,如果这个端口立即建立新的TCP连接,则可能会有影响。所以使用2倍的MSL时间来限制这个端口立即被使用。

查询相关资料,内核中一个宏定义,在 $KERNEL/include/net/tcp.h里面,这个宏是真正控制 TCP TIME_WAIT 状态的超时时间的。内容如下:

   #define TCP_TIMEWAIT_LEN (60*HZ)

修改这个宏定义数值设置,根据我们的测试,常用的值有以下三种:30秒,1分钟,2分钟,可以根据业务实际情况进行实测,我们这边网络压力比较大,通过压测最终确定设置为 10 秒,也就是把上面的修改为:

#define TCP_TIMEWAIT_LEN (10*HZ)

然后重新编译内核,重启系统即可发现短连接造成的TIME_WAIT状态倍数级下降,我们实测效果如下:

内核编译升级参考:

http://michaelkang.blog.51cto.com/1553154/1266825

优化系统内核参数主机       │ 内核编译优化主机

av.com (主机名)    │av.com    (主机名)

TIME_WAIT       46366      │TIME_WAIT       9419

ESTABLISHED     99         │FIN_WAIT1       3

LISTEN          7          │ESTABLISHED     118

av.com    │LISTEN          7

TIME_WAIT       46125      │av.com

FIN_WAIT1       1          │TIME_WAIT       8950

SYN_SENT        1          │ESTABLISHED     105

ESTABLISHED     99         │LISTEN          7

LISTEN          7          │av.com

av.com                     │TIME_WAIT       9668

TIME_WAIT       46591      │ESTABLISHED     114

ESTABLISHED     101        │LISTEN          7

LISTEN          7          │av.com

av.com                     │TIME_WAIT       9224

TIME_WAIT       44307      │FIN_WAIT1       1

ESTABLISHED     95         │ESTABLISHED     104

LISTEN          7          │LISTEN          7

av.com                     │av.com

TIME_WAIT       46679      │TIME_WAIT       9763

ESTABLISHED     99         │FIN_WAIT1       2

LISTEN          7          │ESTABLISHED     116

av.com                     │LISTEN          7

TIME_WAIT       46833      │av.com

SYN_SENT        1          │TIME_WAIT       9173

ESTABLISHED     99         │FIN_WAIT1       1

LISTEN          7          │ESTABLISHED     103

av.com                     │SYN_RECV        1

TIME_WAIT       45555      │LISTEN          7

SYN_SENT        3          │av.com

ESTABLISHED     104        │TIME_WAIT       9598

LISTEN          7          │ESTABLISHED     117

av.com                     │LISTEN          7

TIME_WAIT       45214      │av.com

ESTABLISHED     96         │TIME_WAIT       9315

LISTEN          7          │SYN_SENT        1

av.com                     │ESTABLISHED     106

TIME_WAIT       46498      │LISTEN          7

SYN_SENT        1          │av.com

ESTABLISHED     93         │TIME_WAIT       9524

LISTEN          7          │ESTABLISHED     116

av.com                     │LISTEN          7

TIME_WAIT       46720      │av.com

SYN_SENT        1          │TIME_WAIT       9110

ESTABLISHED     95         │ESTABLISHED     104

LISTEN          7          │LISTEN          7

同样的网路压力情况下,优化编译后的内核 TIME_WAIT  降低接近5倍,效果很显著。

时间: 2024-11-13 19:28:15

内核编译解决 TCP连接大量 TIMEWAIT的相关文章

TCP连接状态详解及TIME_WAIT过多的解决方法

TCP建立连接的三次握手过程,以及关闭连接的四次握手过程. TCP建立连接的三次握手过程,以及关闭连接的四次握手过程. 1.建立连接协议(三次握手)(1)客户端发送一个带SYN标志的TCP报文到服务器.这是三次握手过程中的报文1. (2) 服务器端回应客户端的,这是三次握手中的第2个报文,这个报文同时带ACK标志和SYN标志.因此它表示对刚才客户端SYN报文的回应:同时又标志SYN给客户端,询问客户端是否准备好进行数据通讯. (3) 客户必须再次回应服务段一个ACK报文,这是报文段3. 2.连接

Tcp连接出现大量ESTABLISHED连接解决方法

TCP状态转移要点TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不 会被释放.网络服务器程序要同时管理大量连接,所以很有必要保证无用连接完全断开,否则大量僵死的连接会浪费许多服务器资源.在众多TCP状态中,最值得 注意的状态有两个:CLOSE_WAIT和TIME_WAIT. 1.LISTENING状态FTP服务启动后首先处于侦听(LISTENING)状态. 2.ESTABLISHED状态ESTABLI

服务器tcp连接timewait过多优化及详细分析

[背景说明] 在7层负载均衡上,查询网络状态发现timewait太多,于是开始准备优化事宜 整体的拓扑结构,前面是lvs做dr模式的4层负载均衡,后端使用(nginx.or haproxy)做7层负载均衡 [优化效果] 修改前,建立连接的有29个,timewait的就达到了900个,如下图所示 修改后,建立连接的有32个,timewait的从900降低到了49个,如下图所示 [具体优化方案] 注意:前端使用nat时,不适用本策略.详细"方案详细介绍"会说明 修改7层负载所在机器,/et

TIME-WAIT的TCP连接参数

新Apache服务器上线以后,用netstat -an命令发现服务器中有大量状态为TIME-WAIT的TCP连接,于是用/sbin/sysctl -a查看了一下Linux的各项内核参数,并翻阅有关资料,决定修改其中的两项参数,以达到减少TCP连接中TIME-WAIT sockets的目的. vi /etc/sysctl.conf 编辑/etc/sysctl.conf文件,增加三行: 引用 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1

TCP连接出现大量TIME_WAIT的解决办法

一个TCP/IP连接断开以后,会通过TIME_WAIT的状态保留一段时间,时间过了才会释放这个端口,当端口接受的频繁请求数量过多的时候,就会产生大量的TIME_WAIT状态的连接,这些连接占着端口,会消耗大量的资源.面对这种情况 可以通过修改TCP/IP的内核参数,来及时的处理这些状态.netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'执行该命令如果出现了大量的 TIME_WAIT 连接数目的话,如下:FIN_

TCP连接TIME-WAIT解决方案

问题根源: 为什么会产生time-wait? 当客户端与服务器之间进行四次断开时,当客户端接收 到服务器端发送过来的断开确认报文后,会发送最后一次 ACK报文,发送之后客户端会进入time-wait状态,这个过 成会持续一分钟,用来完成接收剩余所有从服务器端发送 过来的数据[由于网络延迟等原因导致数据延迟达到], 同时也可以确自己发送的最后一个ACK断开确认报文能被 服务器端收到! time-wait状态的危害: 1 time-wait状态会占据一定量的内存资源,虽然很少但 是如果这种连接在一个

TCP连接的状态详解以及故障排查

转载自CSDN博客:http://blog.csdn.net/hguisu/article/details/38700899 TCP状态 TCP状态迁移路线图 TCP连接建立三次握手 TCP连接的终止四次握手释放 同时打开 同时关闭 TCP通信中服务器处理客户端意外断开 Linux错误信息errno列表 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 了解TCP之前,先了解几个命令:   linux查看tcp的状态命令: 1).netst

查看 并发请求数及其TCP连接状态

服务器上的一些统计数据: 1)统计80端口连接数netstat -nat|grep -i "80"|wc -l 2)统计httpd协议连接数ps -ef|grep httpd|wc -l 3).统计已连接上的,状态为"establishednetstat -na|grep ESTABLISHED|wc -l 4).查出哪个IP地址连接最多,将其封了.netstat -na|grep ESTABLISHED|awk {print $5}|awk -F: {print $1}|s

TCP连接中time_wait在开发中的影响-搜人以鱼不如授之以渔

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的