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。


调节上面两个参数，还是很有帮助的。