一.內容簡介

spark從1.6開始引入了動態內存管理模式，即執行內存和存儲內存之間可以互相搶占。spark提供兩種內存分配模式：靜態內存管理和動態內存管理。本系列文章分別對這兩種內存管理模式的優缺點以及設計原理進行了分析。主要針對spark1.6靜態內存管理進行了分析與說明。

[[252832]]

二.內存空間分配

在 Spark 最初采用的靜態內存管理機制下，存儲內存、執行內存和其他內存的大小在 Spark 應用程序運行期間均為固定的，但用戶可以應用程序啟動前進行配置，堆內內存的分配如下圖所示：

默認情況下，spark內存管理采用unified模式，如果要開啟靜態內存管理模式。將Spark.memory.useLegacyMode參數調為true(默認為false)。官網相關配置如下：

當調整該參數以后，從SparkEnv.scala中可知，如果為true，內存管理調用靜態內存類(StaticMemoryManager)。反之,內存管理采用統一內存管理類(UnifiedMemoryManager)。

三.Execution 內存

可用的Execution內存

用于shuffle聚合內存，取決于joins,sorts,aggregations等過程中頻繁的IO需要的Buffer臨時數據存儲。

簡單來說，spark在shuffle write的過程中，每個executor會將數據寫到該executor的物理磁盤上，下一個stage的task會去上一個stage拉取其需要處理的數據，并且是邊拉取邊進行處理的(和MapReduce的拉取合并數據基本一樣)，這個時候會用一個aggregate的數據結構，比如hashmap邊拉取數據邊進行聚合。這部分內存就被稱做execution內存。

從getMaxExecutironMemory方法可知，每個executor分配給execution的內存為：Execution Memory = systemMaxMemory *memoryFraction(默認0.2) * safetyFraction(默認0.8), 默認為 executor ***可用內存 * 0.16。

Execution內存在運行時會被分配給運行在JVM上的task。這里不同的是，分配給每個task的內存并不是固定的，而是動態的。spark不是一上來就分配固定大小的內存塊給task，而是允許一個task占據JVM所有execution內存。

每個JVM上的task可以最多申請至多1/N的execution內存(N為active task的個數,由spark.executor.cores指定)。如果task的申請沒有被批準，它會釋放一部分內存，并且下次申請的時候，它會申請更小的一部分內存。

注意：為了防止過多的spilling(evict)數據，只有當一個task分配到的內存達到execution內存1/(2N)的時候才會spill, 如果目前空閑的內存達不到1/(2N)的時候, 內存申請會被阻塞直到其他的taskspill掉它們的內存。如果不這樣限制，假設當前有一個任務占據了絕大部分內存，那么新來的task會一直往硬盤spill數據，這樣就會導致比較嚴重的I/O問題。

舉個例子, 某executor先啟動一個task A，并在task B啟動前快速占用了所有可用內存。(B啟動后)N變成2，task B會阻塞直到task A spill，自己可獲得1/(2N)=1/4的execution內存。而一旦task B獲取到了1/4的內存，A和B就都有可能spill了。

預留內存

Spark之所以有一個SafetyFraction這樣的參數，是為了避免潛在的OOM。例如，進行計算時，有一個提前未預料到的比較大的數據，會導致計算時間延長甚至OOM, safetyFraction為storage和execution 都提供了額外的buffer以防止此類的數據傾斜。這部分內存叫做預留內存。

四.Storage內存

可用的Storage內存

該部分內存用作對RDD的緩存(如調用cache,persist等方法)，節點間傳輸的廣播變量。

從StaticMemoryManager的單例對象中可知，***為每個executor分配到的關于storage的內存：

StorageMemory=systemMaxMemory*storageMemoryFraction(默認0.6)*safetyFraction(默認為0.9)=0.54,

也就是說 默認分配executor ***可用內存的 *0.54。源碼如下：

預留內存

同Execution內存中的預留部分。

Unroll

unroll是storage中比較特殊的一部分，它默認占據總內存的20%。

BlockManager是spark自己實現的內部分布式文件系統，BlockManager接受數據(可能從本地或者其他結點)的時候是以iterator的形式，并且這些數據有序列化和非序列化的。需要注以下兩點：

a) iterator在物理內存上是不連續的，如果后續spark要把數據裝載進內存的話，就需要把這些數據放進一個array(物理上連續)。

b) 另外，序列化數據需要進行展開，如果直接展開序列化的數據，會造成OOM, 所以，BlockManager會逐漸的展開這個iterator，并逐漸檢查內存里是否還有足夠的空間用來展開數據放進array里。

unroll的優先級還是比較高的，它使用的內存空間可以從storage中借用，如果在storage中沒有現存的數據block，它甚至可以占據整個storage空間。如果storage中有數據block，它可以***drop掉內存的數據是以spark.storage.unrollFraction來控制的。由圖6可知，這部分默認為storage的20%。

注意：這個20%的空間并不是靜態保留的，而是通過drop掉內存中的數據block來分配的。如果unroll失敗了，spark會把這部分數據evict 到硬盤。

五.Other 部分

這片內存用于程序本身運行所需的內存，以及用戶定義的數據結構和創建的對象，此內存有上面兩部分決定，默認為0.2。

六.局限性

spark的設計文檔中指出靜態內存有以下局限性：

(1)沒有適用于所有應用的默認配置，通常需要開發人員針對不同的應用進行不同的參數配置。比如根據任務的執行邏輯，調整shuffle和storage內存占比來適應任務的需求。

(2) 這樣需要開發人員具備較高的spark原理知識。

(3) 那些不cache數據的應用在運行時只占用一小部分可用內存，因為默認的內存配置中，storage用去了safety內存的60%。

概念補充

eviction策略：在spark技術文檔中，eviction一詞經常出現。eviction并不是單純字面上驅逐的意思。說句題外話，spark我們通常都把它叫做內存計算框架，嚴格意義來說，spark并不是內存計算的新技術。無論是cache還是persist這類算子，spark在內存安排上，絕大多數用的都是LRU策略(LRU可以說是一種算法，也可以算是一種原則，用來判斷如何從Cache中清除對象，而LRU就是“近期最少使用”原則，當Cache溢出時，最近最少使用的對象將被從Cache中清除)。即當內存不夠的時候，會evict掉最遠使用過的內存數據block。當evict的時候，spark會將該數據塊evict到硬盤，而不是單純的拋棄掉。

無論是storage還是execution的內存空間，當內存區域的空間不夠用的時候，spark都會evict數據到硬盤。

因此，如果開發人員在內存分配上沒有合理的進行分配，無論是在storage還是execution超過內存的限制的時候，spark會把內存的數據寫到硬盤。如果是storage的情況，甚至可能把內存的數據全部寫到硬盤并丟掉。這樣做，無疑會增加系統調用、I/O以及重復計算的開銷。有過開發spark任務中包含大量shuffle stage的同學應該有同感，shuffle memory不夠的時候，spill到硬盤的數據會很大，導致任務很慢，甚至會導致任務的各種重試***任務fail掉。這種情況建議提高shuffle memory fraction。如果是資源調度在yarn上，建議通過spark.yarn.executor.memoryOverhead提高堆外內存，有的時候甚至會調到2g，3g，4g直到任務成功。spark相關優化，請參見spark系列后續的文章。

七.參考

[1] Unified Memory Management in Spark 1.6,Andrew Or and Josh Rosen

[2]https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-apache-spark-memory-management/index.html?ca=drs-&utm_source=tuicool&utm_medium=referral

[3] https:// http://spark.apache.org

[4] http://www.jianshu.com/p/e41b18a7e202