标签：arena Container JVM Flink 内存 Jvm Memory Native
这次要说的点依旧不大，主要想给大家讲的是如果发现 Flink on Yarn 定位Native Memory超出限制一个排查思路加上第二篇文章讲的Direct Memory相关。第四篇我大概率会讲一个堆内存相关的案例。
背景
这次问题发生是在18年，我们开始调研Flink。当时运维帮忙搭建了一个不大的hadoop集群，提供给我们提交perjob任务。本以为可以开开心心的学习Flink，然鹅过程走的确实灰常艰难。
现象
Flink的Taskmanager跑一段时间就会挂掉 ，在Yarn Nodemanager日志就会发现Container 内存超了。无论怎么加内存， Taskmanager迟早都会挂掉。
(当时没有保存现场，这张图找离线的同学要的)
排查过程1: 跟进Jobmanager (AM) 启动时Taskmanager(Container)的内存分配
发现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掉。
排查过程2 使用pmap 查看进程:
接下来就怀疑是否Native内存泄漏 ,使用pmap -x <进程号> 观察taskmanager 的内存映射。写个脚本定期打印结果，会有很多连续的 64MB的anon的内存段，且每隔一段时间这个叫anon的内存段都会一直增长, 直到内存超过 Container限制被Kill掉。
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就需要考虑这种情况了。
标签：arena,Container,JVM,Flink,内存,Jvm,Memory,Native 来源： https://www.cnblogs.com/wgcn/p/15859660.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。