[转帖]性能案例-Linux下解决time_wait连接过多(Linux内核优化)

性能,案例,linux,解决,time,wait,连接,内核,优化 · 浏览次数 : 0

小编点评

**关于 sysctl.conf 中的其他参数** * **net.ipv4.tcp_max_syn_backlog**:进入SYN包的最大请求队列长度,默认 1024。 * **net.ipv4.tcp_retries2**:TCP失败重传次数,默认 15。 * **net.ipv4.tcp_keepalive_probes**:TIME-WAIT sockets快速回收的 probe 次数,默认 9。 * **net.ipv4.tcp_keepalive_time**:KEEPALIVE 消息发送的频率,默认 1200。 * **net.ipv4.tcp_keepalive_intvl**:KEEPALIVE 消息发送的 intvl,默认 30。 * **net.ipv4.tcp_keepalive_probes**:TIME-WAIT sockets快速回收的 probe 频率,默认 3。 * **net.ipv4.tcp_syncookies**:开启 SYN Cookies,默认 1。 **其他配置参数** * **net.ipv4.tcp_keepalive_time**:KEEPALIVE 消息发送的频率,默认 1800。 * **net.ipv4.tcp_keepalive_intvl**:KEEPALIVE 消息发送的 intvl,默认 30。 * **net.ipv4.tcp_max_syn_backlog**:进入 SYN包的最大请求队列长度,默认 5000。 * **net.ipv4.tcp_max_tw_buckets**:系统同时保持 TIME_WAIT 套接字的最大数量,默认 180000。

正文

一、性能测试的主要概念和计算公式

系统吞度量要素:

一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。

单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。

系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间

QPS(TPS):每秒钟request/事务 数量

并发数: 系统同时处理的request/事务数

响应时间:  一般取平均响应时间

 

理解了上面三个要素的意义之后,就能推算出它们之间的关系:

QPS(TPS)= 并发数/平均响应时间

*******************************************************

二、Linux 下产生大量 TIME_WAIT 状态的原因和解决办法

1、问题描述:高负载下,系统响应变慢,并出现超时或失误失败情况,TIME_WAIT积压

2、问题影响:系统设置的自动回收时间为60s,但在压测中如果涉及的服务较多的情况下,比如这次以100TPS压力单测1个接口,涉及4-6个服务,每秒就会创建400+的连接,1分钟就是2.4万的连接,系统无法及时回收,压测两分钟后,新的请求过来,无法创建连接或无法及时创建连接,导致请求失败,严重时会出现整个服务器挂死(新来的请求无法创建连接)。

3、问题原因:Linux环境配置存在问题(后check所有测试环境均未配置,包括生产环境)

4、问题背景:在对A接口进行负载测试时,在一定压力下,出现了比较诡异的现象:在100TPS压力下,开始响应时间很快,都在0.3s左右,但压测不到一分钟开始出现大量事务失败,响应时间倍增,最后系统甚至出现“挂死”。

5、问题解决:增加以下,

[root@aaa1 ~]# vim /etc/sysctl.conf

net.ipv4.tcp_tw_reuse = 1

这个是重点,表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭

问题定位及验证

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

TIME_WAIT 41735

CLOSE_WAIT 145

FIN_WAIT2 3

ESTABLISHED 413

不到两分钟,time_wait积压到4万,最后导致无法创建新的连接,事务全部失败。

添加参数后,再次验证,以下是压测十分钟中的time_wait数据,一致保持在5000以下,而且由于不需要重新创建连接,直接用已存在的,减少了资源开销,120TPS比之前压测100TPS的性能要好很多。

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

TIME_WAIT 4500

CLOSE_WAIT 7

ESTABLISHED 642

 

***************************附上相关参数的详解****************************

1、在服务器中可输入如下命令:

#netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

LAST_ACK 14

SYN_RECV 348

ESTABLISHED 70

FIN_WAIT1 229

FIN_WAIT2 30

CLOSING 33

TIME_WAIT 18122

 

状态:描述

CLOSED:无连接是活动的或正在进行

LISTEN:服务器在等待进入呼叫

SYN_RECV:一个连接请求已经到达,等待确认

