Spark任务失败 Container be Killed 案情分析

1.案情

    很单纯的讲，就是一个spark程序以yarn-cluster的模式运行在yarn集群上，经常遇到Lost executor   Container be killed by yarn for exceed memory limits

2.spark大致架构

3、案发现场

    

        从日志可以看出，Container被杀掉，Executor丢失，导致stage中的task也失败，大致原因可以看出，堆内存基本被全部用完，同时建议设置spark.yarn.executor.memoryOverhead。

        想要解决问题，首先得明白container,executor,task之间的资源分配以及相互关系，才能知道怎么合理调整资源使得任务顺利运行。

4.yarn资源分配

       当spark任务运行在yarn集群上时，Yarn的ResourceMananger用来管理集群资源，集群上每个节点上的NodeManager用来管控所在节点的资源，从yarn的角度来看，每个节点看做可分配的资源池，当向ResourceManager请求资源时，NodeManager将会以execution container的资源形式返回，其实就是个JVM进程，提供了任务运行的各种资源，主要包括，cpu,内存，磁盘IO/网络等资源。

想必大家会有以下疑问

1、  container资源来自何方？

从上述可以知道，container资源来自于NodeManager的资源分配，来自于node节点。

2、  一个Container可以分配多少个executor?

参数yarn.nodemanager.resource.memory-mb，该参数是设置nodemanager申请到用于所有container的内存总量，单位为M。

在yarn集群上，可以通过参数executor-nums指定executor个数，executor-memory指定每个executor的内存大小,默认为1G，因此，一个Container可以分配的executor个数 = container的内存大小/executor-memory内存值。

其中，每个executor可用的内存主要由分配的堆内存和堆外内存构成，堆内存即executor-memory,堆外存由默认值和设置值来决定，即Max(executor-memory*0.1,384M)即为该executor的堆外内存。

3、任务并行度

yarn集群上，可以通过设置executor-nums和executor-cores来设置Job的task并行度，如果设置了50个executor，每个ececutor3核，即job的每个stage理论上都会有150个task并行运行，但是如果设置了参数spark.defalut.parallelism，真正的并行度为Min(spark.defalut.parallelism,150)，这里暂时不讨论并行度的合理设置。

5. 案情分析

Container进程被杀掉，因为executor的内存使用超过了Container的内存总量；task运行在executor中的时候，使用的内存可能会超过executor-memory，所以会为executor额外预留一部分内存，即日志里面提示的spark.yarn.executor.memoryOverhead代表了这部分内存，如果没有设置就会根据公式自动计算：

        其中，MEMORY_OVERHEAD_FACTOR默认为0.1，executorMemory为设置的executor-memory, MEMORY_OVERHEAD_MIN默认为384m。参数MEMORY_OVERHEAD_FACTOR和MEMORY_OVERHEAD_MIN一般不能直接修改。

        主要原因还是executor的内存不足引起的，解决方法如下：

1、如果集群资源充足，可以适当增大executor-memory，如果executor内存充足就不会使用到堆外内存，该方法利用充足的资源换取了性能。

2、如果集群资源有限，可以适当降低executor内task的并行度，使得executor消耗的内存变小，牺牲了部分性能换取任务的顺利运行。

3、配置参数spark.yarn.executor.memoryOverhead，增加executor可利用的总内存，一般建议设置为原来memoryOverhead倍数。

6.总结

    遇到spark中executor task运行资源不足的情况，在无性能问题的前提下可以根据数据计算量适当增加内存满足需求，在一定范围内，增加资源的分配与性能的提升是成正比的。但是也得考虑自身实际情况，权衡资源和性能，资源充足可以用资源换性能，资源有限，优先保障功能正常运行。

1.案情

    很单纯的讲，就是一个spark程序以yarn-cluster的模式运行在yarn集群上，经常遇到Lost executor   Container be killed by yarn for exceed memory limits

2.spark大致架构

3、案发现场

    

        从日志可以看出，Container被杀掉，Executor丢失，导致stage中的task也失败，大致原因可以看出，堆内存基本被全部用完，同时建议设置spark.yarn.executor.memoryOverhead。

        想要解决问题，首先得明白container,executor,task之间的资源分配以及相互关系，才能知道怎么合理调整资源使得任务顺利运行。

4.yarn资源分配

       当spark任务运行在yarn集群上时，Yarn的ResourceMananger用来管理集群资源，集群上每个节点上的NodeManager用来管控所在节点的资源，从yarn的角度来看，每个节点看做可分配的资源池，当向ResourceManager请求资源时，NodeManager将会以execution container的资源形式返回，其实就是个JVM进程，提供了任务运行的各种资源，主要包括，cpu,内存，磁盘IO/网络等资源。

想必大家会有以下疑问

1、  container资源来自何方？

从上述可以知道，container资源来自于NodeManager的资源分配，来自于node节点。

2、  一个Container可以分配多少个executor?

参数yarn.nodemanager.resource.memory-mb，该参数是设置nodemanager申请到用于所有container的内存总量，单位为M。

在yarn集群上，可以通过参数executor-nums指定executor个数，executor-memory指定每个executor的内存大小,默认为1G，因此，一个Container可以分配的executor个数 = container的内存大小/executor-memory内存值。

其中，每个executor可用的内存主要由分配的堆内存和堆外内存构成，堆内存即executor-memory,堆外存由默认值和设置值来决定，即Max(executor-memory*0.1,384M)即为该executor的堆外内存。

3、任务并行度

yarn集群上，可以通过设置executor-nums和executor-cores来设置Job的task并行度，如果设置了50个executor，每个ececutor3核，即job的每个stage理论上都会有150个task并行运行，但是如果设置了参数spark.defalut.parallelism，真正的并行度为Min(spark.defalut.parallelism,150)，这里暂时不讨论并行度的合理设置。

5. 案情分析

Container进程被杀掉，因为executor的内存使用超过了Container的内存总量；task运行在executor中的时候，使用的内存可能会超过executor-memory，所以会为executor额外预留一部分内存，即日志里面提示的spark.yarn.executor.memoryOverhead代表了这部分内存，如果没有设置就会根据公式自动计算：

        其中，MEMORY_OVERHEAD_FACTOR默认为0.1，executorMemory为设置的executor-memory, MEMORY_OVERHEAD_MIN默认为384m。参数MEMORY_OVERHEAD_FACTOR和MEMORY_OVERHEAD_MIN一般不能直接修改。

        主要原因还是executor的内存不足引起的，解决方法如下：

1、如果集群资源充足，可以适当增大executor-memory，如果executor内存充足就不会使用到堆外内存，该方法利用充足的资源换取了性能。

2、如果集群资源有限，可以适当降低executor内task的并行度，使得executor消耗的内存变小，牺牲了部分性能换取任务的顺利运行。

3、配置参数spark.yarn.executor.memoryOverhead，增加executor可利用的总内存，一般建议设置为原来memoryOverhead倍数。

6.总结

    遇到spark中executor task运行资源不足的情况，在无性能问题的前提下可以根据数据计算量适当增加内存满足需求，在一定范围内，增加资源的分配与性能的提升是成正比的。但是也得考虑自身实际情况，权衡资源和性能，资源充足可以用资源换性能，资源有限，优先保障功能正常运行。