天戈朱

     Spark 作為一個以擅長內存計算為優勢的計算引擎，內存管理方案是其非常重要的模塊； Spark的內存可以大體歸為兩類：execution和storage，前者包括shuffles、joins、sorts和aggregations所需內存，后者包括cache和節點間數據傳輸所需內存；在Spark 1.5和之前版本里，兩者是靜態配置的，不支持借用，spark1.6 對內存管理模塊進行了優化，通過內存空間的融合，消除以上限制，提供更好的性能。官方網站只是要求內存在8GB之上即可（Impala推薦要求機器配置在128GB）， 但spark job運行效率主要取決于：數據量大小，內存消耗，內核數（確定并發運行的task數量）

目錄：

•  基礎知識
• spark1.5- 內存管理
• spark1.6 內存管理

基本知識：

• on-heap memory：Java中分配的非空對象都是由Java虛擬機的垃圾收集器管理的，也稱為堆內內存。虛擬機會定期對垃圾內存進行回收，在某些特定的時間點，它會進行一次徹底的回收（full gc）。徹底回收時，垃圾收集器會對所有分配的堆內內存進行完整的掃描，這意味著一個重要的事實——這樣一次垃圾收集對Java應用造成的影響，跟堆的大小是成正比的。過大的堆會影響Java應用的性能
• off-heap memory：堆外內存意味著把內存對象分配在Java虛擬機的堆以外的內存，這些內存直接受操作系統管理（而不是虛擬機）。這樣做的結果就是能保持一個較小的堆，以減少垃圾收集對應用的影響
• LRU Cache（Least Recently Used）：LRU可以說是一種算法，也可以算是一種原則，用來判斷如何從Cache中清除對象，而LRU就是“近期最少使用”原則，當Cache溢出時，最近最少使用的對象將被從Cache中清除
• spark 源碼： https://github.com/apache/spark/releases
• scale ide for Intellij : http://plugins.jetbrains.com/plugin/?id=1347

Spark1.5- 內存管理：

• 1.6 版本引入了新的內存管理方案，配置參數： spark.memory.useLegacyMode 默認 false 表示使用新方案，true 表示使用舊方案， SparkEnv.scala 源碼 如下圖：
•  
• 在staticMemoryManager.scala 類中查看構造類及內存獲取定義
•       

• 通過代碼推斷，若設置了 spark.testing.memory 則以該配置的值作為 systemMaxMemory，否則使用 JVM 最大內存作為 systemMaxMemory。
• spark.testing.memory 僅用于測試，一般不設置，所以這里我們認為 systemMaxMemory 的值就是 executor 的最大可用內存
• Execution：用于緩存shuffle、join、sort和aggregation的臨時數據，通過spark.shuffle.memoryFraction配置
• spark.shuffle.memoryFraction：shuffle 期間占 executor 運行時內存的百分比，用小數表示。在任何時候，用于 shuffle 的內存總 size 不得超過這個限制，超出部分會 spill 到磁盤。如果經常 spill，考慮調大參數值
• spark.shuffle.safetyFraction：為防止 OOM，不能把 systemMaxMemory * spark.shuffle.memoryFraction 全用了，需要有個安全百分比
• 最終用于 execution 的內存量為：executor 最大可用內存* spark.shuffle.memoryFraction*spark.shuffle.safetyFraction，默認為 executor 最大可用內存 * 0.16
• execution內存被分配給JVM里的多個task線程。
• task間的execution內存分配是動態的，如果沒有其他tasks存在，Spark允許一個task占用所有可用execution內存

• storage內存分配分析過程與 Execution 一致，由上面的代碼得出，用于storage 的內存量為: executor 最大可用內存 * spark.storage.memoryFraction * spark.storage.safetyFraction，默認為 executor 最大可用內存 * 0.54
• 在 storage 中，有一部分內存是給 unroll 使用的，unroll 即反序列化 block，該部分占比由 spark.storage.unrollFraction 控制，默認為0.2

• 通過代碼分析，storage 和 execution 總共使用了 80% 的內存，剩余 20% 內存被系統保留了，用來存儲運行中產生的對象,該類型內存不可控.

小結：

• 這種內存管理方式的缺陷，即 execution 和 storage 內存表態分配，即使在一方內存不夠用而另一方內存空閑的情況下也不能共享，造成內存浪費，為解決這一問題，spark1.6 啟用新的內存管理方案UnifiedMemoryManager
• staticMemoryManager- jvm 堆內存分配圖如下

Spark1.6 內存管理：

• 從spark1.6開始，引入了新的內存管理方式-----統一內存管理(UnifiedMemoryManager)，在統一內存管理下，spark一個executor中的jvm heap內存被劃分成如下圖:

• Reserved Memory,這一部分的內存是我們無法使用的部分，spark內部保留內存，會存儲一些spark的內部對象等內容。
• spark1.6默認的Reserved Memory大小是300MB。這部分大小是不允許我們使用者改變的。簡單點說就是我們在為executor申請內存后，有300MB是我們無法使用的。并且如果我們申請的executor的大小小于1.5 * Reserved Memory 即 < 450MB，spark會報錯:
• User Memory：用戶在程序中創建的對象存儲等一系列非spark管理的內存開銷都占用這一部分內存
• Spark Memory：該部分大小為 (JVM Heap Size - Reserved Memory) * spark.memory.fraction,其中的spark.memory.fraction可以是我們配置的(默認0.75)，如下圖：
• 如果spark.memory.fraction配小了，我們的spark task在執行時產生數據時，包括我們在做cache時就很可能出現經常因為這部分內存不足的情況而產生spill到disk的情況，影響效率。采用官方推薦默認配置
• Spark Memory這一塊有被分成了兩個部分，Execution Memory 和 Storage Memory,這通過spark.memory.storageFraction來配置兩塊各占的大小(默認0.5，一邊一半)，如圖：
• Storage Memory主要用來存儲我們cache的數據和臨時空間序列化時unroll的數據，以及broadcast變量cache級別存儲的內容
• Execution Memory則是spark Task執行時使用的內存(比如shuffle時排序就需要大量的內存)
• 為了提高內存利用率，spark針對Storage Memory 和 Execution Memory有如下策略:

1. 1. 一方空閑，一方內存不足情況下，內存不足一方可以向空閑一方借用內存
   2. 只有Execution Memory可以強制拿回Storage Memory在Execution Memory空閑時，借用的Execution Memory的部分內存（如果因強制取回，而Storage Memory數據丟失，重新計算即可）
   3. 如果Storage Memory只能等待Execution Memory主動釋放占用的Storage Memory空閑時的內存。(這里不強制取回，因為如果task執行，數據丟失就會導致task 失敗)