You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by 杨扬 <ya...@cupdata.com> on 2022/09/15 06:50:31 UTC
某作业计算算子处于busy状态
各位好!
目前有一flink作业,大致分为3个阶段:
读取kafka中数据(1个source,并行度3)-> 进行数据筛选和条件判断(没有窗口操作,并行度25)-> 结果写入kafka(20多个sink,每个sink并行度3)。可参考附件图片。
目前存在的问题是:作业在运行一段时间后,中间25并行度的一系列计算算子会变为busy状态(会达到50%以上),端到端的信息延迟增加,偶尔延迟会达到2秒以上。此时作业日志并没有报错、异常、告警等信息。
上述问题因为没有日志异常告警信息,本人有些无从下手解决。猜测是否因为sink数据量太多且每个sink并行度都是3会导致中间25个并行度的一系列算子和sink之间的交互产生大量shuffle引起?望各位大佬帮忙分析一下这个问题
Re:Re: 某作业计算算子处于busy状态
Posted by Xuyang <xy...@163.com>.
Hi, 可以尝试下使用Arthas+jmap的方式定位可能出现内存泄露的原因
--
Best!
Xuyang
在 2022-09-21 13:40:32,"杨扬" <ya...@cupdata.com> 写道:
>flink内存泄漏有什么排查的指标或者工具吗?
>比如大致定位泄漏的位置之类的。
>
>
>
>
>
>> 在 2022年9月19日,下午5:41,yidan zhao <hi...@gmail.com> 写道:
>>
>> 那你代码检查下有没有内存泄露呢。
>>
>> 杨扬 <ya...@cupdata.com> 于2022年9月19日周一 11:21写道:
>>>
>>> 还有一个现象,观察到 taskHeap内存占用在逐步升高,作业刚启动的时候占用在10%左右,一周后增加至25%左右,两周后增加至50%左右,上述指的是GC后观察到的内存占用值。两周后计算算子几乎一直100%busy状态,端到端延迟已经达到了10s左右,作业已经不可用需要重启了。
>>>
>>>
>>>
>>>
>>>> 在 2022年9月15日,下午8:58,yidan zhao <hi...@gmail.com> 写道:
>>>>
>>>> 本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况,就是尽可能满负荷够用就行的意思。
>>>>
>>>> yidan zhao <hi...@gmail.com> 于2022年9月15日周四 20:57写道:
>>>>>
>>>>> 资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。
>>>>>
>>>>> 杨扬 <ya...@cupdata.com> 于2022年9月15日周四 20:02写道:
>>>>>>
>>>>>> 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量10000TPS左右,资源是足够的吧?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 在 2022年9月15日,下午7:27,yidan zhao <hi...@gmail.com> 写道:
>>>>>>>
>>>>>>> busy那就提升并发度看看效果?
>>>>>>>
>>>>>>> 杨扬 <yangyang1@cupdata.com <ma...@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 进行了分析。
>>>
>>
>> =======================================================
>> 此邮件已由 Deep Discovery Email Inspector 进行了分析。
>
Re: 某作业计算算子处于busy状态
Posted by 杨扬 <ya...@cupdata.com>.
flink内存泄漏有什么排查的指标或者工具吗?
比如大致定位泄漏的位置之类的。
> 在 2022年9月19日,下午5:41,yidan zhao <hi...@gmail.com> 写道:
>
> 那你代码检查下有没有内存泄露呢。
>
> 杨扬 <ya...@cupdata.com> 于2022年9月19日周一 11:21写道:
>>
>> 还有一个现象,观察到 taskHeap内存占用在逐步升高,作业刚启动的时候占用在10%左右,一周后增加至25%左右,两周后增加至50%左右,上述指的是GC后观察到的内存占用值。两周后计算算子几乎一直100%busy状态,端到端延迟已经达到了10s左右,作业已经不可用需要重启了。
>>
>>
>>
>>
>>> 在 2022年9月15日,下午8:58,yidan zhao <hi...@gmail.com> 写道:
>>>
>>> 本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况,就是尽可能满负荷够用就行的意思。
>>>
>>> yidan zhao <hi...@gmail.com> 于2022年9月15日周四 20:57写道:
>>>>
>>>> 资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。
>>>>
>>>> 杨扬 <ya...@cupdata.com> 于2022年9月15日周四 20:02写道:
>>>>>
>>>>> 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量10000TPS左右,资源是足够的吧?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 在 2022年9月15日,下午7:27,yidan zhao <hi...@gmail.com> 写道:
>>>>>>
>>>>>> busy那就提升并发度看看效果?
>>>>>>
>>>>>> 杨扬 <yangyang1@cupdata.com <ma...@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 进行了分析。
>>
>
> =======================================================
> 此邮件已由 Deep Discovery Email Inspector 进行了分析。
Re: 某作业计算算子处于busy状态
Posted by yidan zhao <hi...@gmail.com>.
那你代码检查下有没有内存泄露呢。
杨扬 <ya...@cupdata.com> 于2022年9月19日周一 11:21写道:
>
> 还有一个现象,观察到 taskHeap内存占用在逐步升高,作业刚启动的时候占用在10%左右,一周后增加至25%左右,两周后增加至50%左右,上述指的是GC后观察到的内存占用值。两周后计算算子几乎一直100%busy状态,端到端延迟已经达到了10s左右,作业已经不可用需要重启了。
>
>
>
>
> > 在 2022年9月15日,下午8:58,yidan zhao <hi...@gmail.com> 写道:
> >
> > 本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况,就是尽可能满负荷够用就行的意思。
> >
> > yidan zhao <hi...@gmail.com> 于2022年9月15日周四 20:57写道:
> >>
> >> 资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。
> >>
> >> 杨扬 <ya...@cupdata.com> 于2022年9月15日周四 20:02写道:
> >>>
> >>> 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量10000TPS左右,资源是足够的吧?
> >>>
> >>>
> >>>
> >>>
> >>>> 在 2022年9月15日,下午7:27,yidan zhao <hi...@gmail.com> 写道:
> >>>>
> >>>> busy那就提升并发度看看效果?
> >>>>
> >>>> 杨扬 <yangyang1@cupdata.com <ma...@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 进行了分析。
>
Re: 某作业计算算子处于busy状态
Posted by 杨扬 <ya...@cupdata.com>.
还有一个现象,观察到 taskHeap内存占用在逐步升高,作业刚启动的时候占用在10%左右,一周后增加至25%左右,两周后增加至50%左右,上述指的是GC后观察到的内存占用值。两周后计算算子几乎一直100%busy状态,端到端延迟已经达到了10s左右,作业已经不可用需要重启了。
> 在 2022年9月15日,下午8:58,yidan zhao <hi...@gmail.com> 写道:
>
> 本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况,就是尽可能满负荷够用就行的意思。
>
> yidan zhao <hi...@gmail.com> 于2022年9月15日周四 20:57写道:
>>
>> 资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。
>>
>> 杨扬 <ya...@cupdata.com> 于2022年9月15日周四 20:02写道:
>>>
>>> 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量10000TPS左右,资源是足够的吧?
>>>
>>>
>>>
>>>
>>>> 在 2022年9月15日,下午7:27,yidan zhao <hi...@gmail.com> 写道:
>>>>
>>>> busy那就提升并发度看看效果?
>>>>
>>>> 杨扬 <yangyang1@cupdata.com <ma...@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 进行了分析。
Re: 某作业计算算子处于busy状态
Posted by yidan zhao <hi...@gmail.com>.
本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况,就是尽可能满负荷够用就行的意思。
yidan zhao <hi...@gmail.com> 于2022年9月15日周四 20:57写道:
>
> 资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。
>
> 杨扬 <ya...@cupdata.com> 于2022年9月15日周四 20:02写道:
> >
> > 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量10000TPS左右,资源是足够的吧?
> >
> >
> >
> >
> > > 在 2022年9月15日,下午7:27,yidan zhao <hi...@gmail.com> 写道:
> > >
> > > busy那就提升并发度看看效果?
> > >
> > > 杨扬 <yangyang1@cupdata.com <ma...@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 进行了分析。
> >
Re: 某作业计算算子处于busy状态
Posted by yidan zhao <hi...@gmail.com>.
资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。
杨扬 <ya...@cupdata.com> 于2022年9月15日周四 20:02写道:
>
> 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量10000TPS左右,资源是足够的吧?
>
>
>
>
> > 在 2022年9月15日,下午7:27,yidan zhao <hi...@gmail.com> 写道:
> >
> > busy那就提升并发度看看效果?
> >
> > 杨扬 <yangyang1@cupdata.com <ma...@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 进行了分析。
>
Re: 某作业计算算子处于busy状态
Posted by 杨扬 <ya...@cupdata.com>.
目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量10000TPS左右,资源是足够的吧?
> 在 2022年9月15日,下午7:27,yidan zhao <hi...@gmail.com> 写道:
>
> busy那就提升并发度看看效果?
>
> 杨扬 <yangyang1@cupdata.com <ma...@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 进行了分析。
Re: 某作业计算算子处于busy状态
Posted by yidan zhao <hi...@gmail.com>.
busy那就提升并发度看看效果?
杨扬 <ya...@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引起?望各位大佬帮忙分析一下这个问题
>
>
>