spark 内存管理(1.6前后)

一：Memory Manager

StaticMemoryManager 和 UnifiedMemoryManager

StaticMemoryManager

1.6版本之前的内存管理

概念上，内存空间被分成了三块独立的区域，每块区域的内存容量是按照JVM堆大小的固定比例进行分配的：

• Execution：在执行shuffle、join、sort和aggregation时，用于缓存中间数据。通过spark.shuffle.memoryFraction进行配置，默认为0.2。
• Storage：主要用于缓存数据块以提高性能，同时也用于连续不断地广播或发送大的任务结果。通过`spark.storage.memoryFraction进行配置，默认为0.6。
• Other：这部分内存用于存储运行Spark系统本身需要加载的代码与元数据，默认为0.2。

这种内存分配机制，最大的问题是，谁都不能超过自己的上限，规定了是多少就是多少，虽然另外一片内存闲着呢。这在是StorageMemory 和 ExecutionMemory比较严重，他们都是消耗内存的大户。这个问题引出了Unified Memory Management模型，重点是打破ExecutionMemory 和 StorageMemory 这种分明的界限。

UnifiedMemoryManager

统一内存管理：Execution和Storage之间是软边界，任一方都可以从另一方借用内存。Execution和Storage之间共享的区域是通过`spark.memory.fraction`（1.6.2默认为0.75，2.2默认值0.6）配置的，大小是：（HeapSize-300MB）*0.75。 该空间内的边界的位置由`spark.memory.storageFraction`（默认为0.5）进一步确定。 这意味着默认情况下，存储区的大小为0.75* 0.5 = 0.375的堆空间。

  存储可以借用尽可能多的执行内存，直到执行回收其空间。 当发生这种情况时，缓存的块将被释放到内存中，直到释放足够的借用内存以满足执行存储器请求。 类似地，执行可以借用尽可能多的存储空间。然而，由于执行此操作涉及复杂性，执行内存不会因存储而被驱逐。 这意味着，如果执行已经占用了大部分存储空间，那么尝试缓存块可能会失败，在这种情况下，新块将根据各自的存储级别去降级存储，例如Memory。