spark异常篇-Removing executor 5 with no recent heartbeats: 120504 ms exceeds timeout 120000 ms 可能的解决方案

问题描述与分析

题目中的问题大致可以描述为：

由于某个 Executor 没有按时向 Driver 发送心跳，而被 Driver 判断该 Executor 已挂掉，此时 Driver 要把 该 Executor 上执行的任务发送给另外一个 Executor 重新执行；

默认等待时长为 spark.network.timeout=120s 

完整报错大概如下

17/01/13 09:13:08 WARN spark.HeartbeatReceiver: Removing executor 5 with no recent heartbeats: 161684 ms exceeds timeout 120000 ms
17/01/13 09:13:08 ERROR cluster.YarnClusterScheduler: Lost executor 5 on slave10: Executor heartbeat timed out after 161684 ms
17/01/13 09:13:08 WARN scheduler.TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, slave10): ExecutorLostFailure (executor 5 exited caused by one of the running tasks) Reason: Executor heartbeat timed out after 161684 ms
17/01/13 09:13:08 INFO scheduler.DAGScheduler: Executor lost: 5 (epoch 0)
17/01/13 09:13:08 INFO cluster.YarnClusterSchedulerBackend: Requesting to kill executor(s) 5
17/01/13 09:13:08 INFO scheduler.TaskSetManager: Starting task 0.1 in stage 0.0 (TID 5, slave06, partition 0,RACK_LOCAL, 8029 bytes)
17/01/13 09:13:08 INFO storage.BlockManagerMasterEndpoint: Trying to remove executor 5 from BlockManagerMaster.
17/01/13 09:13:08 INFO storage.BlockManagerMasterEndpoint: Removing block manager BlockManagerId(5, slave10, 34439)
17/01/13 09:13:08 INFO storage.BlockManagerMaster: Removed 5 successfully in removeExecutor
17/01/13 09:13:08 INFO scheduler.DAGScheduler: Host added was in lost list earlier: slave10
17/01/13 09:13:08 INFO yarn.ApplicationMaster$AMEndpoint: Driver requested to kill executor(s) 5.
17/01/13 09:13:08 INFO scheduler.TaskSetManager: Finished task 0.1 in stage 0.0 (TID 5) in 367 ms on slave06 (5/5)
17/01/13 09:13:08 INFO scheduler.DAGScheduler: ResultStage 0 (saveAsNewAPIHadoopFile at DataFrameFunctions.scala:55) finished in 162.495 s

Executor 没有按时向 Driver 发送心跳，原因可能为

1. 真的挂掉

2. 执行某任务由于资源不够造成死机

3. 其他原因

我们主要解决第二个

 

解决方案

增加资源---增加 memoryOverhead

简单来解释下 

spark.yarn.executor.memoryOverhead 的内存是由 spark tungsten 自己的管理机制去管理，用的时候申请，用完释放，内存利用率高，【鉴于 JVM 的内存管理，GC 效率低，才有了这种管理机制】

而 spark.executor.memory 的内存是由 JVM 管理，分配，回收，涉及多种垃圾回收机制，用不好效率低

原因分析

如果用于存储 RDD 的空间不足，那么后存储的 RDD 的 partition 会覆盖之前的 RDD 的 partition，导致之前的 RDD 丢失，当使用丢失的 RDD partition 时，需要重新计算；

如果 java 堆或者永久代的内存不足，则会产生各种 OOM 情况，executor 会被杀死，spark 会重新申请一个 container 运行 executor，失败的 task 或者丢失的数据都会在这个 executor 上重新执行；

如果实际运行过程中，ExecutorMemory + MemoryOverhead 之和(JVM 进程总内存) 超过 container 容量，yarn 会直接杀死该 container，executor 日志中不会有记录，spark 会重新申请 container 运行 executor；

如果 java 堆以外的 JVM 进程占用内存较多，需要将 MemoryOverhead 设置足够大，否则 executor 将会被杀死

具体操作

spark.yarn.executor.memoryOverhead 的默认配置为 max(executorMemory * 0.10, 384)，单位为 M

我们可以手动设置

--conf spark.yarn.executor.memoryOverhead=512

--conf spark.yarn.driver.memoryOverhead=512

减少资源占用---使用 combineByKey

如 reduceByKey，可以有效的减少内存占用

rdd.repartition(20).map(mymap).groupBy(mygroup).mapValues(len).collect()
rdd.repartition(20).map(mymap).map(mygroup).reduceByKey(lambda x, y: x+y).collect()

另外还有几种较为简单的方法

1. 增加等待时长 spark.network.timeout

2. 在资源不变的情况下，增加 executor 内存，减少 executor 数量，增加 executor cores，这个自己想想，反正就是总的不变，保证每个 task 有足够内存

参考资料：

https://blog.csdn.net/gangchengzhong/article/details/76474129

https://www.cnblogs.com/RichardYD/p/6281745.html　　spark yarn任务的executor 无故 timeout之原因分析

http://f.dataguru.cn/thread-906602-1-1.html　　spark.yarn.executor.memoryOverhead