[转帖]神秘的backlog参数与TCP连接队列
https://www.cnblogs.com/codelogs/p/16060820.html
简介#
这要从一次压测项目说起,那是我们公司的系统与另几家同行公司的系统做性能比拼,性能数据会直接影响项目中标,因此压力非常大。
当时甲方给大家提供了17台服务器供系统部署,并使用LoadRunner对系统进行压测,乙方有完全的服务器使用权,甲方派一个人负责压测并记录性能数据,要求压测QPS不低于4000。
项目开工#
接收到项目后,我们leader作为本项目的技术负责人,很快就为本项目指定了架构,web层使用nginx作为负载均衡,应用层使用weblogic服务器(理解为类似tomcat的东西即可)集群,数据库使用Oracle RAC集群,如下:
看看这系统架构也挺简单的,心里想,高并发系统不过如此嘛?
待系统代码按照上述架构部署完毕后,我们就开始了第一轮压测。
好家伙,我们一开始压测,就发现压测机上有大量的网络报错,类似于Connection timed out
、Read timed out
之类的网络异常。
但奇怪的是,我们登录到nginx或weblogic上观察机器情况,cpu、memory使用都不高,查看应用日志,发现日志中似乎并没有收到多少请求!
整个组内满脸的疑惑,压测请求为什么没到应用系统中来?那请求去哪了?一番讨论过后,组内没人能回答这个问题,然后就都埋头去网上搜索答案去了。
可是,经过半天的研究,大家都没有找出问题所在,包括leader也没有,中途参照网上调整过一些nginx、jvm配置啥的,都没见起啥明显效果!
请求外援#
leader见问题一时半会解决不了,于是就从众包网站上找到了一些高手,虽然需要花点钱,但问题能快速解决还是值得的。
首先第一位高手远程进来了,操作了大概10分钟后就放弃了,看来钱不好挣。
然后第二位高手远程进来了,弄了个把小时,还重新编译了nginx,最终也放弃了,问题没有解决。
然后第三位高手远程进来了,只见他进来之后,就吩咐我们开始压测,然后就是他的show time了。
只见他不断地观察着一个命令的输出结果,命令如下:
$ netstat -nat | awk '/tcp/{print $6}'|sort|uniq -c
16 CLOSE_WAIT
80 ESTABLISHED
6 FIN_WAIT2
11 LAST_ACK
8 LISTEN
22 SYN_RECV
400 TIME_WAIT
观察了一会后,他就叫我们停下来,他要调整一些内核参数了,调整参数如下:
$ vi /etc/sysctl.conf
net.ipv4.tcp_max_syn_backlog = 8192
net.core.netdev_max_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 5
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
调整完毕后,我们又开始压测,效果十分明显,虽然后端系统此时也有很多报错,但至少请求都进来了!
至此,本次压测的核心技术难题已经解决,虽然后面也调整过一些jvm参数与代码,但都在我们自己的掌控范围内,这些就不再提了。
但我当时根本就看懵了,不知道大佬弄了些啥?
半连接队列与全连接队列#
经过一段时间的网上搜索,我发现了新的知识点,就是TCP建立连接的过程里面,有两个队列,分别是半连接队列与全连接队列,如下:
- 服务端要提供服务,会调用
bind()
与listen()
函数,创建一个LISTEN状态的Socket。 - 当客户端建立连接时,会发SYN包,即三次握手的第一步,服务端收到后,会创建一个SYN_RECV状态的Socket,放入半连接队列,并且回复SYN+ACK(即三次握手第二步)。
- 当客户端收到SYN+ACK后,将自己的Socket状态变更为ESTABLISHED,并给服务端回复ACK。
- 服务端收到ACK后,将对应半连接队列里的Socket移动到全连接队列,并将其状态变更为ESTABLISHED。
- 服务端
accept()
轮询线程这时会从全连接队列里面取到新的Socket,然后就可以使用此Socket与客户端交换数据了。
可以看到,在服务端建立连接的过程中,会经历半连接队列与全连接队列,如果半连接队列或全连接队列满了,会怎么样呢?
- 如果半连接队列满了,会丢弃客户端发来的SYN,而客户端如果发了几次SYN都没有收到SYN+ACK,会报
Connection timed out
异常,这解释了我们压测机上的大量报错。 - 如果全连接队列满了,会丢弃客户端回复的ACK与数据包,因为此时客户端是ESTABLISHED(连接已建立)状态,然后客户端会发具体的请求数据包,然后请求数据包一直被丢弃,会导致客户端报
Software caused connection abort :socket write error
或Read timed out
。 - 另外,全连接队列满了,也会导致丢弃第一次握手的SYN,这也会导致
Connection timed out
异常。
可见,半连接队列与全连接队列的大小非常重要,而内核默认配置都是128,这太小了!如下:
$ vi /etc/sysctl.conf
# 这是半连接队列的大小
net.ipv4.tcp_max_syn_backlog = 8192
# 这是全连接队列的大小
net.core.somaxconn = 8192
# 使得配置修改生效
$ sysctl -p
# 查看当前配置
$ sysctl -a
另外,Socket网络编程一般也可以指定一个backlog参数,如java中的ServerSocket:
int port=8080;
int backlog=8192;
ServerSocket ss = new ServerSocket(port, backlog);
while(true){
//接收到新连接
Socket s = ss.accept();
new Thread(()->{
//socket读写操作...
}, "socket-thread-" + s).start();
}
这个backlog参数,就是配置全连接队列的大小的,但全连接队列大小实际由内核与应用程序同时决定,取net.core.somaxconn
与应用中backlog
的最小值。
所以,一般网络服务程序(tomcat、redis、mysql等)都会有一个backlog的配置,在springboot内置的tomcat中,backlog配置方法如下:
server:
port: 8080
tomcat:
accept-count: 8192 # 内置tomcat的全连接队列大小配置
观测TCP连接队列#
如上,大佬当时诊断问题时,主要使用的是netstat命令,用于统计各状态Socket的数量,如下:
$ netstat -nat | awk '/tcp/{print $6}'|sort|uniq -c
16 CLOSE_WAIT
80 ESTABLISHED
6 FIN_WAIT2
11 LAST_ACK
8 LISTEN
22 SYN_RECV
400 TIME_WAIT
从这里可以看到,ESTABLISHED状态的Socket数量较少,大佬估计是觉得压测时正常连接不应该这么少,然后就认定是TCP连接队列大小配置有问题,导致压测QPS上不去。
当然,这是非常依赖经验的,因为这个数据并不直观,估计大佬有多年的性能优化经验,才能感觉到这个连接数是不正常的。
经过我多方搜索,我发现有一些方法,可以直接观测到连接队列的使用情况。
- 观测连接队列长度
# ss命令对于LISTEN状态的Socket
# Recv-Q是全连接队列的当前大小
# Send-Q是全连接队列的最大值
$ ss -nltp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 10 0.0.0.0:8080 0.0.0.0:* users:(("ncat",pid=25760,fd=3))
# netstat命令对于LISTEN状态的Socket
# Recv-Q是半连接队列的当前大小
# Send-Q一般显示为0
$ netstat -nltp
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 25760/ncat
可见,通过ss或netstat命令,可以直接观测到TCP连接队列的大小,另外,也有办法观测到由于队列溢出而丢弃包的次数,如下:
- 观测连接队列溢出而丢弃包的次数
$ netstat -s|grep -iE LISTEN
52 times the listen queue of a socket overflowed # backlog满了,溢出的次数
52 SYNs to LISTEN sockets ignored # SYN包drop的次数
从上可以看到,SYN被drop了52次,可能是连接队列设置过小导致。
ss其它用法#
一般做过网络编程的话,应该了解过,每个socket都可以设置recv buffer
(读缓冲)和send buffer
(写缓冲),而对于ESTABLISHED状态的socket,ss命令可以观测到这两个buffer的使用情况,如下:
- Recv-Q:表示的是recv buffer中用户进程未来得及
read()
走的数据大小。 - Send-Q:表示的是
write()
到send buffer中远程主机还未返回ACK确认包的数据大小。
一般来说,这两个buffer内核可自动调整大小,并不需要我们手动配置,另外,使用netstat还可以观测到这两个buffer不足导致的丢包情况,如下:
$ netstat -s|grep -E 'pruned|collapsed'
19963 packets pruned from receive queue because of socket buffer overrun
665 packets collapsed in receive queue due to low socket buffer
- collapsed:由于tcp包的header部分内容有很多是一样的,Linux为了节省Tcp header所占用的内存,使相同header的tcp包复用同一个header以节省内存,当socket的recv buffer不足时,会触发这个行为。
- pruned:是指内核在collapsed时的尝试后,仍未有足够空间接收包则此时直接丢包。
总结#
这次压测给我的印象很深,发现了在Java的世界外面,还有很多的底层机制运行着,它们一般不出问题,但一旦出现问题,将是非常难以定位的问题,这也促使我后面花了大量时间去补Linux和网络相关的知识点。
另外,其实TCP连接队列相关知识点,在运维圈子里会分享的更多,因为他们经常部署系统、部署软件嘛,时间久了自然会了解到,这也促使我后面越来越多的关注到运维与DBA层面的知识点。
往期内容#
[转帖]神秘的backlog参数与TCP连接队列的更多相关文章
- 设置TCP_USER_TIMEOUT参数来判断tcp连接是否断开
[TOC] 1. bug描述 前段时间遇到这样的一个问题,openstack一个控制节点宕机后,在宕机后一段时间内创建的虚拟机,一直卡在创建中的状态.有的甚至要等到16分钟之后虚拟机才会切换到下一个状 ...
- 曹工说Redis源码(4)-- 通过redis server源码来理解 listen 函数中的 backlog 参数
文章导航 Redis源码系列的初衷,是帮助我们更好地理解Redis,更懂Redis,而怎么才能懂,光看是不够的,建议跟着下面的这一篇,把环境搭建起来,后续可以自己阅读源码,或者跟着我这边一起阅读.由于 ...
- TCP/IP协议中backlog参数
TCP建立连接是要进行三次握手,但是否完成三次握手后,服务器就处理(accept)呢? backlog其实是一个连接队列,在Linux内核2.2之前,backlog大小包括半连接状态和全连接状态两种队 ...
- TCP之三:TCP/IP协议中backlog参数(队列参数)
目录: <TCP洪水攻击(SYN Flood)的诊断和处理> <TCP/IP协议中backlog参数> TCP建立连接是要进行三次握手,但是否完成三次握手后,服务器就处理(ac ...
- 关于TCP 半连接队列和全连接队列
关于TCP 半连接队列和全连接队列 http://jm.taobao.org/2017/05/25/525-1/ 发表于 2017-05-25 | 作者 蛰剑 | 分类于 网络 ...
- 性能分析之TCP全连接队列占满问题分析及优化过程(转载)
前言 在对一个挡板系统进行测试时,遇到一个由于TCP全连接队列被占满而影响系统性能的问题,这里记录下如何进行分析及解决的. 理解下TCP建立连接过程与队列 从图中明显可以看出建立 TCP 连接的时候, ...
- 我为 Netty 贡献源码 | 且看 Netty 如何应对 TCP 连接的正常关闭,异常关闭,半关闭场景
欢迎关注公众号:bin的技术小屋,本文图片加载不出来的话可查看公众号原文 本系列Netty源码解析文章基于 4.1.56.Final版本 写在前面..... 本文是笔者肉眼盯 Bug 系列的第三弹,前 ...
- 【转】关于TCP 半连接队列和全连接队列
摘要: # 关于TCP 半连接队列和全连接队列 > 最近碰到一个client端连接异常问题,然后定位分析并查阅各种资料文章,对TCP连接队列有个深入的理解 > > 查资料过程中发现没 ...
- Linux网络编程二、tcp连接API
一.服务端 1.创建套接字: int socket(int domain, int type, int protocol); domain:指定协议族,通常选用AF_INET. type:指定sock ...
- 三次握手 四次握手 原因分析 TCP 半连接队列 全连接队列
小结 1. 三次握手的原因:保证双方收和发消息功能正常: [生活模型] "请问能听见吗""我能听见你的声音,你能听见我的声音吗" [原理]A先对B:你在么?我在 ...
随机推荐
- Java异常处理之数字溢出问题
在进行 Java 开发时,经常会遇到数字溢出的问题.这个问题在很多程序中都非常常见,尤其是在进行数值计算的时候.Java 中提供了一种异常机制来处理这种情况,我们可以在代码中使用 try-catch ...
- 华为云PB级数据库GaussDB(for Redis)解析第二期:Redis消息队列Stream的应用探讨
摘要:本文将对Stream的常用命令和应用场景进行介绍,并探讨原生Redis Stream消息队列的缺陷以及GaussDB(for Redis)提供的解决方案,供大家学习和选用. 华为云高斯Redis ...
- 聊聊LiteOS中生成的Bin、HEX、ELF三种文件格式
摘要:我们在使用编译器在编译工程后会要求生成可执行文件,将这些文件烧录到MCU进行运行,达到我们测试和使用程序的目的,再使用工具链进行编译的时候往往生成.bin..hex ..elf ..alf等文件 ...
- Spark 开源新特性:Catalyst 优化流程裁剪
摘要:为了解决过多依赖 Hive 的问题, SparkSQL 使用了一个新的 SQL 优化器替代 Hive 中的优化器, 这个优化器就是 Catalyst. 本文分享自华为云社区<Spark 开 ...
- 带你读AI论文:SDMG-R结构化提取—无限版式小票场景应用
摘要:在文档图像中提取关键信息在自动化办公应用中至关重要.传统基于模板匹配或者规则的方法,在通用性方面.未见过版式模板数据方面,效果都不好:为此,本文提出了一种端到端的空间多模态图推理模型(SDMG- ...
- 云小课|VMware备份上云学习专列来了,快加入吧~
阅识风云是华为云信息大咖,擅长将复杂信息多元化呈现,其出品的一张图(云图说).深入浅出的博文(云小课)或短视频(云视厅)总有一款能让您快速上手华为云.更多精彩内容请单击此处. 摘要:华为云云备份CBR ...
- 使用appuploader工具流程(Windows版本)
转载:使用appuploader工具流程(Windows版本) 目录 转载:使用appuploader工具流程(Windows版本) 一.登录apple官网,注册账号 二.下载Appuploade ...
- Gartner 权威预测未来4年网络安全的8大发展趋势
翻译:SEAL安全 原文标题: Gartner Unveils the Top Eight Cybersecurity Predictions for 2022-23 原文链接: https://ww ...
- 8款最佳实践,保护你的 IaC 安全!
基础设施即代码(IaC) 是一种快速发展的技术,利用软件开发原则和实践,用软件配置基础设施.与传统的 IT 基础架构相比,IaC 可以更高效地交付软件.自动化还解锁了弹性配置的能力,该功能可在不同的负 ...
- 火山引擎 ByteHouse:双十一即将到来,如何用数据分析提升电商平台销售转化?
更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 "双十一"电商大促脚步渐近,各大平台的战火又将燃起.直播电商以低成本.高转化率等优势备受商家青 ...