您现在的位置是:主页 > Web前端技术 > Web前端技术

Java内存泄漏实例排查分析编程语言

IDCBT2022-01-07服务器技术人已围观

简介这篇文章主要介绍“Java内存泄漏实例排查分析”,在日常操作中,相信很多人在Java内存泄漏实例排查分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大

这篇文章主要介绍“Java内存泄漏实例排查分析”,在日常操作中,相信很多人在Java内存泄漏实例排查分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Java内存泄漏实例排查分析”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

问题出现

晚上七点多开始,我就开始不停地收到报警邮件,邮件显示探测的几个接口有超时情况。

多数执行栈都在:

java.io.BufferedReader.readLine(BufferedReader.java:371) java.io.BufferedReader.readLine(BufferReader.java:389) java_io_BufferedReader$readLine.call(Unknown Source) com.domain.detect.http.HttpClient.getResponse(HttpClient.groovy:122) com.domain.detect.http.HttpClient.this$2$getResponse(HttpClient.groovy)

这个线程栈的报错我见得多了,我们设置的 HTTP DNS 超时是 1s,connect 超时是 2s,read 超时是 3s。

这种报错都是探测服务正常发送了 HTTP  请求,服务器也在收到请求正常处理后正常响应了,但数据包在网络层层转发中丢失了,所以请求线程的执行栈会停留在获取接口响应的地方。

这种情况的典型特征就是能在服务器上查找到对应的日志记录。而且日志会显示服务器响应完全正常。

与它相对的还有线程栈停留在 Socket connect 处的,这是在建连时就失败了,服务端完全无感知。

我注意到其中一个接口报错更频繁一些,这个接口需要上传一个 4M 的文件到服务器,然后经过一连串的业务逻辑处理,再返回 2M 的文本数据。

而其他的接口则是简单的业务逻辑,我猜测可能是需要上传下载的数据太多,所以超时导致丢包的概率也更大吧。

根据这个猜想,群登上服务器,使用请求的 request_id 在近期服务日志中搜索一下,果不其然,就是网络丢包问题导致的接口超时了。

当然这样 leader 是不会满意的,这个结论还得有人接锅才行。于是赶紧联系运维和网络组,向他们确认一下当时的网络状态。

网络组同学回复说是我们探测服务所在机房的交换机老旧,存在未知的转发瓶颈,正在优化,这让我更放心了,于是在部门群里简单交待一下,算是完成任务。

问题爆发

本以为这次值班就起这么一个小波浪,结果在晚上八点多,各种接口的报警邮件蜂拥而至,打得准备收拾东西过周日单休的我措手不及。

这次几乎所有的接口都在超时,而我们那个大量网络 I/O 的接口则是每次探测必超时,难道是整个机房故障了么?

我再次通过服务器和监控看到各个接口的指标都很正常,自己测试了下接口也完全  OK,既然不影响线上服务,我准备先通过探测服务的接口把探测任务停掉再慢慢排查。

结果给暂停探测任务的接口发请求好久也没有响应,这时候我才知道没这么简单。

标签:

很赞哦! ()

本栏推荐