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

起因

新接觸一個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其它相關文章!

推薦閱讀: