当前位置 : 主页 > 编程语言 > 其它开发 >

JVM诊断及工具笔记(4) 使用visualvm分析JVM堆内存泄漏

来源:互联网 收集:自由互联 发布时间:2022-05-21
在这里感谢最近一直阅读我文章的小伙伴,如果觉得文章对你有用,可以帮忙关注转载,需要的时候可以及时找到文章。 背景 今年Q3季度我们在推广业务方使用Iceberg,当时为了让不同

封面图片不要使用微信打开文章,可以使用手机/电脑浏览器

在这里感谢最近一直阅读我文章的小伙伴,如果觉得文章对你有用,可以帮忙关注转载,需要的时候可以及时找到文章。

背景

今年Q3季度我们在推广业务方使用Iceberg,当时为了让不同业务线的用户可以使用自己的hadoop账号权限把数据写到他们的hadoop集市目录,我们在Iceberg中添加了ugi,使Flink账号代理成业务方的hadoop账号。这次的堆内存泄漏就是因为我们使用ugi错误方式引发的。

现象

通过监控,我们发现用户的Flink写Iceberg任务的堆内存呈增长趋势,没多久就报堆内存oom了。

image-20211026203047331 定位过程 1.打印日志及设置oom时dump堆内存到磁盘

clusterConf.env.java.opts=-XX:+PrintGCDetails

-XX:+PrintGCDateStamps -Xloggc:${LOG_DIRS}/gc.log -XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/tmp/${CONTAINER_ID}.dump

2.使用visualvm分析堆内存文件 (一定要计算对象保留大小有助于分析)

发现最多的实例竟然是Entry对象,开始去分析其引用(主要是想查找找有没有比较大的HashMap),

image-20211026203919097

​ 如下图好多引用都是DistributedFileSystem引用的DFSclient对象。

image-20211026205035451

搜下DFSClient对象,发现其数量有16000多个。DFSClient对象为什么会这么多,继续往下跟发现其被缓存到DistributedFileSystem的cache里面。

image-20211026205302968

​ cache中具体缓存使用的key如图 scheme, authority,ugi,unique 其中unique可以忽略,在visualvm上看都是相同的,scheme及authority记录着几个namenode的地址,值也并不多,唯一异常的就是存在超大量的ugi对象,此时内存泄漏的真凶差不多找到了。

发现在改造的Iceberg支持代理用户的代码中,每次调用getFs方法都要重新创建一个ugi对象。

image-20211026211556533

解决

ugi按用户缓存起来之后,cache里面的DFSClient对象数量就符合预期了。这个任务就再也没有发生过堆内存泄漏了。

image-20211026222721656

上一篇:eBPF+Ftrace 合璧剑指:no space left on device?
下一篇:没有了
网友评论