Re: TaskManager的Slot的释放时机

[Zhilong Hong]

Hello, johnjlong:

TaskExecutor#cancel是RPC调用，不包含TM是否存活的信息。TM是否存活是由Heartbeat
Service来负责检测的，目前heartbeat.timeout配置项 [1]
的默认值为50s。而RPC调用的超时配置项akka.ask.timeout [2]
的默认值为10s。如果想要尽快检测到TM丢失的情况，可以将这两个配置项的值调小，但这有可能会导致集群或作业不稳定。

关于降低heartbeat timeout时长社区目前已有讨论，具体可以参考：[3] 和 [4]

[1]
https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/config/#heartbeat-timeout
[2]
https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/config/#akka-ask-timeout
[3] https://issues.apache.org/jira/browse/FLINK-23403
[4] https://issues.apache.org/jira/browse/FLINK-23209

Sincerely,
Zhilong

On Tue, Jan 25, 2022 at 10:06 AM johnjlong  wrote:

> 各位大佬好，请教一个问题。
> 我根据ResourceID主动释放TM的链接的时候，我发现TM对应的Slots仅仅是标记为free。
>
> 而其真正是释放却要等到JobMaster主动cancel整个ExecuteGraph的时候，此时会逐个调用每个定点所在的slot的TM的cancel方法。
> 但是此时相关联的TM已经close掉，触发了rpc超时，默认20s。然后slot才会被释放。
>
>
> 我的问题是：为什么不在调用TaskExecutor的cancelTask之间判断下TM是否存活，如果不存活就直接走cancel的流程，不用等rpc超时后，才进行下一步？？？
>
> 附上日志截图：
>
> johnjlong
> johnjl...@163.com
>
> 
> 签名由网易邮箱大师 定制
>

TaskManager的Slot的释放时机

[johnjlong]

各位大佬好，请教一个问题。
我根据ResourceID主动释放TM的链接的时候，我发现TM对应的Slots仅仅是标记为free。
而其真正是释放却要等到JobMaster主动cancel整个ExecuteGraph的时候，此时会逐个调用每个定点所在的slot的TM的cancel方法。
但是此时相关联的TM已经close掉，触发了rpc超时，默认20s。然后slot才会被释放。


我的问题是：为什么不在调用TaskExecutor的cancelTask之间判断下TM是否存活，如果不存活就直接走cancel的流程，不用等rpc超时后，才进行下一步？？？


附上日志截图：


| |
johnjlong
|
|
johnjl...@163.com
|
签名由网易邮箱大师定制