spark调优篇-spark on Yarn 内存管理总结 Removing executor 5 with no recent heartbeats: 120504 ms exceeds timeout 120000 ms

本文旨在解析 spark on Yarn 的内存管理，使得 spark 调优思路更加清晰

内存相关参数

spark 是基于内存的计算，spark 调优大部分是针对内存的，了解 spark 内存参数有也助于我们理解 spark 内存管理

spark.driver.memory：默认 512M
spark.executor.memory：默认 512M
spark.yarn.am.memory：默认 512M
spark.yarn.driver.memoryOverhead：driver memory * 0.10, with minimum of 384
spark.yarn.executor.memoryOverhead：executor memory * 0.10, with minimum of 384
spark.yarn.am.memoryOverhead：am memory * 0.10, with minimum of 384
executor-cores：executor 相当于一个进程，cores 相当于该进程里的线程

内存解析

spark.xxx.memory / --xxx-memory 是 JVM 堆区域，但是 JVM 本身也会占用一定的堆空间，这部分由 spark.yarn.xxx.memoryOverhead 确定，二者关系如下图

内存分配

为了更好的利用 spark 内存，通常我们需要在 Yarn 集群中设置如下参数　　【非必须】

<property>
      <name>yarn.nodemanager.resource.memory-mb</name>
      <value>106496</value> <!-- 104G -->
  </property>
  <property>
      <name>yarn.scheduler.minimum-allocation-mb</name>
      <value>2048</value>
  </property>
  <property>
      <name>yarn.scheduler.maximum-allocation-mb</name>
      <value>106496</value>
  </property>
  <property>
      <name>yarn.app.mapreduce.am.resource.mb</name>
      <value>2048</value>
  </property>

yarn.app.mapreduce.am.resource.mb：am 能申请的最大内存
yarn.nodemanager.resource.memory-mb：nodemanager 能申请的最大内存
yarn.scheduler.minimum-allocation-mb：任务调度时一个 container 可申请的最小内存
yarn.scheduler.maximum-allocation-mb：任务调度时一个 container 可申请的最大内存

yarn.scheduler.minimum-allocation-mb 是 Container 的内存基本单位，也就是说 Container 的内存必须是 yarn.scheduler.minimum-allocation-mb 的整数倍，

比如 yarn.scheduler.minimum-allocation-mb 设置为 2G，2048M，

如果内存申请为 512M，512+384<2048M，会被分配 2G 内存，

如果内存申请为 3G，3072+384=3456M<4096M，会被分配 4G 内存，

如果申请内存为 6G，6144+614=6758<8192M，会被分配 8G 内存，　　　　　　　　　　【max(6144*0.1， 384)=614】

所以当设定 --executor-memory 为 3G 时，Container 实际内存并非 3G

常见问题

常见的问题无非就是内存不足或者 container 被杀死

Removing executor 5 with no recent heartbeats: 120504 ms exceeds timeout 120000 ms
Container killed by YARN for exceeding memory limits
Consider boosting spark.yarn.executor.memoryOverhead
spark-OutOfMemory:GC overhead limit exceeded

常规思路

1. 第一解决办法就是增加总内存　　　　【此法不能解决所有问题】

2. 其次考虑数据倾斜问题，因为数据倾斜导致某个 task 内存不足，其它 task 内存足够

　　// 最简单的方法是 repartition　　　　【此法不能解决所有问题】

3. 考虑增加每个 task 的可用内存

　　// 减少 Executor 数

　　// 减少 executor-cores 数

参数设置注意事项

executor-memory

设置过大，会导致 GC 过程很长，64G 是推荐的内存上限　　【根据硬件不同，可寻找合适的上限】

executor-cores

1. 设置过大，并行度会很高，容易导致网络带宽占满，特别是从 HDFS 读取数据，或者是 collect 数据回传 Driver

2. 设置过大，使得多个 core 之间争夺 GC 时间已经资源，导致大部分时间花在 GC 上

参考资料：

https://www.cnblogs.com/saratearing/p/5813403.html#top

https://blog.csdn.net/pearl8899/article/details/80368018

https://www.so.com/s?q=with+minimum+of+384&src=se_zoned

https://blog.cloudera.com/how-to-tune-your-apache-spark-jobs-part-2/　　英文博客