TCP连接不释放,应用产生大量CLOSE_WAIT状态TCP

这篇具有很好参考价值的文章主要介绍了TCP连接不释放,应用产生大量CLOSE_WAIT状态TCP。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、起源

23年元旦期间,大家都沉浸在一片祥和的过节气氛当中。

“滴滴滴”,这头同事的电话响起,具体说些什么我也没太在意,但见同事接完电话之后展现出了一副懊恼夹杂着些许不耐烦的表情。

我不解问道:“怎么了?”

同事:“刚刚运营反馈系统开始刷白屏了,所有的请求一直处于pending状态。”

此刻我的大脑开始飞速旋转,界面白屏?前端是不是有一个初始化的请求?这个初始化的请求有问题导致前端没有往下运行并渲染页面?

我:“已经登陆进系统的用户可以正常使用吗?”

同事:“也不可以”。

那就不是初始化请求失败的问题了。

再往下分析,应用进程应该没有宕机,否则接口会快速响应404。

我:“所有接口都阻塞住了还是单个接口的问题,最近有没有项目发版?”

同事:“运营反馈是所有接口都有阻塞情况,这段时间一直没有发版”。

那就怪了,近期没有发版,而且所有接口均有问题。

到此,基本可以判定出,这个问题与业务无关,而是类似基础设施出现问题导致了,比如网络问题、Java GC问题、线程池线程短缺出现业务饥饿问题等。

这种问题勾起了我的兴趣,我决定自己上手问题,开始排查…

二、表象

打开系统,发现浏览器发出的接口确实都处于“pending”状态。(Ps:pending是浏览器发出请求之后的一种状态,代表该请求还未得到服务器响应,如果接口RT延迟高,你就有可能经常看到这种状态);

接口处于pending状态,我在本地使用telnet ip port命令连接应用服务器端口也是正常的,到此说明网络与应用进程都是完好的。

三、排查

打开监控系统查看了Java GC耗时、次数两项指标,发现和平时也没什么不一样。

查看了系统调用量发现与往常相似,没有什么流量突刺。

同事查看了那段时间的系统日志也未发现明显的错误。

我手里的鼠标一直向下滑动着,我和同事紧张的看着电脑,紧盯着各项指标,希望能看出些端倪,并能以此为突破口。

果然,还是看到了…

下图是近几天的TCP连接数曲线图:

TCP连接不释放,应用产生大量CLOSE_WAIT状态TCP

TCP涨势图.jpeg

发现TCP连接一直处于只涨不降的趋势(除了中间几次的人为重启机器)。

我进入服务器,熟练的敲起Linux命令:

[root] $ **netstat -na | grep '8089' | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
LISTEN 8
CLOSE_WAIT 35
ESTABLISHED 108
SYN_SENT 1
TIME_WAIT 9**

[root] $ netstat -ntp | grep 'CLOSE_WAIT'
tcp 1 0 本机ip:端口  nginx机器  CLOSE_WAIT  pid/java
....

观察了十分钟,发现CLOSE_WAT状态的TCP连接数一直处于增长的状态。并且观察到所有的CLOSE_WAIT状态的TCP都是与Nginx建立的,问了运维同学,这台Nginx是这台后端应用的代理。

同事:“啊,原来是TCP连接数捣鬼,一直上涨但不释放”。

这一点和浏览器发出的接口一直处于Pending状态刚好吻合起来了。一定是代码出现了什么问题,导致接口延迟上升,所有的HTTP请求映射到底层就是TCP连接,应用服务器一直没有返回内容,那么TCP自然也不会释放了(这里我们先不考虑现代HTTP协议的KeepAlive机制)。

只见同事为了止血抓紧去重启机器了,好让这些TCP连接被强制关闭。

但我还有一点疑问,TCP未能及时释放确实有问题不假,但即便是这样,区区500个TCP连接,也不至于达到操作系统的阈值,要知道操作系统对端口的限制理论上可以达到65535个。

