运行HQL时，报错：Container killed by YARN for exceeding memory limits

1 出现问题现象

搭建Hive On Spark 模式，运行HQL时：出现如下错误：

ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 4.5 GB of 4.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead or disabling yarn.nodemanager.vmem-check-enabled because of YARN-4714

Hadoop 中yarn-site.xml部分资源定义相关参数官网链接

yarn.nodemanager.resource.memory-mb   每个节点上yarn可使用的内存，默认为8G，如果节点内存资源不足8G，要减少这个值，yarn不会智能的去检测内存资源，一般这个设置yarn的可用内存资源yarn.nodemanager.resource.cpu-vcores  每个节点服务器上yarn可以使用的CPU个数，默认是8，推荐将值配置与物理核心个数相同(一般可以配置成（1-2）*物理Cpu核数)，如果节点CPU核心不足8个，要调小这个值，yarn不会智能的去检测物理核心数yarn.scheduler.maximum-allocation-mb   单个任务最大申请物理内存量，默认8GB
yarn.scheduler.minimum-allocation-mb   单个任务最小申请物理内存量，默认1GB
yarn.scheduler.increment-allocation-mb  单个任务内存不够用时一次性加多少内存 单位MB。CDH默认512Myarn.scheduler.minimum-allocation-vcores  单个任务最大可申请的最小CPU个数，默认1个
yarn.scheduler.maximum-allocation-vcores   单个任务最大可申请的最大CPU个数，默认4个，如果申请资源时，超过这个配置，会抛出InvalidResourceRequestExceptionyarn.nodemanager.pmem-check-enabled  是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true
yarn.nodemanager.vmem-check-enabled  是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是trueyarn.nodemanager.vmem-pmem-ratio：每使用 1MB 物理内存，最多可用的虚拟内存数，默认值2.1

针对上面的值，如何去设置？
举个例子，如果有一个服务器16核，64G内存，那么如何达到资源利用最大化呢yarn.nodemanager.resource.cpu-vcores Cpu核数，如果公司服务器比较富裕，设置比例1：1，即该值设置成16，如果公司服务器不富裕，设置比例1：2，即该值设置成32yarn.nodemanager.resource.memory-mb 总内存，一般要预留15-20%的内存给系统和其他服务使用，那么可用内存就是64GB*0.8=51.2GB,我们设置成50G就可以了（固定经验值）yarn.scheduler.minimum-allocation-mb 单任务最小内存
如果设置成2G，那50/2 = 25，就是最多可以跑25个container
如果设置成3G，那50/3 = 16，就是最多可以跑16个containeryarn.scheduler.minimum-allocation-mb 单任务最少vcore
如果设置vcore = 1，那么32/1 = 32，就是最多可以跑32个container，如果设置成这个，根据上面内存分配的情况，最多只能跑25个container，vcore有点浪费
如果设置vcore = 2，那么32/2 = 16，就是最多可以跑16个containeryarn.scheduler.maximum-allocation-vcores 单任务最多vcore
一般就设置成4个，cloudera公司做过性能测试，如果cpu大于等于5之后，cpu利用率反而不是很好（固定经验值）yarn.scheduler.maximum-allocation-mb 单任务最大内存
这个要根据自己公司业务设定，如果有大任务，需要5-6G内存，那就设置为8G

spark.yarn.executor.memoryOverhead源代码:

var executorMemory = 1024 // 默认值，1024MB
val MEMORY_OVERHEAD_FACTOR = 0.10  //Overhead的比例参数，默认0.1
val MEMORY_OVERHEAD_MIN = 384L/ Executor memory in MB.
protected val executorMemory = sparkConf.get(EXECUTOR_MEMORY).toInt
// Additional memory overhead.
protected val memoryOverhead: Int = sparkConf.get(EXECUTOR_MEMORY_OVERHEAD).getOrElse(math.max((MEMORY_OVERHEAD_FACTOR * executorMemory).toInt, MEMORY_OVERHEAD_MIN)).toIntval executorMem=args.executorMemory + executorMemoryOverhead假设executor为X(整数，单位为MB)，即：
1 如果没有设置spark.yarn.executor.memoryOverhead
executorMem=X+max(X*0.1,384)
2 如果设置了spark.yarn.executor.memoryOverhead(整数，单位是MB)
executorMem=X +spark.yarn.executor.memoryOverhead

Saprk底层shuffle传输方式是使用netty传输，netty在进行网络传输过程中会申请堆外内存(netty是零拷贝)，所以就是用了堆外内存。

Spark的Executor的Container内存有两大部分组成：堆外内存和Executor内存

堆外内存由参数spark.yarn.executor.memoryOverhead参数设置，主要用于JVM自身开销

Executor内存spark.executor.memory参数设置，分为两部分

Execution：shuffle、排序、聚合等用于计算的内存
Storage：用于集群中缓冲和传播内部数据的内存(cache、广播变量)

1.1 何时需要调整Executor的堆外内存大小

当出现如下异常时，

shuffle file cannot find（DAGScheduler，resubmitting task）
executor lost
task lost
out ofmemory

出现上述现象大致有这么两种情况：

1 MapTask所运行的executor内存不足，导致executor挂掉了，对应的Executor上面的block manager也挂掉了，导致ConnectionManager不能用，也就无法建立连接，从而不能拉取数据
2 Executor并没有挂掉，而且在拉取数据的过程中出现了问题
- 1 BlockManage之间的连接失败（map task所运行的executor正在GC）
- 2 建立连接成功，map task所运行的executor正在GC
3 reduce task向Driver中的MapOutputTracker获取shuffle file位置的时候出现了问题

1.1.2 解决方案

1.增大Executor内存(即堆内内存) ，申请的堆外内存也会随之增加–executor-memory 5G

2.增大堆外内存 spark.yarn.executor.memoryoverhead 2048M

默认申请的堆外内存是Executor内存的10%，真正处理大数据的时候，这里都会出现问题，导致spark作业反复崩溃，无法运行；此时就会去调节这个参数，到至少1G，甚至说2G、4G)

2 针对上述现象的解决方案如下

通过上面的报错描述上可以了解到，continer超过了内存的限制从而被kill掉，调整的建议

方案一：根据提示 yarn.nodemanager.vmem-check-enabled =false 关闭虚拟内存检查

方案二：根据提示 spark.yarn.executor.memoryOverhead

尝试提升spark.yarn.executor.memoryOverhead参数值至512MB，这种方式是通过牺牲内存资源来换取应用稳定性

真正的原因是：每个任务都是通过NIO channel 去获取shuffle文件。并且所需的缓冲区是从OS overheads中分配的，这也就导致了os overhead越来越大，因此我们也可以通过减少并行度来减少同时运行的任务来尝试避免这样的问题

方案三：降低参数–excutor-cores值

这种方式是牺牲了应用的性能和cpu的利用率来换取应用稳定性

Spark On Yarn 中Executor 内存分配的机制

Spark性能调优之Shuffle调优