Spark JVM调优之调节executor堆外内存与连接等待时长

executor堆外内存的调优

有时候，如果你的spark作业处理的数据量特别特别大，大约在几亿的数据量，然后spark作业运行，时不时报错，

shuffle file cannot find , execturo、task lost。out of memeory可能是看到lost这种字样;

可能是说，你的executor的堆外内存不太够用，导致executor在运行过程中，可能会内存溢出；然后可能导致后续的stage的task在运行的时候，可能要从一些executor中去拉取shuffle map output文件，但是executor可能已经挂掉了，关联的block manager也没有了，所以可能会报shuffle output file not found；resubmitting task； executor lost; spark作业彻底奔溃

 

上述情况下，就可以考虑调节一下executor的堆外内存。也许就可以避免报错，此外，有时，堆外内存调节比较大的时候，对于性能来说，也会带来一定的提升。

 

在spark-submit的脚本中，去添加配置，一定要注意，不是在你的spark作业代码中，用new SparkConf().set()这种方式去设置，是没有用的！一定要在spark-submit脚本中去设置。

spark.yarn.executor.memoryOverhead(这个是针对yarn的提交模式)

默认情况下，这个堆外内存上限大概是300多M,后来我们通常项目中，真正处理大数据的时候，这里都会出现问题，导致spark作业反复崩溃，无法运行，此时就会去调节这个参数到2G，至少1G(1024M)，甚至说4G

通常这个参数调节上去以后，就会避免掉某些JVM OOM的异常问题，同时，会让整体spark作业的性能得到较大的提升。

 

当一个executor需要用到另一个executor数据时候，那么这个executor就会向另一个executor发起网络连接来拉取数据，但是，当另一个executor正好在gc，那么此时就会没有响应，无法建立网络连接，会卡住，spark默认的网络连接的超时时长，是60s,如果卡住60s都无法建立连接的话，那么就宣告失败了。

 

碰到一种情况，某某file. 一串file id.uuid(dsfdfs-32434vd--dsfa-fsegd)。not found,file lost。

这种情况下，很有可能是那份数据的executor在jvm jc.所以拉取数据的时候，建立不了连接，然后超过默认60s以后，直接宣告失败。

报错几次，几次都拉取不到数据的话，可能会导致spark作业的崩溃，也可能会导致DAGScheduler，反复提交几次stage,TaskScheduler，反复提交几次task。大大延长spark作业的运行时间

这时可以考虑连接的超时时长

--conf spark.core.connection.ack.wait.timeout=300

建立不上连接的时候，超时等待时长

调节这个值比较大以后，通常来说，可以避免部分的偶尔出现某某文件拉取失败，某某文件lost掉 

spark-submit脚本，切记，不是在new SparkConf().set来设置

 

这个是在大量数据的时候会出现这种问题

不是几千万，几百万数据量情况下，可能是几亿，几十亿的时候，很容易碰到executor堆外内存，以及gc引起的连接超时的问题

 

调节上面的俩个参数是很有帮组的