那一定是有一个短板的中间件因达到了阈值而限制了整个系统,很快我便想到了Tomcat,因为Tomcat一定是每个业务接口都绕不过的中间件。

虽然机器已经重启了,但我们有服务治理相关的平台可以调出任意一个时间点的线程状态,不看不知道,一看吓一跳,所有以“http-nio-xxx”为前缀的线程全部阻塞在方法:SocketInputStream.read0方法中。熟悉这个前缀线程的人都知道,这是Tomcat线程池。

我:”查一下日志,看看接口AOP有没有捕捉到请求信息?“

同事:“捕捉到了”

我:“随机抽取几个请求,看看接口AOP是否捕捉到了接口响应信息”

同事抓紧去查了,不一会儿惊讶的说道:“老朱,还真有很多请求接口响应AOP没有捕获到,那就是说这些请求一直没有处理完”。

同事又说道:“老朱,这个项目比较特殊,项目中所有的接口基本只做了透传的事情,项目只是做简单的数据加工,然后请求其他系统,最后针对结果集再进行过滤、转换返回给前端”

我:“啊,原来是这样,目前使用的HTTP客户端是什么?”

同事:“Apache HttpClient”

我:“Apache HttpClient?三个超时时间都设置了吧?“

同事:“嗯,都设置了,connectTimeout、socketTimeout、connectionRequestTimeout都根据项目的性质调试过了,并且数据流也都妥善处理了”

我有些不解,所有的超时时间都设置好了,那为什么还会有大量的Tomcat线程阻塞在SocketInputstream.read0方法中呢,最终导致TCP持续飙高。

我和同事都陷入了困境,进入两难处境,不知道如何继续排查,机器重启确实可以强制释放TCP但是这方法治标不治本。

同事:“啊,这,怎么会这样”

我:“怎么了?!吞吞吐吐”

同事:“我记得之前明明在这些应用里都加了接口AOP日志,刚刚看到我们项目有日志,但是其他系统中居然没有日志…

至此我有个大胆的猜测,请求进入项目之后,项目加工请求并转发给其他项目,但转发给系统项目的这段网络出现了什么问题(因为其他系统并未收到请求),又因为种种原因导致超时时间并未生效,慢慢的项目中所有Tomcat线程都阻塞在了SocketInputstream中的read0方法中,最后Tomcat无空闲线程可去处理用户提交的新的请求。

但是什么情况下Apache HttpClient中的超时时间不生效呢?

直到我看到了一篇JDK官网说明:

Bug ID: JDK-8172578 SocketInputStream.socketRead0 can hang even with soTimeout set

SocketInputStream.socketRead0 can hang even with soTimeout set

在第二篇文章中有详细描述了SocketTimeOut参数失效的原因,大致意思是:因为OS select方法存在虚假唤醒的问题导致线程提前进行读取,但又因为并没有实际数据因此造成了读取阻塞。

而我们的JDK版本是1.8.0_91,也就是低于JDK修复版本,当OS发出虚假唤醒之后,导致Java线程进入阻塞读取状态,最终导致socketTimeout失效。

事情到这就解释的通了,我再来根据现象与各项指标结合起来从头到尾的阐述一波。

TCP连接不释放,应用产生大量CLOSE_WAIT状态TCP

应用拓扑图.png

这里先祭出项目的拓扑图。

应用A是这次案发地点,应用A的大多数功能只是做请求透传工作,将用户请求的参数做过滤、筛选、添油加醋发送给应用B。

根据上述的拓扑性质,以应用A为中心会有两段请求,这里标识为A段、B段。

案发时间前几个小时,起初系统稳如老狗。应用A稳定的处理着Nginx转发来的前端请求,并包装发送给应用B,然后将应用B返回来的数据进行筛选、处理然后返回给用户。

然而好景不长,B段出现了一些网络丢包、抖动等情况变得开始不稳定了,搭配上JDK8U152版本之前可能会受到操作系统的select虚假唤醒的情况,慢慢的Tomcat很多线程都阻塞在了SocketInputstreamread0方法上,这一点和之前看到的线程Dump信息一致。

