能否考虑针对检查点和保存点设置不同的超时时间

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

能否考虑针对检查点和保存点设置不同的超时时间

nobleyd
出发点是,检查点超时失败啥的其实并不是很重要,高峰时间有时候就是会超时失败,但并不会明显反压,因此没关系。但是,有时候需要重启任务,用保存点,那么高峰时期就是无法生成保存点,然后任务失败自动从上一次检查点恢复。这导致本身高峰时期,重启在停的过程失败导致回滚了近10分(检查点周期)。

有一种思路是直接将超时设置更长时间,但这也不行,因为检查点本身是占据资源的,设置短超时就是不希望检查点占据过多资源,相当于超时完成不了就不要继续了。

但是保存点却是人工介入,需要去重启任务,可能是bug或者什么原因必须重启任务。但高峰时间按照正常设置的超时可能就是无法完成保存点。
Reply | Threaded
Open this post in threaded view
|

Re: 能否考虑针对检查点和保存点设置不同的超时时间

Yun Tang
Hi

你的这个需求其实社区早已经有相关ticket [1]了,不过这个需求一直不是很强烈,毕竟大多数时候可以通过增大checkpoint timeout即可,增大checkpoint timeout不代表着也会增大checkpoint占据的资源。

[1] https://issues.apache.org/jira/browse/FLINK-9465

祝好
唐云
________________________________
From: 赵一旦 <[hidden email]>
Sent: Tuesday, August 18, 2020 14:38
To: [hidden email] <[hidden email]>
Subject: 能否考虑针对检查点和保存点设置不同的超时时间

出发点是,检查点超时失败啥的其实并不是很重要,高峰时间有时候就是会超时失败,但并不会明显反压,因此没关系。但是,有时候需要重启任务,用保存点,那么高峰时期就是无法生成保存点,然后任务失败自动从上一次检查点恢复。这导致本身高峰时期,重启在停的过程失败导致回滚了近10分(检查点周期)。

有一种思路是直接将超时设置更长时间,但这也不行,因为检查点本身是占据资源的,设置短超时就是不希望检查点占据过多资源,相当于超时完成不了就不要继续了。

但是保存点却是人工介入,需要去重启任务,可能是bug或者什么原因必须重启任务。但高峰时间按照正常设置的超时可能就是无法完成保存点。
Reply | Threaded
Open this post in threaded view
|

Re: 能否考虑针对检查点和保存点设置不同的超时时间

nobleyd
好的。懂了。我本来以为超时的意义,就是不希望高压情况下继续花太多时间在检查点上。

Yun Tang <[hidden email]> 于2020年8月20日周四 上午1:27写道:

> Hi
>
> 你的这个需求其实社区早已经有相关ticket [1]了,不过这个需求一直不是很强烈,毕竟大多数时候可以通过增大checkpoint
> timeout即可,增大checkpoint timeout不代表着也会增大checkpoint占据的资源。
>
> [1] https://issues.apache.org/jira/browse/FLINK-9465
>
> 祝好
> 唐云
> ________________________________
> From: 赵一旦 <[hidden email]>
> Sent: Tuesday, August 18, 2020 14:38
> To: [hidden email] <[hidden email]>
> Subject: 能否考虑针对检查点和保存点设置不同的超时时间
>
>
> 出发点是,检查点超时失败啥的其实并不是很重要,高峰时间有时候就是会超时失败,但并不会明显反压,因此没关系。但是,有时候需要重启任务,用保存点,那么高峰时期就是无法生成保存点,然后任务失败自动从上一次检查点恢复。这导致本身高峰时期,重启在停的过程失败导致回滚了近10分(检查点周期)。
>
> 有一种思路是直接将超时设置更长时间,但这也不行,因为检查点本身是占据资源的,设置短超时就是不希望检查点占据过多资源,相当于超时完成不了就不要继续了。
>
> 但是保存点却是人工介入,需要去重启任务,可能是bug或者什么原因必须重启任务。但高峰时间按照正常设置的超时可能就是无法完成保存点。
>