频道栏目
首页 > 网络 > 云计算 > 正文
JVM调优executor堆外内存和连接时长
2016-12-15 09:24:00         来源:coderlaw's study  
收藏   我要投稿
一、executor堆外内存是什么? 有时候,如果你的spark作业处理的数据量特别特别大,几亿数据量;然后spark作业一运行, 时不时的报错, shuffle file cannot find, executor、 task lost, out of memory(内存溢出); 可能是说executor的堆外内存不太够用,导致executor在运行的过程中,可能会内存溢出;
/usr/local/spark/bin/spark-submit \
--class com.hulb.sparkstudy.WordCount \
--num-executors 80 \
--driver-memory 6g \
--executor-memory 6g \ (80*6 = 480G 内存)
--executor-cores 3 \ (80*3 = 240 个core)
--master yarn-cluster \
--queue root.default \
--conf spark.yarn.executor.memoryOverhead=2048 \
--conf spark.core.connection.ack.wait.timeout=300 \
/usr/local/spark/spark.jar \
${1} ( task id)

↑↑实际生产环境提交作业的一个例子↑↑

二、问题的情景

然后可能导致后续的stage的task在运行的时候,可能要从一些executor中去拉取shuffle map output文件,但是executor可能已经挂掉了,关联的block manager也没有了;

所以可能会报
shuffle output file not found;
resubmitting task;
executor lost;spark作业彻底崩溃。

三、怎么解决?

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

如果此时,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的提交模式)

默认情况下,这个堆外内存上限大概是300多M;
后来我们通常项目中,真正处理大数据的时候,这里都会出现问题,导致spark作业反复崩溃,无法运行;

此时就会去调节这个参数,到至少1G(1024M),甚至说2G、4G

通常这个参数调节上去以后,就会避免掉某些JVM OOM的异常问题,

同时呢,会让整体spark作业的性能,得到较大的提升。

五、什么是连接时长?

正好碰到对方在GC ,导致没能响应,无法建立网络连接!!(默认60s)

此时呢,就会没有响应,无法建立网络连接;会卡住;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。
调节上面两个参数,还是很有帮助的。

点击复制链接 与好友分享!回本站首页
上一篇:dockerservice系统介绍
下一篇:负载均衡器部署方式和工作原理
相关文章
图文推荐
文章
推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站