hi all,
合理的话这里的ScheduledExecutor的delay参数是否可以和slot.request.timeout和idle.timeout两个参数分开配置？
public void start(
@Nonnull JobMasterId jobMasterId,
@Nonnull String newJobManagerAddress,
@Nonnull ComponentMainThreadExecutor componentMainThreadExecutor)
throws Exception {
this.jobMasterId = jobMasterId;
this.jobManagerAddress = newJobManagerAddress;
this.componentMainThreadExecutor = componentMainThreadExecutor;
// 这里周期检查slot request timeout
scheduleRunAsync(this::checkIdleSlot, idleSlotTimeout);
scheduleRunAsync(this::checkBatchSlotTimeout, batchSlotTimeout);
if (log.isDebugEnabled()) {
scheduleRunAsync(this::scheduledLogStatus,
STATUS_LOG_INTERVAL_MS, TimeUnit.MILLISECONDS);
}
}
jun su <
[hidden email]> 于2021年4月15日周四 下午4:50写道：
> 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 <
[hidden email]> 于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
>
--
Best,
Jun Su
Locked
