还要考虑Spark请求的资源如何适应YARN可用的资源。相关的YARN属性是:
yarn.nodemanager.resource.memory-mb控制每个主机上container使用的最大内存总和。
yarn.nodemanager.resource.cpu-vcores控制每个主机上container使用的最大内核总数。
申请五个executor核心意思就是向YARN请求五个核心。 YARN请求的内存更复杂,原因有两个:
--executor-memory / spark.executor.memory属性控制executor堆大小,但executor也可能使用堆外内存,例如Java NIO直接缓冲区。 spark.yarn.executor.memoryOverhead属性值将添加到executor内存中,以确定每个executor对YARN的完整内存请求。默认为max(384,.07 * spark.executor.memory)。
YARN请求的内存会稍微向上舍入。 yarn.scheduler.minimum-allocation-mb和yarn.scheduler.increment-allocation-mb属性分别控制最小和增量请求值。
下图(不按默认值缩放)显示Spark和YARN中内存属性的层次结构:
[img]https://ss.csdn.net/p?https://mmbiz.qpic.cn/mmbiz_png/ ... zUFQ/640?wx_fmt=png[/img]
调整Spark executor的内存大小时,请记住以下几点:
ApplicationMaster是一个可以从yarn上申请container,但自身不会运行executor,它需要占用内存和CPU。在客户端部署模式下,它们默认为1024 MB和一个核心。在集群部署模式下,ApplicationMaster运行驱动程序,因此可考虑使用--driver-memory和--driver-cores配置其资源。
运行具有太多内存的executor通常会导致过多的垃圾收集延迟。对于单个执行程序,请使用64 GB作为上限。
HDFS客户端难以处理许多并发线程。每个executor最多有五个任务可以实现完全写入吞吐量,因此请将每个执行程序的核心数保持在该数量之下。
运行微型executor(例如,使用单个核心和运行单个任务所需的足够内存)会抵消在单个JVM中运行多个任务的好处。例如,广播变量必须在每个执行程序上复制一次,因此许多小执行程序会导致更多的数据副本。
可以考虑使用--num-executors 6 --executor-cores 15 --executor-memory 63G。但是,这种方法不行的:
63 GB加上executor内存开销超出了NodeManagers的63 GB容量。
ApplicationMaster在其中一个主机上占用一个核心,因此该主机上没有15核执行器的空间。
每个执行程序15个核心可能导致较差的HDFS I / O吞吐量。
相反,使用--num-executors 17 --executor-cores 5 --executor-memory 19G:
这导致所有主机上有三个executor,除了具有两个执行程序的ApplicationMaster。
--executor-memory计算为(63/3 executor /每台主机):
21 * 0.07 = 1.47GB。 21 - 1.47~19GB。
其实,资源配置调优全靠经验和自己对集群,分布式,数据量,业务及自己代码的理解,然后多加测试,这样形成自己的经验认知。
希望对大家有帮助。
欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/) | 黑马程序员IT技术论坛 X3.2 |