以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）。