起因
新接觸一個spark集羣，明明集羣資源（core,內存）還有剩餘，但是提交的任務卻申請不到資源。
分析
環境
spark 2.2.0
基於yarn集羣
參數
spark任務提交參數中最重要的幾個：
spark-submit --master yarn --driver-cores 1 --driver-memory 5G --executor-cores 2 --num-executors 16 --executor-memory 4G
driver-cores driver端核數
driver-memory driver端內存大小
executor-cores 每個執行器的核數
num-executors 此任務申請的執行器總數
executor-memory 每個執行器的內存大小
那麼，該任務將申請多少資源呢？
申請的執行器總內存數大小=num-executor * (executor-memory +spark.yarn.executor.memoryOverhead) = 16 * (4 + 2) = 96
申請的總內存=執行器總內存+dirver端內存=101
申請的總核數=num-executor*executor-core + yarn.AM(默認爲1)=33
運行的總容器(contanier) = num-executor + yarn.AM(默認爲1) = 17
所以這裏還有一個關鍵的參數 spark.yarn.executor.memoryOverhead
這個參數是什麼意思呢？
堆外內存，每個executor歸spark 計算的內存爲executor-memory，每個executor是一個單獨的JVM，這個JAVA虛擬機本向在的內存大小即爲spark.yarn.executor.memoryOverhead，不歸spark本身管理。在spark集羣中配置。也可在代碼中指定
spark.set("spark.yarn.executor.memoryOverhead", 1)
這部份實際上是存放spark代碼本身的究竟，在executor-memory內存不足的時候也能應應急頂上。
問題所在
假設一個節點16G的內存，每個executor-memory=4，理想情況下4x4=16，那麼該節點可以分配出4個節點供spark任務計算所用。
1.但應考慮到spark.yarn.executor.memoryOverhead.
如果spark.yarn.executor.memoryOverhead=2，那麼每個executor所需申請的資源爲4+2=6G，那麼該節點只能分配2個節點，剩餘16-6x2=4G的內存，無法使用。
如果一個集羣共100個節點，用戶將在yarn集羣主界面看到，集羣內存剩餘400G,但一直無法申請到資源。
2.core也是一樣的道理。
很多同學容易忽略spark.yarn.executor.memoryOverhead此參數，然後陷入懷疑，怎麼申請的資源對不上，也容易陷入優化的誤區。
優化結果
最終優化結果，將spark.yarn.executor.memoryOverhead調小，並根據node節點資源合理優化executor-memory,executor-core大小，將之前經常1.6T的內存佔比，降到1.1左右。並能較快申請到資源。