使用Jstat、jmap分析内存泄漏问题

 


[if !supportLists]1、 [endif]问题现象描述

国际化中台新增文案,编辑文案20用户并发时,部分请求结果返回502 bad geteway错误,



[if !supportLists]2、 [endif]问题定位过程

2.1、初步怀疑是nignx服务器问题,查看nignx日志,定位是后端应用报错

[if !vml]

[endif]

2.2、查看if-zaif-cps-copywriting-agent-mock-dev应用服务器有重启记录。

确认是在重启时,请求返回失败。

[if !vml]

[endif]

2.3、再查看重启原因是因为内存资源消耗完,日志存在OutOfMemoryError的报错信息,容器对服务进行的重启。

[if !vml]

[endif]

2.3、分析内存资源耗尽的原因,在Linxu后端使用命令查看内存GC情况

Jstat  -gcutil 6 1000

[if !vml]

[endif]

结果分析,E — Heap上的 Eden space 区已使用空间的百分比消耗非常快,不停进行YGC,但是内存基本不释放。待old区内存百分比被占满后开始Full gc,不能释放内存,多次尝试FULL gc仍不能释放内存,容器重启该服务。


[if !supportLists]3、 [endif]问题分析过程

3.1、使用—命令生成dump文件。对内存进行分析

jmap -dump:format=b,file=/tmp/dump.dat  PID或jmap-dump:live,format=b,file=aaa.hprof 22400



3.2、down到本地后使用MAT工具对dump文件分析

[if !vml]

[endif]

初步定位内存泄漏的代码位置


3.3、在Leak

Suspects页面会给出可能的内存泄露,进入Leak Suspects,查看那些类可能发生内存泄露

[if !vml]

[endif]

点击Details发现有自己的代码。

[if !vml]

[endif]

3.4、线程池的问题,进入Details查看详情:

在详情页面Shortest Paths To the Accumulation

Point表示GC root到内存消耗聚集点的最短路径,如果某个内存消耗聚集点有路径到达GC root,则该内存消耗聚集点不会被当做垃圾被回收

[if !vml]

[endif]

查看前面占用大的class

[if !vml]

[endif]

如果类的Objects占用很大,极可能就是这里的问题。

[if !vml]

[endif]


[if !supportLists]4、 [endif]问题解决方案

[if !vml]

[endif]

[if !vml]

[endif]


如上只是修改其中一个可能存在性能问题的代码

[if !supportLists]5、 [endif]优化后结果

具体问题暂未彻底优化,当前性能结果满足生产业务量,且存在双实例,不影响生产业务,对生产环境进行监控观察后根据情况再审视是否再次优化。

你可能感兴趣的:(使用Jstat、jmap分析内存泄漏问题)