看了眼项目对Tomcat的线程数配置:server.tomcat.max-threads=**400**,而线程Dump出的信息中刚好有400个线程阻塞在了read0方法中。

嗯,没错,就是这样,最后Tomcat成为了整个项目的瓶颈。

四、解决

知道了,问题就非常方便解决了,我主要采取了三个措施:

  1. 将项目中使用的BIO HttpClient化成NIO的方式:HttpAsyncClient
  2. 升级JDK为JDK8u152版本
  3. 添加耗时兜底方案,若超过SocketTimeout时间,应用A请求B应用还未结束,则手动关闭TCP连接,Tomcat主线程继续向下运行

其中第二点不用说,我通过一段伪代码来说明一下1和3.

public static String getHttpClientResult(CloseableHttpAsyncClient asyncHttpClient, HttpRequestBase httpMethod) throws IOException {
                String content = "";        
                // TCP强制断开标志
        boolean abortFlag = true;
                HttpResponse response = null;
        // 执行请求
        Future<HttpResponse> httpResponseFuture = asyncHttpClient.execute(httpMethod, null);

        try {
            httpResponse = httpResponseFuture.get(SOCKET_TIMEOUT, TimeUnit.MILLISECONDS);
            abortFlag = false;
                        // 获取返回结果
                        if (httpResponse.getEntity() != null) {
                content = EntityUtils.toString(httpResponse.getEntity(), ENCODING);
            }

        } catch (InterruptedException e) {
            // 线程被打断,重新设置标志并且向下运行
            Thread.currentThread().interrupt();
        } catch (ExecutionException e) {
            // http执行异常,包括readTimeOut、connectTimeOut
            log.error("当前线程:{},请求异常,发送TCP RST包强制断开", Thread.currentThread().getName());
        } catch (TimeoutException e) {
            /**
             * future get 超时 兜底方案,避免主线程阻塞在read方法中
             * @see java.net.SocketInputStream#socketRead0(java.io.FileDescriptor, byte[], int, int, int)
             * 若超时则发送RST包以强制连接双方断开TCP
             */
            log.error("当前线程:{},超时:{}秒,仍未获取到数据,发送RST包", Thread.currentThread().getName(), SOCKET_TIMEOUT);
        } finally {
            if (abortFlag) {
                httpMethod.abort();
            }
              // 释放资源
              if (!Objects.isNull(httpResponse)
                && !Objects.isNull(httpResponse.getEntity())
                && !Objects.isNull(httpResponse.getEntity().getContent())) {
                   httpResponse.getEntity().getContent().close();
                }
        }
                
        return abortFlag ? null : content;
    }

代码优化完毕,赶紧发版,目前我的这位同事在也没有被运维‘骚扰’过了,目前TCP升降趋势稳定喜人 ,如下:

TCP连接不释放,应用产生大量CLOSE_WAIT状态TCP

修复后的TCP涨势图.jpeg


 文章来源地址https://www.toymoban.com/news/detail-448631.html

