hi all, 通过看源码发现了问题 :
短时间内提交大量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的发生 jun su <sujun891...@gmail.com> 于2021年4月13日周二 下午3:18写道： > hi all, > 为了触发该异常, 预设场景: > 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执行完后， 还会存留一段时间？ 有些引用还未释放？ > -- > Best, > Jun Su > -- Best, Jun Su
