推薦大家去看原文博主的文章，條理清晰閱讀方便，轉載是爲了方便以後個人查閱
https://www.cnblogs.com/coco2015/p/11240677.html
1 堆內和堆外內存規劃
Spark執行器(Executor)的內存管理建立在 JVM 的內存管理之上，Spark 對 JVM 的空間（OnHeap+Off-heap）進行了更爲詳細的分配，以充分利用內存。同時，Spark 引入了Off-heap 內存模式，使之可以直接在工作節點的系統內存中開闢空間，進一步優化了內存的使用（可以理解爲是獨立於JVM託管的Heap之外利用c-style的malloc從os分配到的memory。由於不再由JVM託管，通過高效的內存管理，可以避免JVM object overhead和Garbage collection的開銷）。
運行於Executor中的Task同時可使用JVM(OnHeap+Off-heap)和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的內存。
---OffHeap內存：存儲經過序列化的二進制數據，Spark 可以直接操作系統堆外內存，減少了不必要的內存開銷，以及頻繁的 GC 掃描和回收，提升了處理性能。堆外內存可以被精確地申請和釋放，而且序列化的數據佔用的空間可以被精確計算，所以相比堆內內存來說降低了管理的難度，也降低了誤差。
2 Executor內存劃分
2.1 Executor可用內存總量
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.executor.memory"指定的內存爲JVM最大分配的堆內存（"-xmx"），Spark爲了更高效的使用這部分內存，對這部分內存進行了細分，下圖（備註：此圖源於互聯網）對基於spark2(1.6+)對堆內存分配比例進行了描述：
Heap內存模型
其中：
- 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部分不可被搶佔。
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內存簡化模型
其中，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 = mapred.reduce.tasks (HiveOnSpark)
通過增加P的值，可在一定程度上使Task現有內存滿足任務運行
注: 當調整一個參數不能解決問題時，上述方案應進行協同調整
---備註：若應用shuffle階段 spill嚴重，則可以通過調整“spark.shuffle.spill.numElementsForceSpillThreshold”的值，來限制spill使用的內存大小，比如設置（2000000），該值太大不足以解決OOM問題，若太小，則spill會太頻繁，影響集羣性能，因此，要依據負載類型進行合理伸縮（此處，可設法引入動態伸縮機制，待後續處理）。
- 調整應用邏輯：
Executor OOM 一般發生Shuffle階段，該階段需求計算內存較大，且應用邏輯對內存需求有較大影響，下面舉例就行說明：
- groupByKey 轉換爲 reduceByKey
一般情況下，groupByKey能實現的功能使用reduceByKey均可實現，而ReduceByKey存在Map端的合併，可以有效減少傳輸帶寬佔用及Reduce端內存消耗。
選擇合適的算子
- data skew 預處理
Data Skew是指任務間處理的數據量存大較大的差異。
如左圖所示，key 爲010的數據較多，當發生shuffle時，010所在分區存在大量數據，不僅拖慢Job執行（Job的執行時間由最後完成的任務決定）。 而且導致010對應Task內存消耗過多，可能導致OOM. 而右圖，經過預處理（加鹽，此處僅爲舉例說明問題，解決方法不限於此）可以有效減少Data
Skew導致 的問題
Data Skew預處理
---注：上述舉例僅爲說明調整應用邏輯可以在一定程序上解決OOM問題，解決方法不限於上述舉例
4.1.2 Beyond…… memory, killed by yarn
出現該問題原因是由於實際使用內存上限超過申請的內存上限而被Yarn終止掉了, 首先說明Yarn中Container內存監控機制：
- Container進程的內存使用量：以Container進程爲根的進程樹中所有進程的內存使用總量。
- Container被殺死的判斷依據：進程樹總內存（物理內存或虛擬內存）使用量超過向Yarn申請的內存上限值，則認爲該Container使用內存超量，可以被“殺死”。
因此，對該異常的分析要從是否存在子進程兩個角度出發。
a 不存在子進程
根據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 <比原來小的值>
b 存在子進程
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>中所述