到了这里,关于TCP连接不释放,应用产生大量CLOSE_WAIT状态TCP的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 高并发场景下大量TCP链接处于time_wait状态原因及优化思路分析

    对一台服务器进行压测(模拟高并发场景),会发现大量 TIME_WAIT 状态的 TCP连接,连接关闭后,这些TIME_WAIT会被系统回收 一般来讲,在高并发的场景中,出现TIME_WAIT连接是正常现象,一旦四次握手连接关闭之后,这些连接也就随之被系统回收了 但是在实际高并发场景中,很

    2024年02月04日
    浏览(74)
  • TCP的连接建立与释放

        TCP是面向连接的协议,运输连接是用于传输TCP报文的。TCP运输的建立和释放是每一次面向连接的通信中必不可少的过程,同时也是在面试过程中必被提问的问题之一。      TCP运输连接有三个阶段,分别是:连接建立阶段、数据传输阶段、连接释放阶段。 一:TCP的连接

    2024年02月03日
    浏览(35)
  • 5.8.4 TCP连接管理(二)TCP链接释放

    5.8.4 TCP连接管理(二)TCP链接释放 在数据传输结束之后,通信双方都可以发出释放连接的请求,如图 图中所示的主机A192.168.1.100与百度服务器B:119.75.218.70之间TCP连接释放的过程。 主机B的TCP通知对方要释放从B到A方向上的连接,将发往主机A的TCP报文段首部的终止比特FIN置1,

    2024年02月12日
    浏览(35)
  • 【计算机网络】深入理解TCP协议二(连接管理机制、WAIT_TIME、滑动窗口、流量控制、拥塞控制)

    正常情况下,TCP需要经过三次握手建立连接+四次挥手断开链接,下面看一个图: 服务器的状态变化: [CLOSED - LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接; [LISTEN - SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认

    2024年02月07日
    浏览(60)
  • 【无标题】服务器大量time_wait影响性能,如何解决

    调整内核参数:可以通过修改操作系统的内核参数来调整 TIME_WAIT 状态的处理。例如,可以调整 net.ipv4.tcp_tw_reuse 参数为 1,表示允许将 TIME_WAIT 状态的连接用于新的连接。这样可以减少 TIME_WAIT 状态连接占用的资源。 调整连接超时时间:可以调整操作系统的 TCP 连接超时时间,

    2024年01月19日
    浏览(47)
  • ORACLE 10G版本数据库系统产生大量归档日志问题的分析

    近期接到用户告知 数据库归档暴增,导致生产库归档空间满,手动删除后,归档空间很快就会满。 立即登陆数据库系统,查询发现归档日志异常增长,从以前的每小时产生3 00M ,增长到每小时产生5 9150M 。拉取问题时段的A WR 报告,将问题S QL 提交给应用运维人员,应用修复

    2024年02月03日
    浏览(55)
  • Hive产生大量Info日志的问题(由Flink On Yarn配置引起的)

    当时,hive安装部署好,并没有这个问题,后面部署了 Flink On Yarn,就没有使用过hive了。 (1)使用 bin/hive 的时候,会打印大量的INFO日志,不停的刷日志,sql语句这些能够正常执行(MR引擎或者Tez引擎都可以),但是其实无法正常使用。 (2)info日志如下所示: (3)而后想通

    2024年02月11日
    浏览(43)
  • tp6的runtime/Logs目录下产生大量日记文件,怎么取消自动生成?

    一开始查了好多网上提供的,很幸运都是抄袭别人的,没一个成功,最后无奈只能自己解决方法 其实很简单,不用修改config/log.php文件,没用因为只要有登入错误,警告,消息或者sql错误都会写入 解决方法: 关闭调试模式 配置数据库文件  .env文件 true改为false即可  总结:

    2024年02月16日
    浏览(81)
  • 97-TCP为什么要有一个“TIME_WAIT“的状态

    \\\"TIME_WAIT\\\"状态存在的原因主要有两点: 假设上图中用于确认服务器结束报文段6的TCP报文段7丢失,那么服务器将重发结束报文段,因此客户端需要停留在某个状态以处理重复收到的结束报文段.否则客户端将以复位报文段来回应服务器,服务器则认为这是一个错误,因为他期望的是一

    2024年02月01日
    浏览(63)
  • [网络] 5. TCP 链接的建立与释放~汇总

    大部分内容源于网络加之个人理解~巨人的肩膀有多大决定你可以看得多远~ 第 1 次握手建立连接时,客户端向服务器发送 SYN 报文(SEQ=x,SYN=1),并进入 SYN_SENT 状态,等待服务器确认。 第 2 次握手实际上是分两部分来完成的,即 SYN+ACK(请求和确认)报文。 ● 服务器收到

    2024年02月04日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包