其他分享
首页 > 其他分享> > JVM诊断及工具笔记(3) 使用pmap 定位一次Jvm Native Memory泄漏

JVM诊断及工具笔记(3) 使用pmap 定位一次Jvm Native Memory泄漏

作者:互联网

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

这次要说的点依旧不大,主要想给大家讲的是如果发现 Flink on Yarn 定位Native Memory超出限制一个排查思路加上第二篇文章讲的Direct Memory相关。第四篇我大概率会讲一个堆内存相关的案例。

背景

这次问题发生是在18年,我们开始调研Flink。当时运维帮忙搭建了一个不大的hadoop集群,提供给我们提交perjob任务。本以为可以开开心心的学习Flink,然鹅过程走的确实灰常艰难。

现象

Flink的Taskmanager跑一段时间就会挂掉 ,在Yarn Nodemanager日志就会发现Container 内存超了。无论怎么加内存, Taskmanager迟早都会挂掉。

image-20220103230204101

(当时没有保存现场,这张图找离线的同学要的)

排查过程1: 跟进Jobmanager (AM) 启动时Taskmanager(Container)的内存分配

image-20211025192335739

image-20220112232916610

发现Jobmanager在拼接Taskmanager的启动脚本时,会将Container Memory中只要不是堆内存都会留给Direct Memory (当时测试使用的版本是1.6比较旧,高版本忘了是1.10还是1.11以上已经有配置可以预留内存给Native Memory),且会使用-XX:MaxDirectMemorySize做限制。 既然堆内存,Direct Memory 都可以被限制住,那么预留些内存分配给Native Memory 是不是Container Memory就不会超了。所以加了个配置,从Direct memory 减去一部分什么也不做就预留给Native memory。然鹅,不管预留多少内存1G 3G 5G 给Native Memory 。Container 都会因为内存超出限制被kill掉。

image-20211025221759298

排查过程2 使用pmap 查看进程:

接下来就怀疑是否Native内存泄漏 ,使用pmap -x <进程号> 观察taskmanager 的内存映射。写个脚本定期打印结果,会有很多连续的 64MB的anon的内存段,且每隔一段时间这个叫anon的内存段都会一直增长, 直到内存超过 Container限制被Kill掉。

image-20211025202214290

anon是什么,一顿网上搜索之后发现终于明白:

anon是glibc(为应用系统在多核心CPU和多Sockets环境中高伸缩性提供了一个动态内存分配的特性增强)引入了per thread arena内存池,多个线程之间不再共用一个arena内存区域了,这样避免内存分配时需要额外的锁来降低性能。简单的说就是glibc为了提高性能,为每个线程分配额外的内存池,减少互斥的情况。

一个32位的应用程序进程,最大可创建 2 CPU总核数个arena内存池(MALLOC_ARENA_MAX),每个arena内存池大小为1MB,一个64位的应用程序进程,最大可创建 8 CPU总核数个arena内存池(MALLOC_ARENA_MAX),每个arena内存池大小为64MB

但是glibc 部分版本存在bug 并不会按上述的逻辑生成内存池

如果不考虑内存分配的性能,遇到这样的问题时,有两种解决方案

1.使用export MALLOC_ARENA_MAX=1禁用per thread arena (hadoop默认是设成了4,但是我们的flink服务依然是会内存泄漏)

2.更换glibc的替代方案。比如 Jemalloc , Tcmalloc

 

后续

去年(2020年)年底Flink社区在Flink docker镜像默认将Jemalloc替换掉了glibc。使用flink高版本(12+) on k8s 的同学应该是不必再考虑文中介绍的问题。但是如果使用flink on yarn就需要考虑这种情况了。

image-20211025213253202

 

标签:arena,Container,JVM,Flink,内存,Jvm,Memory,Native
来源: https://www.cnblogs.com/wgcn/p/15859660.html