本文1、2、3節介紹了Spark 內存相關之識，第4節描述了常見錯誤類型及產生原因并給出了解決方案。
1 堆內和堆外內存規劃
Executor 的內存管理建立在 JVM 的內存管理之上，Spark 對 JVM 的空間（Heap+Off-heap）進行了更為詳細的分配，以充分利用內存。同時，Spark 引入了Off-heap（TungSten）內存模式，使之可以直接在工作節點的系統內存中開辟空間，進一步優化了內存的使用（可以理解為是獨立于JVM托管的Heap之外利用c-style的malloc從os分配到的memory。由于不再由JVM托管，通過高效的內存管理，可以避免JVM object overhead和Garbage collection的開銷）。
運行于Executor中的Task同時可使用JVM和Off-heap兩種模式的內存。
- JVM OnHeap內存： 大小由”--executor-memory”(即 spark.executor.memory)參數指定。Executor中運行的并發任務共享JVM堆內內存。
- JVM OffHeap內存：大小由“spark.yarn.executor.memoryOverhead”參數指定，主要用于JVM自身，字符串, NIO Buffer等開銷。
- Off-heap模式：默認情況下Off-heap模式的內存并不啟用，可以通過“spark.memory.offHeap.enabled”參數開啟，并由spark.memory.offHeap.size指定堆外內存的大小（占用的空間劃歸JVM OffHeap內存）。
==備注==：我們現在未啟用Off-heap模式的內存，因此，只介紹JVM模式的Executor內存管理。以下出現有Off-heap均為JVM中區別于Heap的內存。
2 Executor內存劃分
2.1 Executor可用內存總量
如上圖所示，Yarn集群管理模式中，Spark 以Executor Container的形式在NodeManager中運行，其可使用的內存上限由“yarn.scheduler.maximum-allocation-mb” 指定, ====我們可以稱其為MonitorMemory ====。
如前所述，Executor的內存由Heap內存和設定的Off-heap內存組成。
Heap： 由“spark.executor.memory” 指定, 以下稱為ExecutorMemory
Off-heap： 由 “spark.yarn.executor.memoryOverhead” 指定， 以下稱為MemoryOverhead
因此, 對現有Yarn集群，存在：
ExecutorMemory + MemoryOverhead <= MonitorMemory
若應用提交之時，指定的 ExecutorMemory與MemoryOverhead 之和大于 MonitorMemory，則會導致Executor申請失敗；若運行過程中，實際使用內存超過上限閾值，Executor進程會被Yarn終止掉（kill）。
2.2 Heap
Spark 對Heap內存的管理是邏輯上的劃分管理（限制各有邏輯區域內存量及記錄使用狀態），對象實例真正占用內存的管理(申請和釋放)都由JVM完成。
“spark.executor.memory”指定的內存為JVM最大分配的堆內存（“-xmx”），Spark為了更高效的使用這部分內存，對這部分內存進行了細分，下圖（備注：此圖源于互聯網）對基于spark 2 （1.6）對堆內存分配比例進行了描述：
其中：
- Reserved Memory保留內存，系統默認值為300，一般無需改動，不用關心此部分內存。 但如果Executor分配的內存小于 1.5 * 300 = 450M時，Executor將無法執行。
- Storage Memory 存儲內存
用于存放廣播數據及RDD緩存數據。由上圖可知，Spark 2+中，初始狀態下，Storage及Execution Memory均約占系統總內存的30%（1 * 0.6 * 0.5 = 0.3）。在UnifiedMemory管理中，這兩部分內存可以相互借用，為了方便描述,我們使用storageRegionSize來表示“spark.storage.storageFraction”。當計算內存不足時，可以改造storageRegionSize中未使用部分，且StorageMemory需要存儲內存時也不可被搶占； 若實際StorageMemory使用量超過storageRegionSize，那么當計算內存不足時，可以改造(StorageMemory – storageRegionSize)部分，而storageRegionSize部分不可被搶占。
==備注==： Unified Memory中，spark.shuffle.memoryFraction, spark.storage.unrollFraction等參數無需在指定。
2.3 Java Off-heap (Memory Overhead)
Executor 中，另一塊內存為由“spark.yarn.executor.memoryOverhead”指定的Java Off-heap內存，此部分內存主要是創建Java Object時的額外開銷，Native方法調用，線程棧， NIO Buffer等開銷（Driect Buffer）。此部分為用戶代碼及Spark 不可操作的內存，不足時可通過調整參數解決, 無需過多關注。 具體需要調整的場景參見本文第4節。
3 任務內存管理（Task Memory Manager）
Executor中任務以線程的方式執行，各線程共享JVM的資源，任務之間的內存資源沒有強隔離（任務沒有專用的Heap區域）。因此，可能會出現這樣的情況：先到達的任務可能占用較大的內存，而后到的任務因得不到足夠的內存而掛起。
在Spark任務內存管理中，使用HashMap存儲任務與其消耗內存的映射關系。每個任務可占用的內存大小為潛在可使用計算內存的1/2n – 1/n , 當剩余內存為小于1/2n時，任務將被掛起，直至有其他任務釋放執行內存，而滿足內存下限1/2n，任務被喚醒，其中n為當前Executor中活躍的任務數。
任務執行過程中，如果需要更多的內存，則會進行申請，如果，存在空閑內存，則自動擴容成功，否則，將拋出OutOffMemroyError。
==備注==：潛在可使用計算內存為：初始計算內存+可搶占存儲內存
4 內存調整方案
Executor中可同時運行的任務數由Executor分配的CPU的核數N 和每個任務需要的CPU核心數C決定。其中:
- N = spark.executor.cores
- C = spark.task.cpus
Executor的最大任務并行度可表示為 ==TP = N / C==. 其中,C值與應用類型有關，大部分應用使用默認值1即可，因此，影響Executor中最大任務并行度的主要因素是N.
依據Task的內存使用特征，前文所述的Executor內存模型可以簡單抽象為下圖所示模型：
其中，Executor 向yarn申請的總內存可表示為： M = M1 + M2 .
4.1 錯誤類型及調整方案
4.1.1 Executor OOM類錯誤 （錯誤代碼 137、143等）
該類錯誤一般是由于Heap（M2）已達上限，Task需要更多的內存，而又得不到足夠的內存而導致。因此，解決方案要從增加每個Task的內存使用量，滿足任務需求 或 降低單個Task的內存消耗量，從而使現有內存可以滿足任務運行需求兩個角度出發。因此：
4.1.1.1 增加單個task的內存使用量
- 增加最大Heap值， 即 上圖中M2 的值，使每個Task可使用內存增加。
- 降低Executor的可用Core的數量 N , 使Executor中同時運行的任務數減少，在總資源不變的情況下，使每個Task獲得的內存相對增加。
4.1.1.2 降低單個Task的內存消耗量
降低單個Task的內存消耗量可從配制方式和調整應用邏輯兩個層面進行優化：
-
配制方式
減少每個Task處理的數據量，可降低Task的內存開銷，在Spark中，每個partition對應一個處理任務Task, 因此，在數據總量一定的前提下，可以通過增加partition數量的方式來減少每個Task處理的數據量,從而降低Task的內存開銷。針對不同的Spark應用類型，存在不同的partition調整參數如下：
- P = spark.default.parallism (非SQL應用)
- P = spark.sql.shuffle.partition (SQL 應用)
通過增加P的值，可在一定程度上使Task現有內存滿足任務運行
注: 當調整一個參數不能解決問題時，上述方案應進行協同調整==備注：若應用shuffle階段 spill嚴重，則可以通過調整“spark.shuffle.spill.numElementsForceSpillThreshold”的值，來限制spill使用的內存大小 ，比如設置（2000000），該值太大不足以解決OOM問題，若太小，則spill會太頻繁，影響集群性能，因此，要依據負載類型進行合理伸縮（此處，可設法引入動態伸縮機制，待后續處理）。==
-
調整應用邏輯
Executor OOM 一般發生Shuffle階段，該階段需求計算內存較大，且應用邏輯對內存需求有較大影響，下面舉例就行說明：
- groupByKey 轉換為 reduceByKey
一般情況下，groupByKey能實現的功能使用reduceByKey均可實現，而ReduceByKey存在Map端的合并，可以有效減少傳輸帶寬占用及Reduce端內存消耗。
- groupByKey 轉換為 reduceByKey
-
data skew 預處理
Data Skew是指任務間處理的數據量存大較大的差異。
如左圖所示，key 為010的數據較多，當發生shuffle時，010所在分區存在大量數據，不僅拖慢Job執行（Job的執行時間由最后完成的任務決定）。 而且導致010對應Task內存消耗過多，可能導致OOM. 而右圖，經過預處理（加鹽，此處僅為舉例說明問題，解決方法不限于此）可以有效減少Data Skew導致 的問題
==注：上述舉例僅為說明調整應用邏輯可以在一定程序上解決OOM問題，解決方法不限于上述舉例==
4.1.2 Beyond…… memory, killed by yarn.
出現該問題原因是由于實際使用內存上限超過申請的內存上限而被Yarn終止掉了, 首先說明Yarn中Container內存監控機制：
- Container進程的內存使用量：以Container進程為根的進程樹中所有進程的內存使用總量。
- Container被殺死的判斷依據：進程樹總內存（物理內存或虛擬內存）使用量超過向Yarn申請的內存上限值，則認為該Container使用內存超量，可以被“殺死”。
因此，對該異常的分析要從是否存在子進程兩個角度出發。
1） 不存在子進程
根據Container進程殺死的條件可知，在不存在子進程時，出現killed by yarn問題是于由Executor(JVM)進程自身內存超過向Yarn申請的內存總量M 所致。由于未出現4.1.1節所述的OOM異常，因此可判定其為 M1 (Overhead)不足, 依據Yarn內存使用情況有如下兩種方案：
- 如果，M未達到Yarn單個Container允許的上限時，可僅增加M1 ，從而增加M；如果，M達到Yarn單個Container允許的上限時，增加 M1， 降低 M2.
操作方法：在提交腳本中添加 --conf spark.yarn.executor.memoryOverhead=3072(或更大的值，比如4096等) --conf spark.executor.memory = 10g 或 更小的值，注意二者之各要小于Container監控內存量,否則伸請資源將被yarn拒絕。 - 減少可用的Core的數量 N, 使并行任務數減少，從而減少Overhead開銷
操作方法：在提交腳本中添加 --executor-cores=3 <比原來小的值> 或 --conf spark.executor.cores=3 <比原來小的值>
2）存在子進程
Spark 應用中Container以Executor（JVM進程）的形式存在，因此根進程為Executor對應的進程, 而Spark 應用向Yarn申請的總資源M = M1 + M 2 , 都是以Executor（JVM）進程（非進程樹）可用資源的名義申請的。申請的資源并非一次性全量分配給JVM使用，而是先為JVM分配初始值，隨后內存不足時再按比率不斷進行擴容，直致達到Container監控的最大內存使用量M 。當Executor中啟動了子進程（調用shell等）時，子進程占用的內存（記為 S） 就被加入Container進程樹，此時就會影響Executor實際可使用內存資源（Executor進程實際可使用資源為：M - S），然而啟動JVM時設置的可用最大資源為M， 且JVM進程并不會感知Container中留給自己的使用量已被子進程占用，因此，當JVM使用量達到 M - S，還會繼續開劈內存空間，這就會導致Executor進程樹使用的總內存量大于M 而被Yarn 殺死。
典形場景有：PySpark（Spark已做內存限制，一般不會占用過大內存）、自定義Shell調用。其解決方案：
- PySpark場景：
- 如果，M未達到Yarn單個Container允許的上限時，可僅增加M1 ，從而增加M；如果，M達到Yarn單個Container允許的上限時，增加 M1， 降低 M2.
- 減少可用的Core的數量 N, 使并行任務數減少，從而減少Overhead開銷
- 自定義Shell 場景：（OverHead不足為假象）
- 調整子進程可用內存量，（通過單機測試，內存控制在Container監控內存以內，且為Spark保留內存等留有空間）。
操作方法同4.1.2<1>中所述
- 調整子進程可用內存量，（通過單機測試，內存控制在Container監控內存以內，且為Spark保留內存等留有空間）。
特別鳴謝：海華師兄
轉載請注明：http://www.lxweimin.com/p/10e91ace3378
參考文獻：
https://spark.apache.org/docs/latest/tuning.html
https://0x0fff.com/spark-memory-management/ https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-apache-spark-memory-management/index.html?ca=drs-&utm_source=tuicool&utm_medium=referral
