本文基于Spark2.1.0版本
我們知道，使用yarn作為cluster manager時胶背，spark（以client模式為例）用spark-submit提交應用程序（或者是spark-shell交互操作）不加任何資源參數(shù)時巷嚣，會使用如下幾個默認配置來向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
按照參數(shù)的默認值，yarn將會生成3個containers钳吟，第一個是container0廷粒，用來執(zhí)行applicationmaster功能，另外兩個container红且，就是分配給spark程序的CoarseGrainedExecutorBackend.
結合上面這些默認值坝茎，我們認為將會占用集群的3個vcores，3.5G memory暇番。
看下圖(yarn web ui)嗤放，第一個問題來了，為什么memory使用的數(shù)量不是想象中的3.5g呢奔誓？
原來斤吐，yarn對于應用程序所要申請的內(nèi)存資源，有兩個參數(shù)來影響實際申請到內(nèi)存容量：
第一個是yarn.scheduler.minimum-allocation-mb：最小可申請內(nèi)存量厨喂，默認是1024和措。
第二個是規(guī)整化因子（FIFO和Capacity Scheduler時，規(guī)整化因子等于最小可申請資源量蜕煌，不可單獨配置派阱；Fair Scheduler時，規(guī)整化因子通過參數(shù)yarn.scheduler.increment-allocation-mb設置斜纪，默認是1024）贫母，其作用是應用程序申請的資源如果不是該因子的整數(shù)倍，則將被修改為最小的整數(shù)倍對應的值盒刚。
由于每個容器都會占用一些額外的內(nèi)存腺劣，所以導致CoarseGrainedExecutorBackend的每個容器實際使用的內(nèi)存數(shù) > 申請的1G，在規(guī)整化因子的作用下因块，這些容器實際申請的內(nèi)存橘原，就會是2G；而applicationmaster所在的容器涡上，因為申請內(nèi)存不到1G趾断，則在最小可申請內(nèi)存的作用下，實際申請的內(nèi)存就會是1G吩愧。
這下申請的內(nèi)存數(shù)就和圖中的對上號了吧（5G）芋酌！
ok，繼續(xù)往下說雁佳。
如果使用默認的2個executor脐帝，且每個executor只有1個vcore同云，畢竟執(zhí)行任務的并發(fā)性太差。我們可以給每個executor多分配幾個vcore來提高并發(fā)性腮恩。在提交應用程序時梢杭，增加 --executor-cores 4 配置温兼。
那么秸滴，問題來了，為什么vcore的顯示的不是我們配置的9呢（4+4+1）募判？依然是3荡含，難道沒有生效嗎？
其實使用spark的driver ui觀察届垫，這里面的顯示是準確的释液，說明我們想給每個executor使用4個core是生效了的。
可為什么yarn的web ui顯示的不準確呢装处？
通過查資料發(fā)現(xiàn)误债，因為我們的capacity schedule使用的是DefaultResourceCalculator，那么DefaultResourceCalculator它在加載Container時其實僅僅只會考慮內(nèi)存而不考慮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
（請注意每個節(jié)點的配置文件都需要修改寝蹈，并且重啟hadoop）
這時再提交spark應用程序，發(fā)現(xiàn)申請的vcores 的數(shù)目就對了吧（4+4+1）登淘。
歡迎指正箫老，轉載請標明作者和出處，謝謝黔州。
