为了触发该异常, 预设场景: 1. jobmanager 分配1g内存 2. 持续跑一个离线查询job, 特点是查询文件数较大(1w个parquet文件), 任务在1s内结束
如此跑到30-40次后, jm会oom异常退出, 此时dump出堆栈可以看92%的内存被 akka.actor.LightArrayRevolverScheduler$TaskQueue[512]占用,前30-40个TaskQueue中任然存在JobMaster, 由于文件数有1w个,所以每个JobMaster中的jobGraph和FileSplit对象也会较大,所以导致新的job无法构建导致oom
而同样的jm内存配置 + 文件数, 如果任务运行的稍慢,比如运行10s才结束, 这时JM虽然也有高堆栈占用导致高GC的问题,但是不会出现OOM , 说明JobMaster在被垃圾回收.
我的疑问是既然 JobMaster 已经在job执行完后 onStop 掉释放了资源, 为什么没被及时或者无法被回收, 从而导致JM的oom呢? JobMaster在job执行完后, 还会存留一段时间? 有些引用还未释放*来自志愿者整理的FLINK邮件归档
你好,短时间内提交大量Job后, JobManager进程会OOM的原因是这些Job所属的JobMaster没被及时的GC掉.
原因是JobMaster所属的SlotPoolImpl在启动时后会定期的检查有没有pending slot request, 如果发生了time out的情况会做相应的cancel操作, 而这个周期任务的延迟是slot.idle.timeout和slot.request.timeout两个参数决定的, 所以在Job执行完毕后, 因为周期检查的线程还有一次在等待周期时间, 这导致SlotPoolImpl和JobMaster都在这个delay时间内GC不掉.
同时job包含大量文件数, 导致JobMaster中包含的ExecutionGraph和FileSplit等信息占用堆栈空间比较大, 最后导致OOM
通过调整slot.idle.timeout和slot.request.timeout两个参数来缩短delay的时间, 保证GC及时回收JobMaster, 就会避免OOM的发生*来自志愿者整理的FLINK邮件归档
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。