以spark 提交 任务为例:
yarn作为cluster manager时,spark(以client模式为例)用spark-submit提交应用程序(或者是spark-shell交互操作)不加任何资源参数时,会使用如下几个默认配置来向yarn的resourcemanager申请container资源:
spark.executor.memory 1g
spark.executor.cores 1
spark.executor.instances 2
spark.yarn.am.memory 512m
spark.yarn.am.cores 1
按照参数的默认值,yarn将会生成3个containers,第一个是container0,用来执行applicationmaster功能,另外两个container,就是分配给spark程序的CoarseGrainedExecutorBackend.
结合上面这些默认值,我们认为将会占用集群的3个vcores,3.5G memory。
看下图(yarn web ui),第一个问题来了,为什么memory使用的数量不是想象中的3.5g呢?
原来,yarn对于应用程序所要申请的内存资源,有两个参数来影响实际申请到内存容量:
第一个是yarn.scheduler.minimum-allocation-mb:最小可申请内存量,默认是1024。
第二个是规整化因子(FIFO和Capacity Scheduler时,规整化因子等于最小可申请资源量,不可单独配置;Fair Scheduler时,规整化因子通过参数yarn.scheduler.increment-allocation-mb设置,默认是1024),其作用是应用程序申请的资源如果不是该因子的整数倍,则将被修改为最小的整数倍对应的值。
由于每个容器都会占用一些额外的内存,所以导致CoarseGrainedExecutorBackend的每个容器实际使用的内存数 > 申请的1G,在规整化因子的作用下,这些容器实际申请的内存,就会是2G;而applicationmaster所在的容器,因为申请内存不到1G,则在最小可申请内存的作用下,实际申请的内存就会是1G。
这下申请的内存数就和图中的对上号了吧(5G)!
ok,继续往下说。
如果使用默认的2个executor,且每个executor只有1个vcore,毕竟执行任务的并发性太差。我们可以给每个executor多分配几个vcore来提高并发性。在提交应用程序时,增加 --executor-cores 4 配置。
那么,问题来了,为什么vcore的显示的不是我们配置的9呢(4+4+1)?依然是3,难道没有生效吗?
其实使用spark的driver ui观察,这里面的显示是准确的,说明我们想给每个executor使用4个core是生效了的。
可为什么yarn的web ui显示的不准确呢?
通过查资料发现,因为我们的capacity schedule使用的是DefaultResourceCalculator,那么DefaultResourceCalculator它在加载Container时其实仅仅只会考虑内存而不考虑cores。将capacity-scheduler.xml中的:
yarn.scheduler.capacity.resource-calculator
org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator
修改为:
yarn.scheduler.capacity.resource-calculator
org.apache.hadoop.yarn.util.resource.DominantResourceCalculator
(请注意每个节点的配置文件都需要修改,并且重启hadoop)
这时再提交spark应用程序,发现申请的vcores 的数目就对了吧(4+4+1)。