因为OOM导致的Lost executor On Yarn

遇到的问题

最近在测大数据程序在不同资源情况下的运行的性能情况，但是在测一些BenchMark的时候总会出现下列的问题：

Container killed by YARN for exceeding memory limits

紧接着在下面就会出现出现

ERROR cluster.YarnClientClusterScheduler: Lost executor

这是因为executor因为内存溢出被kill了，在接下来的执行过程中就会出现找不到对应的executor的问题，接下来就进入了不断的反复提交过程……对这个问题查找了一些资料，整理下备忘。如果理解有问题还请指正。

Yarn 内存

首先对yarn的内存管理整理一下，在yarn中，一个Executor对应着一个JVM的进程，一个Executor会使用到的内存分为两个部分，分别是ExecutorMemory（通过–executor-memory设置），以及MemoryOverHead。其中executormemory中又分为用于存储的memory-store以及用来执行运算，shuffle的memory-execution。spark.shuffle.memoryFraction是用来调节memory-executionz占用总的executormemory内存的比例。在1.60版本之后两者没有明确的界线，占满的一方可以借用空闲一方的内存来使用，但是并不意味shuffle.memoryFraction参数没有意义，因为借用归还也是需要开销。

那么MemoryOverhead有什么作用？Memoryoverhead中放了方法区，java虚拟机栈，本地方法栈，jvm进程本身所要使用的内存，以及直接内存。其大小是：

math.max((MEMORY_OVERHEAD_FACTOR*executorMemory).toInt,MEMORY_OVERHEAD_MIN）

当jvm的总内存超过了container的容量（executormemory+memoryoverhead），那么就会被kill掉。

问题解决

主要是参考了[3][5] 两篇博客，解决途径主要尝试下面几个方法：

1. 增加分配的堆内内存的大小
2. 增加你所划分的堆外内存的大小
3. 降低你所划分的核的数量（核的数量下降，意味着同一时刻在运行的task的数量减少，内存的压力减小）
4. 将垃圾回收的频率提高，让内存能更快的释放，相应的性能会有损失
5. 为了避免是由于数据分布不均衡导致个别节点的数据量超出限制，可以使用repartition来重新分区
6. 为了避免在shuffle中但个文件过大而导致OOM问题，可以适当的增加分区的数目
7. 由于python使用堆外内存，所以如果使用的是python，可以尝试降低executor-memory的值，并加大堆外内存的大小[4]

可能会有不对的地方，欢迎指正。

参考文献

[1]http://blog.csdn.net/yhb315279058/article/details/51035631
[2]https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-apache-spark-memory-management/index.html
[3]https://gsamaras.wordpress.com/code/memoryoverhead-issue-in-spark/
[4]http://blog.csdn.net/hammertank/article/details/48346285
[5]http://www.codexiu.cn/spark/blog/7231/