??大家好，我是不溫卜火，是一名計算機學院大資料專業大二的學生，昵稱來源于成語—
不溫不火，本意是希望自己性情溫和，作為一名互聯網行業的小白，博主寫博客一方面是為了記錄自己的學習程序，另一方面是總結自己所犯的錯誤希望能夠幫助到很多和自己一樣處于起步階段的萌新，但由于水平有限，博客中難免會有一些錯誤出現，有紕漏之處懇請各位大佬不吝賜教！暫時只有csdn這一個平臺，博客主頁：https://buwenbuhuo.blog.csdn.net/
??本片博文為大家帶來的是JVM 調優，
目錄
- 1. 降低cache操作的記憶體占比
- 2. 調節Executor堆外記憶體
- 3. 調節連接等待時長
對于 JVM 調優，首先應該明確，full gc/minor gc，都會導致JVM的作業執行緒停止作業，即stop the world，
1. 降低cache操作的記憶體占比
- 靜態記憶體管理機制
根據 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 的記憶體區域，因此無需手動進行調節，
2. 調節Executor堆外記憶體
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 作業的性能，
3. 調節連接等待時長
在 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等報錯，
??本次的分享就到這里了,
??好書不厭讀百回，熟讀課思子自知，而我想要成為全場最靚的仔，就必須堅持通過學習來獲取更多知識，用知識改變命運，用博客見證成長，用行動證明我在努力，
??如果我的博客對你有幫助、如果你喜歡我的博客內容，請“點贊” “評論”“收藏”一鍵三連哦！聽說點贊的人運氣不會太差，每一天都會元氣滿滿呦！如果實在要白嫖的話，那祝你開心每一天，歡迎常來我博客看看，
??碼字不易，大家的支持就是我堅持下去的動力，點贊后不要忘了關注我哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/1446.html
標籤：其他
上一篇：Jmeter常用引數化設定