SYN_SENT:应用已经开始,打开一个连接

ESTABLISHED:正常数据传输状态

FIN_WAIT1:应用说它已经完成

FIN_WAIT2:另一边已同意释放

ITMED_WAIT:等待所有分组死掉

CLOSING:两边同时尝试关闭

TIME_WAIT:另一边已初始化一个释放

LAST_ACK:等待所有分组死掉

 

也就是说,这条命令可以把当前系统的网络连接状态分类汇总。

如发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决。

2、先检查一下time wait的值:

[root@aaa1 ~]# sysctl -a | grep time | grep wait

net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60

net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

 

[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw

(说明没配置)

3、修改系统配置

[root@aaa1 ~]# vim /etc/sysctl.conf

增加以下几行:(请根据实际需要添加

net.ipv4.tcp_fin_timeout = 30

net.ipv4.tcp_keepalive_time = 1200

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_max_tw_buckets = 5000

说明:

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 = 30 表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。

net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。

net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_max_tw_buckets = 5000表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000,改为5000。对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。

 

4、执行以下命令使配置生效:

[root@aaa1 ~]# /sbin/sysctl -p

 

***************************关于 sysctl.conf 中的其他参数****************************

$ /proc/sys/net/core/wmem_max
最大socket写buffer,可参考的优化值:873200

$ /proc/sys/net/core/rmem_max
最大socket读buffer,可参考的优化值:873200

$ /proc/sys/net/ipv4/tcp_wmem
TCP写buffer,可参考的优化值: 8192 436600 873200

$ /proc/sys/net/ipv4/tcp_rmem
TCP读buffer,可参考的优化值: 32768 436600 873200

$ /proc/sys/net/ipv4/tcp_mem
同样有3个值,意思是:
net.ipv4.tcp_mem[0]:低于此值,TCP没有内存压力.
net.ipv4.tcp_mem[1]:在此值下,进入内存压力阶段.
net.ipv4.tcp_mem[2]:高于此值,TCP拒绝分配socket.
上述内存单位是页,而不是字节.可参考的优化值是:786432 1048576 1572864

$ /proc/sys/net/core/netdev_max_backlog
进入包的最大设备队列.默认是300,对重负载服务器而言,该值太低,可调整到1000.

$ /proc/sys/net/core/somaxconn
listen()的默认参数,挂起请求的最大数量.默认是128.对繁忙的服务器,增加该值有助于网络性能.可调整到256.

$ /proc/sys/net/core/optmem_max
socket buffer的最大初始化值,默认10K.

$ /proc/sys/net/ipv4/tcp_max_syn_backlog
进入SYN包的最大请求队列.默认1024.对重负载服务器,增加该值显然有好处.可调整到2048.

$ /proc/sys/net/ipv4/tcp_retries2
TCP失败重传次数,默认值15,意味着重传15次才彻底放弃.可减少到5,以尽早释放内核资源.

$ /proc/sys/net/ipv4/tcp_keepalive_time
$ /proc/sys/net/ipv4/tcp_keepalive_intvl
$ /proc/sys/net/ipv4/tcp_keepalive_probes

这3个参数与TCP KeepAlive有关.默认值是:

tcp_keepalive_time = 7200 seconds (2 hours)
tcp_keepalive_probes = 9
tcp_keepalive_intvl = 75 seconds

意思是如果某个TCP连接在idle 2个小时后,内核才发起probe.如果probe 9次(每次75秒)不成功,内核才彻底放弃,认为该连接已失效.对服务器而言,显然上述值太大. 可调整到:

/proc/sys/net/ipv4/tcp_keepalive_time 1800
/proc/sys/net/ipv4/tcp_keepalive_intvl 30
/proc/sys/net/ipv4/tcp_keepalive_probes 3

$ proc/sys/net/ipv4/ip_local_port_range
指定端口范围的一个配置,默认是32768 61000,已够大.

 

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 = 30
表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_keepalive_time = 1200
表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。

net.ipv4.ip_local_port_range = 1024 65000
表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。

net.ipv4.tcp_max_syn_backlog = 8192
表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_max_tw_buckets = 5000
表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000,改为 5000。

 

 

文章知识点与官方知识档案匹配,可进一步学习相关知识
CS入门技能树Linux入门初识Linux25419 人正在系统学习中

与[转帖]性能案例-Linux下解决time_wait连接过多(Linux内核优化)相似的内容:

[转帖]性能案例-Linux下解决time_wait连接过多(Linux内核优化)

一、性能测试的主要概念和计算公式 系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。 单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。 系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间

[转帖]《Linux性能优化实战》笔记(十九)—— DNS 解析原理与故障案例分析

一、 域名与 DNS 解析 域名主要是为了方便让人记住,而 IP 地址是机器间的通信的真正机制。以 time.geekbang.org 为例,最后面的 org 是顶级域名,中间的 geekbang 是二级域名,而最左边的 time 则是三级域名。点(.)是所有域名的根,所有域名都以点作为后缀。 把域

[转帖]宋宝华:用eBPF/bcc分析系统性能的一个简单案例

原创 宋宝华 Linux阅码场 3月8日 bcc是eBPF的一种前端,当然这个前端特别地简单好用。可以直接在python里面嵌入通过C语言写的BPF程序,并帮忙产生BPF bytecode和load进入kernel挂载kprobe、tracepoints等上面执行。之后,还可以从python取出来C

[转帖]性能优化必备——火焰图

引言 本文主要介绍火焰图及使用技巧,学习如何使用火焰图快速定位软件的性能卡点。结合最佳实践实战案例,帮助读者加深刻的理解火焰图构造及原理,理解 CPU 耗时,定位性能瓶颈。 背景 当前现状 假设没有火焰图,你是怎么调优程序代码的呢?让我们来捋一下。 1. 功能开关法 想当年我刚工作,还是一个技术小白

[转帖]【软件测试】Jmeter性能测试(性能测试,Jmeter使用与结果分析)

文章目录 前言一、性能测试1. 什么是性能测试?2. 性能测试的重要性3. 性能指标——QPS和TPS①QPS②TPS 二、压测工具Jmeter1. 什么是Jmeter?2. Jmeter主要元件3. 下载安装 三、一个简单的测试案例①新建一个线程组②新建一个HTTP请求③添加HTTP信息头(请求头

[转帖]警惕Oracle数据库性能“隐形杀手”——Direct Path Read

一、 简介 Oracle 的11g版本正式发布到今天已经10年有余,最新版本也已经到了20c,但是Direct Path Read(直接路径读)导致性能问题的案例仍时有发生,很多12c的用户还是经常遇到这个问题,所以有必要把这个事情再跟大家讲一遍,通过2个典型案例加深理解。 早在2012年,盖国强大

[转帖]Nginx应用调优案例

https://bbs.huaweicloud.com/blogs/146367 【摘要】 1 问题背景nginx的应用程序移植到TaiShan服务器上,发现业务吞吐量没有达到硬件预期,需要做相应调优。 2 原因分析l 网卡配置该应用场景下网络吞吐量大,网卡的配置能对性能提升起到很大的作用。l 操作

[转帖]Nginx应用调优案例

https://bbs.huaweicloud.com/blogs/146367 【摘要】 1 问题背景nginx的应用程序移植到TaiShan服务器上,发现业务吞吐量没有达到硬件预期,需要做相应调优。 2 原因分析l 网卡配置该应用场景下网络吞吐量大,网卡的配置能对性能提升起到很大的作用。l 操作

[转帖]strace 命令详解

目录 1、strace是什么? 2、strace能做什么? 3、strace怎么用? 4、strace问题定位案例 4.1、定位进程异常退出 4.2、定位共享内存异常 4.3、 性能分析 5、总结 1、strace是什么? 按照strace官网的描述, strace是一个可用于诊断、调试和教学的Li

[转帖]性能调优——小小的log大大的坑

https://segmentfault.com/a/1190000042434642 引言 “只有被线上服务问题毒打过的人才明白日志有多重要!”我先说结论,谁赞成,谁反对?如果你深有同感,那恭喜你是个社会人了:) 日志对程序的重要性不言而喻,轻巧、简单、无需费脑,程序代码中随处可见,帮助我们排查定