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)

相关推荐

  • 大数据Spark Sql中日期转换FROM_UNIXTIME和UNIX_TIMESTAMP的使用

    目录 UNIX_TIMESTAMP FROM_UNIXTIME 众所周知,数字整型用来大小比较和计算运算要比字符型快的多,因此部分业务需要把时间字段转化为整型方便业务的快速计算和到达,这个整形数字是选定的日期距UTC 时间 '1970-01-01 00:00:00' 开始的秒数,目前为十位,比如常用来举例的1234567890,但毕竟数字不方便观察,后续还需要把这些时间数字转换为真正的时间字段 这里就需要两个函数来进行转换UNIX_TIMESTAMP和FROM_UNIXTIME 咱们一一介绍 U

  • 从0开始学习大数据之java spark编程入门与项目实践

    本文实例讲述了大数据java spark编程.分享给大家供大家参考,具体如下: 上节搭建好了eclipse spark编程环境 在测试运行scala 或java 编写spark程序 ,在eclipse平台都可以运行,但打包导出jar,提交 spark-submit运行,都不能执行,最后确定是版本问题,就是你在eclipse调试的spark版本需和spark-submit 提交spark的运行版本一致,还有就是scala版本一致,才能正常运行. 以下是java spark程序运行 1.新建mave

  • 一文学会Hadoop与Spark等大数据框架知识

    目录 一个实际的需求场景:日志分析 Hadoop Hadoop的生态坏境 Spark Spark整体架构 Spark核心概念 Spark的核心组件 海量数据的存储问题很早就已经出现了,一些行业或者部门因为历史的积累,数据量也达到了一定的级别.很早以前,当一台电脑无法存储这么庞大的数据时,采用的解决方案是使用NFS(网络文件系统)将数据分开存储.但是这种方法无法充分利用多台计算机同时进行分析数据. 一个实际的需求场景:日志分析 日志分析是对日志中的每一个用户的流量进行汇总求和.对于一个日志文件,如

  • easyui datagrid 大数据加载效率慢,优化解决方法(推荐)

    在使用easyui datagrid途中发现加载数据的效率真的不是一般的差.经测试IE8加载300条数据就感觉明显的慢了,加载2000条数据就另人崩溃用时差不多60秒,就算在google浏览器测试结果也快不了几秒. 平时听闻easyui datagrid效率底下,自己测试才发现真是使人无法忍受. 笔者只好百度,google解决方法,发现一篇文章说改 //1.3.3版本是这样的,其它版本也是这句代码 $(_1e0).html(_1e4.join("")); 改为: $(_1e0)[0].

  • 大数据量高并发的数据库优化详解

    如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 一.数据库结构的设计 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

  • java 较大数据量取差集,list.removeAll性能优化详解

    今天在优化项目中的考勤同步功能时遇到将考勤机中的数据同步到数据库, 两边都是几万条数据的样子,老代码的做法差不多半个小时,优化后我本机差不多40秒,服务器速度会更加理想. 两个数据集取差集首先想到的方法便是List.removeAll方法,但是实验发现jdk自带的List.removeAll效率很低 List.removeAll效率低原因: List.removeAll效率低和list集合本身的特点有关 : List底层数据结构是数组,查询快,增删慢 1.List.contains()效率没有h

  • 一次Mysql使用IN大数据量的优化记录

    mysql版本号是5.7.28,表A有390W条记录,使用InnoDB引擎,其中varchar类型字段mac已建立索引,索引方法为B-tree.B表仅有5000+条记录. 有一条SQL指令是这样写的: SELECT * FROM A WHERE mac IN("aa:aa:aa:aa:aa:aa","bb:bb:bb:bb:bb:b",...此外省略900+条) 通过查询出来的结果耗时294.428s.没错,将近5分钟. 使用EXPLAIN分析下: 访问类型type

  • MySQL 大数据量快速插入方法和语句优化分享

    锁定也将降低多连接测试的整体时间,尽管因为它们等候锁定最大等待时间将上升.例如: 复制代码 代码如下: Connection 1 does 1000 inserts Connections 2, 3, and 4 do 1 insert Connection 5 does 1000 inserts 如果不使用锁定,2.3和4将在1和5前完成.如果使用锁定,2.3和4将可能不在1或5前完成,但是整体时间应该快大约40%. INSERT.UPDATE和DELETE操作在MySQL中是很快的,通过为在

  • Java开发者必备10大数据工具和框架

    当今IT开发人员面对的最大挑战就是复杂性,硬件越来越复杂,OS越来越复杂,编程语言和API越来越复杂,我们构建的应用也越来越复杂.根据外媒的一项调查报告,中软卓越专家列出了Java程序员在过去12个月内一直使用的一些工具或框架,或许会对你有意义. 先来看看大数据的概念.根据维基百科,大数据是庞大或复杂的数据集的广义术语,因此传统的数据处理程序不足以支持如此庞大的体量. 在许多情况下,使用SQL数据库存储/检索数据都是很好的选择.而现如今的很多情况下,它都不再能满足我们的目的,这一切都取决于用例的

  • python使用pandas处理大数据节省内存技巧(推荐)

    一般来说,用pandas处理小于100兆的数据,性能不是问题.当用pandas来处理100兆至几个G的数据时,将会比较耗时,同时会导致程序因内存不足而运行失败. 当然,像Spark这类的工具能够胜任处理100G至几个T的大数据集,但要想充分发挥这些工具的优势,通常需要比较贵的硬件设备.而且,这些工具不像pandas那样具有丰富的进行高质量数据清洗.探索和分析的特性.对于中等规模的数据,我们的愿望是尽量让pandas继续发挥其优势,而不是换用其他工具. 本文我们讨论pandas的内存使用,展示怎样

随机推荐

其他