Spark性能優化 (4) | JVM 調優

  本片博文為大家帶來的是JVM 調優。

目錄

• 1. 降低cache操作的記憶體占比
• 2. 調節Executor堆外記憶體
• 3. 調節連接配接等待時長

對于 JVM 調優，首先應該明确，full gc/minor gc，都會導緻JVM的工作線程停止工作，即stop the world。

• 靜态記憶體管理機制

根據 Spark 靜态記憶體管理機制，堆記憶體被劃分為了兩塊，Storage 和 Execution。

Storage 主要用于緩存 RDD資料和 broadcast 資料，Execution主要用于緩存在shuffle過程中産生的中間資料，Storage占系統記憶體的60%，Execution占系統記憶體的20%，并且兩者完全獨立。 在一般情況下，Storage的記憶體都提供給了cache操作，但是如果在某些情況下cache操作記憶體不是很緊張，而task的算子中建立的對象很多，Execution記憶體又相對較小，這回導緻頻繁的minor gc，甚至于頻繁的full gc，進而導緻Spark頻繁的停止工作，性能影響會很大。 在Spark UI中可以檢視每個stage的運作情況，包括每個task的運作時間、gc時間等等，如果發現gc太頻繁，時間太長，就可以考慮調節Storage的記憶體占比，讓task執行算子函數式，有更多的記憶體可以使用。 Storage記憶體區域可以通過spark.storage.memoryFraction參數進行指定，預設為0.6，即60%，可以逐級向下遞減，

val conf = new SparkConf()
  .set("spark.storage.memoryFraction", "0.4")

           

• 統一記憶體管理機制

根據Spark統一記憶體管理機制，堆記憶體被劃分為了兩塊，Storage 和 Execution。Storage 主要用于緩存資料，Execution 主要用于緩存在 shuffle 過程中産生的中間資料，兩者所組成的記憶體部分稱為統一記憶體，Storage和Execution各占統一記憶體的50%，由于動态占用機制的實作，shuffle 過程需要的記憶體過大時，會自動占用Storage 的記憶體區域，是以無需手動進行調節。

Executor 的堆外記憶體主要用于程式的共享庫、Perm Space、 線程Stack和一些Memory mapping等, 或者類C方式allocate object。

有時，如果你的Spark作業處理的資料量非常大，達到幾億的資料量，此時運作 Spark 作業會時不時地報錯，例如shuffle output file cannot find，executor lost，task lost，out of memory等，這可能是Executor的堆外記憶體不太夠用，導緻 Executor 在運作的過程中記憶體溢出。

stage 的 task 在運作的時候，可能要從一些 Executor 中去拉取 shuffle map output 檔案，但是 Executor 可能已經由于記憶體溢出挂掉了，其關聯的 BlockManager 也沒有了，這就可能會報出 shuffle output file cannot find，executor lost，task lost，out of memory等錯誤，此時，就可以考慮調節一下Executor的堆外記憶體，也就可以避免報錯，與此同時，堆外記憶體調節的比較大的時候，對于性能來講，也會帶來一定的提升。

預設情況下，Executor 堆外記憶體上限大概為300多MB，在實際的生産環境下，對海量資料進行處理的時候，這裡都會出現問題，導緻Spark作業反複崩潰，無法運作，此時就會去調節這個參數，到至少1G，甚至于2G、4G。

Executor堆外記憶體的配置需要在spark-submit腳本裡配置，

--conf spark.executor.memoryOverhead=2048
           

以上參數配置完成後，會避免掉某些JVM OOM的異常問題，同時，可以提升整體 Spark 作業的性能。

在 Spark 作業運作過程中，Executor 優先從自己本地關聯的 BlockManager 中擷取某份資料，如果本地BlockManager沒有的話，會通過TransferService遠端連接配接其他節點上Executor的BlockManager來擷取資料。

如果 task 在運作過程中建立大量對象或者建立的對象較大，會占用大量的記憶體，這會導緻頻繁的垃圾回收，但是垃圾回收會導緻工作現場全部停止，也就是說，垃圾回收一旦執行，Spark 的 Executor 程序就會停止工作，無法提供相應，此時，由于沒有響應，無法建立網絡連接配接，會導緻網絡連接配接逾時。

在生産環境下，有時會遇到file not found、file lost這類錯誤，在這種情況下，很有可能是Executor的BlockManager在拉取資料的時候，無法建立連接配接，然後超過預設的連接配接等待時長120s後，宣告資料拉取失敗，如果反複嘗試都拉取不到資料，可能會導緻 Spark 作業的崩潰。這種情況也可能會導緻 DAGScheduler 反複送出幾次 stage，TaskScheduler 傳回送出幾次 task，大大延長了我們的 Spark 作業的運作時間。

此時，可以考慮調節連接配接的逾時時長，連接配接等待時長需要在spark-submit腳本中進行設定

--conf spark.core.connection.ack.wait.timeout=300
           

調節連接配接等待時長後，通常可以避免部分的XX檔案拉取失敗、XX檔案lost等報錯。

  本次的分享就到這裡了,