性能问答>Flink Jobmanager Metaspace OOM>
5回复
2年前

Flink Jobmanager Metaspace OOM



环境说明:

系统后台换了一套ETL的框架,把MySQL中的数据用Flink转到ClickHouse,再经过Flink处理后再次写入到ClickHouse(中间用了zookeeper和kafka)。

配置截图如下:

Jobmanager:

Taskmanager:(6个TM,slots共60个,每个TM分配10个slot)

问题描述:

现在遇到个奇怪的问题,Flink的Jobmanager在job指派给taskmanager后执行过程中,Metaspace内存会快速上升直到 OOM。

尝试过的解决方法:

先使用 jcmd <pid> VM.metaspace 命令查看了 metaspace 的状态:

看到了有7674个加载器,134779个类被加载(共享类有1175个),觉得似乎有点太多了?

job一共有26个,跑完一轮 jobmanager 中的 metaspace 内存会上升 330M左右(配置了1G,那就是30%左右);

所以跑了3轮就把 1G 的 metaspace 给几乎占满了,继续跑就会 OOM。

然后看了下面的 Waste 的 In free chunks 也并不大,总共3%,顺势看了眼上面的 freelists,感觉也还好。

然后去分析了下GC日志(用的G1收集器),截图如下:

堆内存的GC是正常的,但是看 metaspace 就几乎没有被回收过内存。

个人猜测可能是有很多类加载器没有卸载 堆积在了元空间内存中 GC后那些内存没有返回给操作系统 最终导致的metaspace OOM。(但是我没有证据 T.T)

然后呢,开始用 MAT 分析 heap dump 文件,先看了 histogram,流程如下:

GC root可达的对象中,除了上面划出来的 mysql-cj-abandoned-connection-cleanup 线程
 (查了下是用来关闭mysql conntction的 不关闭线程会一直被强引用占着 就没办法释放),
其他都是unreachable对象。

问了开发 开发说不合理。。。因为代码里 mysql的connection 是用try 括起来的,按理来说try结束了就退出了

然后也获取了GC root 可达的最短路径:

然后再排序了下 retained heap 再查了一遍:

Path to GC root:

shortest Path to GC root:

heap dump文件及 gc日志链接:(其中有3份dump文件 是在metaspace 内存逐步上升的过程中分别dump的)

链接: https://pan.baidu.com/s/1RcTGhuCOxINqAnn6B_bkOQ 提取码: 8t8d

请求大佬的协助,分析的我人快麻了 T.T...

1620 阅读
请先登录,查看5条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步