spark大數據任務提交參數的優化記錄分析

Posted on by

起因

新接觸一個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-6×2=4G的內存，無法使用。

如果一個集群共100個節點，用戶將在yarn集群主界面看到，集群內存剩餘400G,但一直無法申請到資源。

2.core也是一樣的道理。

很多同學容易忽略spark.yarn.executor.memoryOverhead此參數，然後陷入懷疑，怎麼申請的資源對不上，也容易陷入優化的誤區。

優化結果

最終優化結果，將spark.yarn.executor.memoryOverhead調小，並根據node節點資源合理優化executor-memory,executor-core大小，將之前經常1.6T的內存占比，降到1.1左右。並能較快申請到資源。

以上就是spark任務提交參數的優化記錄分析的詳細內容，更多關於spark任務提交參數優化的資料請關註WalkonNet其它相關文章！

推薦閱讀：