当前位置: 代码网 > it编程>编程语言>其他编程 > spark大数据任务提交参数的优化记录分析

spark大数据任务提交参数的优化记录分析

2024年05月19日 其他编程 我要评论
起因新接触一个spark集群,明明集群资源(core,内存)还有剩余,但是提交的任务却申请不到资源。分析环境spark 2.2.0 基于yarn集群参数spark任务提交参数中最重要的几个:spark

起因

新接触一个spark集群,明明集群资源(core,内存)还有剩余,但是提交的任务却申请不到资源。

分析

环境

spark 2.2.0 基于yarn集群

参数

spark任务提交参数中最重要的几个:

spark-submit --master yarn --driver-cores 1 --driver-memory 5g --executor-cores 2 --num-executors 16 --executor-memory 4g

driver-cores driver端核数 driver-memory driver端内存大小 executor-cores 每个执行器的核数 num-executors 此任务申请的执行器总数 executor-memory 每个执行器的内存大小

那么,该任务将申请多少资源呢?

申请的执行器总内存数大小=num-executor * (executor-memory +spark.yarn.executor.memoryoverhead) = 16 * (4 + 2) = 96 申请的总内存=执行器总内存+dirver端内存=101 申请的总核数=num-executor*executor-core + yarn.am(默认为1)=33 运行的总容器(contanier) = num-executor + yarn.am(默认为1) = 17

所以这里还有一个关键的参数 spark.yarn.executor.memoryoverhead

这个参数是什么意思呢? 堆外内存,每个executor归spark 计算的内存为executor-memory,每个executor是一个单独的jvm,这个java虚拟机本向在的内存大小即为spark.yarn.executor.memoryoverhead,不归spark本身管理。在spark集群中配置。

也可在代码中指定 spark.set("spark.yarn.executor.memoryoverhead", 1)

这部份实际上是存放spark代码本身的究竟,在executor-memory内存不足的时候也能应应急顶上。

问题所在

假设一个节点16g的内存,每个executor-memory=4,理想情况下4x4=16,那么该节点可以分配出4个节点供spark任务计算所用。 1.但应考虑到spark.yarn.executor.memoryoverhead. 如果spark.yarn.executor.memoryoverhead=2,那么每个executor所需申请的资源为4+2=6g,那么该节点只能分配2个节点,剩余16-6x2=4g的内存,无法使用。

如果一个集群共100个节点,用户将在yarn集群主界面看到,集群内存剩余400g,但一直无法申请到资源。

2.core也是一样的道理。

很多同学容易忽略spark.yarn.executor.memoryoverhead此参数,然后陷入怀疑,怎么申请的资源对不上,也容易陷入优化的误区。

优化结果

最终优化结果,将spark.yarn.executor.memoryoverhead调小,并根据node节点资源合理优化executor-memory,executor-core大小,将之前经常1.6t的内存占比,降到1.1左右。并能较快申请到资源。

以上就是spark任务提交参数的优化记录分析的详细内容,更多关于spark任务提交参数优化的资料请关注代码网其它相关文章!

(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2025  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com