Spark性能调优-调节executor堆外内存

调节executor堆外内存 spark底层shuffle的传输方式是使用netty传输，netty在进行网络传输的过程会申请堆外内存，所以使用了堆外内存！ 什么时候需要调节Executor的堆外内存大小？ 当出现一下异常时： shuffle file cannot find，executor lost、task lost，out of memory 出现这种问题的现象大致有这么两种情况： 1、Executor挂掉了，对应的Executor上面的block manager也挂掉了，找不到对应的shuffle map output文件，Reducer端不能够拉取数据 2、Executor并没有挂掉，而是在拉取数据的过程出现了问题。 上述情况下，就可以去考虑调节一下executor的堆外内存。也许就可以避免报错；此外，有时， 堆外内存调节的比较大的时候，对于性能来说，也会带来一定的提升。 这个executor跑着跑着，突然内存不足了，堆外内存不足了，可能会OOM，挂掉。block manager也没有了， 数据也丢失掉了。 如果此时，stage0的executor挂了，block manager也没有了；此时，stage1的executor的task，虽然通过 Driver的MapOutputTrakcer获取到了自己数据的地址；但是实际上去找对方的block manager获取数据的 时候，是获取不到的 此时，就会在spark-submit运行作业（jar），client（standalone client、yarn client）， 在本机就会打印出log shuffle output file not found。。。 DAGScheduler，resubmitting task，一直会挂掉。反复挂掉几次，反复报错几次 整个spark作业就崩溃了 --conf spark.yarn.executor.memoryOverhead=2048 spark-submit脚本里面，去用--conf的方式，去添加配置；一定要注意！！！切记， 不是在你的spark作业代码中，用new SparkConf().set()这种方式去设置，不要这样去设置，是没有用的！ 一定要在spark-submit脚本中去设置。 spark.yarn.executor.memoryOverhead（看名字，顾名思义，针对的是基于yarn的提交模式） 默认情况下，这个堆外内存上限默认是每一个executor的内存大小的10%；后来我们通常项目中，真正处理大数据的时候， 这里都会出现问题，导致spark作业反复崩溃，无法运行；此时就会去调节这个参数，到至少1G（1024M）， 甚至说2G、4G 通常这个参数调节上去以后，就会避免掉某些JVM OOM的异常问题，同时呢，会让整体spark作业的性能， 得到较大的提升。 调节等待时长！！！ executor，优先从自己本地关联的BlockManager中获取某份数据 如果本地block manager没有的话，那么会通过TransferService，去远程连接其他节点上executor 的block manager去获取 尝试建立远程的网络连接，并且去拉取数据 task创建的对象特别大，特别多 频繁的让JVM堆内存满溢，进行垃圾回收。 正好碰到那个exeuctor的JVM在垃圾回收 JVM调优：垃圾回收 处于垃圾回收过程中，所有的工作线程全部停止；相当于只要一旦进行垃圾回收， spark / executor停止工作，无法提供响应 此时呢，就会没有响应，无法建立网络连接；会卡住；ok，spark默认的网络连接的超时时长，是60s； 如果卡住60s都无法建立连接的话，那么就宣告失败了。 碰到一种情况，偶尔，偶尔，偶尔！！！没有规律！！！某某file。一串file id。 uuid（dsfsfd-2342vs--sdf--sdfsd）。not found。file lost。 这种情况下，很有可能是有那份数据的executor在jvm gc。所以拉取数据的时候，建立不了连接。 然后超过默认60s以后，直接宣告失败。 报错几次，几次都拉取不到数据的话，可能会导致spark作业的崩溃。也可能会导致DAGScheduler， 反复提交几次stage。TaskScheduler，反复提交几次task。大大延长我们的spark作业的运行时间。 可以考虑调节连接的超时时长。 --conf spark.core.connection.ack.wait.timeout=300 spark-submit脚本，切记，不是在new SparkConf().set()这种方式来设置的。 spark.core.connection.ack.wait.timeout（spark core，connection，连接，ack，wait timeout， 建立不上连接的时候，超时等待时长） 调节这个值比较大以后，通常来说，可以避免部分的偶尔出现的某某文件拉取失败，某某文件lost掉了。。。 为什么在这里讲这两个参数呢？ 因为比较实用，在真正处理大数据（不是几千万数据量、几百万数据量），几亿，几十亿，几百亿的时候。 很容易碰到executor堆外内存，以及gc引起的连接超时的问题。 file not found，executor lost，task lost。 调节上面两个参数，还是很有帮助的。