开发者社区> 问答> 正文

Job结束后,JobMaster没有及时GC掉, 导致JobManager OOM了怎么办?

为了触发该异常, 预设场景: 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邮件归档

展开
收起
又出bug了-- 2021-12-03 16:59:36 747 0
1 条回答
写回答
取消 提交回答
  • 你好,短时间内提交大量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邮件归档

    2021-12-03 17:52:37
    赞同 展开评论 打赏
问答分类:
问答地址:
问答排行榜
最热
最新

相关电子书

更多
JVM的GC 立即下载
低代码开发师(初级)实战教程 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载