zhengchenyu commented on issue #1011: URL: https://github.com/apache/incubator-uniffle/issues/1011#issuecomment-1635686571
> This document is written in my mother language. If someone wanna english version, I will translate it. # uniffle下优化tez task重跑 ## 1 背景 计算框架一般都有对成功的task进行重跑的机制。譬如使用NM端shuffle服务，如果NM无法使用，那么在其上运行的map产生的数据就无法提供给下游reduce，因此需要在健康的NM节点执行task重跑。因此，一般情况下计算框架会提供一些机制重跑上游任务。 但是在RemoteShuffleService模式下，如果task已经成功将数据发送给RSS服务。则出现NM无法使用等情况是没有必要进行重跑的。因此需要避免类似的情况。也就意味着我们要分析所有处于SUCCEEDED状态的task是如何进行重跑的。 ## 2 tez中task重跑逻辑分析 Task重跑主要指的已经处于SUCCEEDED状态的task，因为某种原因变为非SUCCEEDED状态，达到某种条件后对task进行重跑。我们需要甄别出tez中有哪些逻辑会产生task重跑，并识别出哪些在RSS模式下是不需要进行重跑的，并进行禁止。 Tez主要是按照DAG->Vertx->Task->TaskImpl对任务进行组织。这里直接给出结论(关于状态转换的分析详见附件)，有以下几种情况可能会导致已经处于SUCCEEDED状态的task进行重跑: [](url) * (a) 节点上运行失败taskattempt过多导致 * (b) 进入开启黑名单状态会主动对所有节点执行(a)的检查 * (c) 从RM端获取阶段处于为unhealth状态 * (d) 足够多的下游通知读取失败。 ### 2.1 节点上运行失败taskattempt过多导致 #### 原因 节点上运行失败的taskattempt足够多的话(超过tez.am.maxtaskfailures.per.node，默认为10)，杀死其上所有container的所有taskattempt，必要时并让其重跑。 #### 处理动作 RSS模式下需要禁止这类重跑。 ### 2.2 进入开启黑名单状态会主动对所有节点执行2.1的检查 #### 原因 当任务的黑名单机器的数目大于总机器的33%(tez.am.node-blacklisting.ignore-threshold-node-percent), 会进入忽略黑名单功能。如果从高于33%变为小于33%的话，就启动黑名单，在这个启动过程中会查看所有的node，对每个node都采取(1)的逻辑进行检查，必要时进行重跑。 #### 处理动作 RSS模式下需要禁止这类重跑。 ### 2.3 从RM端获取节点处于为unhealth状态。 #### 原因 当从RM端得到节点变为unhealthy状态后，如果tez.am.node-unhealthy-reschedule-tasks设置为true(默认为false), 杀死其上所有Container的所有TaskAttempt，必要时并让其重跑。 #### 处理动作 RSS模式下需要禁止这类重跑，直接置tez.am.node-unhealthy-reschedule-tasks为false即可。 ### 2.4 足够多的下游通知读取失败。 #### 原因 当有足够的下游节点的task通知读取失败(以host维度计算，大于总机器数的20%)，则会杀死该TaskAttempt，必要是进行重跑操作。 #### 处理动作 RSS模式下如果很多下游通知读取失败，可能是uniffle服务存在问题，直接让任务失败??? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uniffle.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
