关于1.12新增的initialize阶段时间较长问题

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

关于1.12新增的initialize阶段时间较长问题

nobleyd
如上,目前发现以前很快(10-30s)内能从敲命名到running的任务。现在有时候innitialize阶段就得1-2min。不清楚啥情况。
Reply | Threaded
Open this post in threaded view
|

Re: 关于1.12新增的initialize阶段时间较长问题

nobleyd
这个问题现在还有个现象,我提交任务,web
UI就类似卡住状态,过一会刷新出来任务,会有4-5个initialize状态的任务,然后几秒之内陆续消失,剩下1个。

目前怀疑是有什么重试机制,导致重复提交N个任务,然后可能还有什么去重机制,然后其中几个陆续自动停掉?

赵一旦 <[hidden email]> 于2021年1月26日周二 上午10:51写道:

> 如上,目前发现以前很快(10-30s)内能从敲命名到running的任务。现在有时候innitialize阶段就得1-2min。不清楚啥情况。
>
Reply | Threaded
Open this post in threaded view
|

Re: 关于1.12新增的initialize阶段时间较长问题

zilong xiao
有截图吗?

赵一旦 <[hidden email]> 于2021年2月7日周日 下午3:13写道:

> 这个问题现在还有个现象,我提交任务,web
> UI就类似卡住状态,过一会刷新出来任务,会有4-5个initialize状态的任务,然后几秒之内陆续消失,剩下1个。
>
> 目前怀疑是有什么重试机制,导致重复提交N个任务,然后可能还有什么去重机制,然后其中几个陆续自动停掉?
>
> 赵一旦 <[hidden email]> 于2021年1月26日周二 上午10:51写道:
>
> > 如上,目前发现以前很快(10-30s)内能从敲命名到running的任务。现在有时候innitialize阶段就得1-2min。不清楚啥情况。
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 关于1.12新增的initialize阶段时间较长问题

nobleyd
截图也没办法反应动态变化的过程。
目前是10机器的Standalone集群,状态在5G左右。通过flink-client端提交任务,然后web-ui刷新就一直转圈,过一会(几十秒大概)就OK啦,然后刚刚OK一瞬间会有很多个处于Initialize状态的任务,然后慢慢(10s内吧)没掉。

flink-client端的话,有时候正常提交完成,有时候出现报错(类似说是重复任务的)。


zilong xiao <[hidden email]> 于2021年2月7日周日 下午3:25写道:

> 有截图吗?
>
> 赵一旦 <[hidden email]> 于2021年2月7日周日 下午3:13写道:
>
> > 这个问题现在还有个现象,我提交任务,web
> > UI就类似卡住状态,过一会刷新出来任务,会有4-5个initialize状态的任务,然后几秒之内陆续消失,剩下1个。
> >
> > 目前怀疑是有什么重试机制,导致重复提交N个任务,然后可能还有什么去重机制,然后其中几个陆续自动停掉?
> >
> > 赵一旦 <[hidden email]> 于2021年1月26日周二 上午10:51写道:
> >
> > > 如上,目前发现以前很快(10-30s)内能从敲命名到running的任务。现在有时候innitialize阶段就得1-2min。不清楚啥情况。
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 关于1.12新增的initialize阶段时间较长问题

nobleyd
It also maybe have something to do with my job's first tasks. The second
task have two input, one is the kafka source stream(A), another is
self-defined mysql source as broadcast stream.(B)
In A: I have a 'WatermarkReAssigner', a self-defined operator which add an
offset to its input watermark and then forward to downstream.
In B: The parallelism is 30, but in my rich function's implementation, only
the subtask-0 will do mysql query and send out records, other subtasks do
nothing. All subtasks will send max_watermark - 86400_000 as the watermark.
Since both the first task have some self-defined source or implementation,
I do not know whether the problem have something to do with it.

赵一旦 <[hidden email]> 于2021年2月7日周日 下午4:00写道:

> 截图也没办法反应动态变化的过程。
>
> 目前是10机器的Standalone集群,状态在5G左右。通过flink-client端提交任务,然后web-ui刷新就一直转圈,过一会(几十秒大概)就OK啦,然后刚刚OK一瞬间会有很多个处于Initialize状态的任务,然后慢慢(10s内吧)没掉。
>
> flink-client端的话,有时候正常提交完成,有时候出现报错(类似说是重复任务的)。
>
>
> zilong xiao <[hidden email]> 于2021年2月7日周日 下午3:25写道:
>
>> 有截图吗?
>>
>> 赵一旦 <[hidden email]> 于2021年2月7日周日 下午3:13写道:
>>
>> > 这个问题现在还有个现象,我提交任务,web
>> > UI就类似卡住状态,过一会刷新出来任务,会有4-5个initialize状态的任务,然后几秒之内陆续消失,剩下1个。
>> >
>> > 目前怀疑是有什么重试机制,导致重复提交N个任务,然后可能还有什么去重机制,然后其中几个陆续自动停掉?
>> >
>> > 赵一旦 <[hidden email]> 于2021年1月26日周二 上午10:51写道:
>> >
>> > >
>> 如上,目前发现以前很快(10-30s)内能从敲命名到running的任务。现在有时候innitialize阶段就得1-2min。不清楚啥情况。
>> > >
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: 关于1.12新增的initialize阶段时间较长问题

nobleyd
In reply to this post by nobleyd
这个问题有人清楚吗。今天又是重启,5min了,还是initializing阶段,client部分直接报异常退出(报的Caused by:
org.apache.flink.runtime.rest.util.RestClientException: [Internal server
error., <Exception on server side:
org.apache.flink.runtime.client.DuplicateJobSubmissionException: Job has
already been submitted.),应该是自动重试然后发现已提交了该任务所以报错。

大佬给介绍下initializinng阶段都干嘛,什么事情可能耗时。
比如状态的恢复?

赵一旦 <[hidden email]> 于2021年2月7日周日 下午4:00写道:

> 截图也没办法反应动态变化的过程。
>
> 目前是10机器的Standalone集群,状态在5G左右。通过flink-client端提交任务,然后web-ui刷新就一直转圈,过一会(几十秒大概)就OK啦,然后刚刚OK一瞬间会有很多个处于Initialize状态的任务,然后慢慢(10s内吧)没掉。
>
> flink-client端的话,有时候正常提交完成,有时候出现报错(类似说是重复任务的)。
>
>
> zilong xiao <[hidden email]> 于2021年2月7日周日 下午3:25写道:
>
>> 有截图吗?
>>
>> 赵一旦 <[hidden email]> 于2021年2月7日周日 下午3:13写道:
>>
>> > 这个问题现在还有个现象,我提交任务,web
>> > UI就类似卡住状态,过一会刷新出来任务,会有4-5个initialize状态的任务,然后几秒之内陆续消失,剩下1个。
>> >
>> > 目前怀疑是有什么重试机制,导致重复提交N个任务,然后可能还有什么去重机制,然后其中几个陆续自动停掉?
>> >
>> > 赵一旦 <[hidden email]> 于2021年1月26日周二 上午10:51写道:
>> >
>> > >
>> 如上,目前发现以前很快(10-30s)内能从敲命名到running的任务。现在有时候innitialize阶段就得1-2min。不清楚啥情况。
>> > >
>> >
>>
>