Spark on Yarn Executor Cores、Num
Spark on Yarn Executor Cores、Nums、Memory优化配置
设置以上三个参数,除了计算集群的节点数、节点Cores和内存大小外,还需要考虑以下四点因素:
Hadoop/Yarn/OS Deamons:
spark使用yarn做资源管理,yarn后台使用一些守护进程中运行的,如NameNode,Secondary NameNode,DataNode,JobTracker和TaskTracker,因此在设置num-executors,需为每个节点预留1个core来保证这些守护进程平稳地运行。
Yarn ApplicationMaster(AM):
AM负责从ResourceManager申请资源,与NodeManager进行通信启动/停止任务,监控资源的使用。在Yarn上执行Spark也要考虑AM所需资源(1G和1个Executor)。
HDFS Throughput:
HDFS Client有多个并发线程写的问题,HDFS每个Executor的使用5个任务就可获取完全并发写。因此最好每个Executor的cores不高于5.
MemoryOverhead:
下面图片展示 spark-yarn-memory-usage
每个executor需要内存=spark-executor-memory+spark.yarm.executor.memoryOverhead
spark.yarm.executor.memoryOverhead=Max(384m,7%*spark.executor.memory)即大于等于384M
如果我们为每个executor申请20GB资源,实际上AM获取的资源20GB+7%*20GB=~23GB。
集群环境配置如下:
节点数:10个
每个节点Cores:16
每个节点RAM:64GB
方案1: 每个Executor分配一个Core
--num-executors= 16 x 10 = 160
--executor-cores= 1
--executor-memory = 64GB/16 = 4GB
方案分析:
一个Executor分配1个Core的情况,不能发挥相同JVM内运行多个tasks任务的优势。还有broadcast变量和accumulators会被复制到每个节点的每个core有16次(广播变量和累加器在不指定分区的情况下,会占用所有可用的core,core对应task,task对应partition)。这样也没有充足的资源为Yarn daemon processes和AM。
方案2: 每个Executor分配一个节点
--num-executors = 10
--executor-cores = 16
--executor-memory = 64GB/1 = 64GB
方案分析:
一个Executor分配16个Cores的情况,虽然没有AM和Yarn daemon资源分配问题,但是HFDS throughput将会受到不好的影响。并且会导致过重的GC问题。
方案3: 上述两种方案的折中
考虑到上述四点因素:
每个executors设5 cores,即—executor-cores = 5(HFDS throughput有更好的并发效果)
每个节点为Yarn daemons保留一个core,即每个节点可用cores为16-1=15个。
所以,集群当中可用的cores总数为10*15=150
executors数量=150/5=30
为AM保留一个executor,—num-executors=29
每个节点的executor数=30/10=3
每个节点的每个executor分配的内存=64G/3=21GB
去除heap overhead=7%*21GB=3GB
所以,—executor-memory=21-3=18GB
故,推荐参数配置:
—num-executors=29
—executor-core=5
—executor-memory=18GB
方案分析:
即能获得executors并行度又能实现最好的吞吐量。
总结:
--num-executors, --executor-cores and —executor-memory这些参数在spark运行过程中起到非常极其重要的作用,其影响到spark程序获得CPU和内存的使用。
参考:http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2/