flink 1.10 on yarn 内存超用，被kill怎么办？
社区的大大们好，请教个问题，我最近一个作业在线上运行，运行一天左右就被yarn kill掉了，提示超过内存限制，打印日志如下：
java.lang.Exception: [2020-06-19 00:33:57.249]Container [pid=771992,containerID=container_e05_1592035979967_0057_01_000006] is running 745472B beyond the 'PHYSICAL' memo ry limit. Current usage: 10.0 GB of 10 GB physical memory used; 19.1 GB of 21 GB virtual memory used. Killing container.
我的flink版本是1.10，分配的单TaskManager内存为10g, 查看监控，JVM堆内存一直比较平稳，怀疑是RocksDB使用的存储比较大，打开了RocksDB的block usage监控，确实一直在增长； 然后我调整了taskmanager.memory.managed.fraction为：0.7，但是还是block usage一直增长，最终被kill掉； 我已经开启了state.backend.rocksdb.memory.managed = true，按理说，RocksDB托管内存不会一直增长，看1.10官方文档介绍，RocksDB的使用内存会被控制在托管内存之内，但是我的作业使用的block usage一直在增长，最终导致被容器kill掉；
想问下 1. 什么情况下RocksDB的内存不受控制，一直增长，超过分配的managed memory 2. 在1.10版本中，还有什么情况，会导致内存超过限制，被yarn kill掉
期待各位大佬回复
*来自志愿者整理的flink邮件归档
写回答
-
单个Slot的managed memory是多少（可以通过webUI或者TM的日志观察到），rocksDB的 block cache usage会增长到多少，是一直在增长最终超过单个slot的managed memory么？
RocksDB的内存托管在绝大部分场景下是work的，但是RocksDB本身的实现限制了这个功能完美发挥作用。具体涉及到LRUcache和Writebuffer manager之间的对应关系，目前RocksDB的strict cache limit和将write buffer manager的内存申请“托管”到cache的功能是不完整的，即使在cache达到capacity的情况下，仍然可以申请内存并插入，所以存在小概率的情况会出现内存超用。
想要绕开这个问题，可以先增大TM的process内存，来增大overhead 内存 [1]，可以给RocksDB提供一定的buffer。
从RocksDB的角度的话，增大flush线程数以及降低arena 的size可以降低该问题出现概率。
[1] https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/memory/mem_detail.html#overview
*来自志愿者整理的flink邮件归档
2021-12-06 21:40:38赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
