那你代码检查下有没有内存泄露呢。
杨扬 <yangya...@cupdata.com> 于2022年9月19日周一 11:21写道： > > 还有一个现象，观察到 > taskHeap内存占用在逐步升高，作业刚启动的时候占用在10%左右，一周后增加至25%左右，两周后增加至50%左右，上述指的是GC后观察到的内存占用值。两周后计算算子几乎一直100%busy状态，端到端延迟已经达到了10s左右，作业已经不可用需要重启了。 > > > > > > 在 2022年9月15日，下午8:58，yidan zhao <hinobl...@gmail.com> 写道： > > > > 本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况，就是尽可能满负荷够用就行的意思。 > > > > yidan zhao <hinobl...@gmail.com> 于2022年9月15日周四 20:57写道： > >> > >> 资源足够，busy 50%+，延迟如果也可接受的话，其实就不算问题。2s延迟不算高。 > >> > >> 杨扬 <yangya...@cupdata.com> 于2022年9月15日周四 20:02写道： > >>> > >>> 目前并发度已经设定为25，每个slot内存为4G，已经使用100G内存，峰值流量10000TPS左右，资源是足够的吧？ > >>> > >>> > >>> > >>> > >>>> 在 2022年9月15日，下午7:27，yidan zhao <hinobl...@gmail.com> 写道： > >>>> > >>>> busy那就提升并发度看看效果？ > >>>> > >>>> 杨扬 <yangya...@cupdata.com <mailto:yangya...@cupdata.com>> 于2022年9月15日周四 > >>>> 14:51写道： > >>>> 各位好！ > >>>> 目前有一flink作业，大致分为3个阶段： > >>>> 读取kafka中数据（1个source，并行度3）-> 进行数据筛选和条件判断（没有窗口操作，并行度25）-> > >>>> 结果写入kafka（20多个sink，每个sink并行度3）。可参考附件图片。 > >>>> > >>>> 目前存在的问题是：作业在运行一段时间后，中间25并行度的一系列计算算子会变为busy状态（会达到50%以上），端到端的信息延迟增加，偶尔延迟会达到2秒以上。此时作业日志并没有报错、异常、告警等信息。 > >>>> > >>>> > >>>> 上述问题因为没有日志异常告警信息，本人有些无从下手解决。猜测是否因为sink数据量太多且每个sink并行度都是3会导致中间25个并行度的一系列算子和sink之间的交互产生大量shuffle引起？望各位大佬帮忙分析一下这个问题 > >>>> > >>>> > >>>> > >>>> ======================================================= > >>>> 此邮件已由 Deep Discovery Email Inspector 进行了分析。 > >>> > > > > ======================================================= > > 此邮件已由 Deep Discovery Email Inspector 进行了分析。 >
