Spark1.6内存管理

436次阅读

共计 3730 个字符，预计需要花费 10 分钟才能阅读完成。

Spark 从 1.6.0 版本开始，内存管理模块就发生了改变，旧版本的内存管理模块是实现了 StaticMemoryManager 类，现在被称为 ”legacy”。”Legacy” 模式默认被置为不可用，这就意味着当你用 Spark1.5.x 和 Spark1.6.x 运行相同的代码会有不同的结果，应当多加注意。考虑的兼容性，可以通过设置 spark.memory.useLegacyMode 为可用，默认是 false.

这篇文章介绍自 spark1.6.0 版本后的新的内存管理模型，它实现的是 UnifiedMemoryManager 类。

Spark1.6 内存管理

在这张图中你可以看到三个主要内存区域。

1.Reserved Memory. 这部分内存是被系统预留的，它的大小也是被硬编码的。在 Spark1.6.0 版本，它的大小是 300MB，这就意味着这部分内存不能计入 Spark 内存计算，除非重新编译源码或设置 spark.testing.reservedMemory，它的大小是不可改变的，因为 park.testing.reservedMemory 只是一个测试参数所以在生产中不推荐使用。注意，这部分内存只是被称为“Reserved”, 实际上它不会被 spark 用来干任何事情，但是它限制了你在 spark 中可分配的内存大小。即使你想将全部 JVM 堆内存用于 spark 缓存数据，也不能使用这部分空闲内存（不是真的就浪费了，其实它存储了 Spark 的一些内部对象）。供参考，如果你不能为 executor 至少 1.5 * Reserved Memory = 450MB 的堆内存，任务将会失败并提示”please use larger heap size“的错误信息。

2.User Memory. 这部分内存是分配 Spark Memory 内存之后的部分，而且这部分用来干什么完全取决于你。你可以用来存储 RDD transformations 过程使用的数据结构。例如，你可以通过 mapPartitions transformation 重写 Spark aggregation，mapPartitions transformations 保存 hash 表保证 aggregation 运行。这部分数据就保存在 User Memory。再次强调，这是 User Memory 它完全由你决定存什么、如何使用，Spark 完全不会管你拿这块区域用来做什么，怎么用，也不会考虑你的代码在这块区域是否会导致内存溢出。

3.Spark Memory. 这部分内存就是由 Spark 管理了。这部分内存大小的计算：(“Java Heap”–“Reserved Memory”) * spark.memory.fraction，而且在 spark1.6.0 版本默认大小为：(“Java Heap”– 300MB) * 0.75。例如：如果堆内存大小有 4G，将有 2847MB 的 Spark Memory,Spark Memory=(4*1024MB-300)*0.75=2847MB。这部分内存会被分成两部分：Storage Memory 和 Execution Memory，而且这两部分的边界由 spark.memory.storageFraction 参数设定，默认是 0.5 即 50%。新的内存管理模型中的优点是，这个边界不是固定的，在内存压力下这个边界是可以移动的。如一个区域内存不够用时可以从另一区域借用内存。下边来讨论如何移动及使用的：

1.Storage Memory. 这部分内存即可以用来缓存 spark 数据也可以用来做 unroll 序列化数据的临时空间。广播变量以 block 的形式也存储在这里。你奇怪的是 unroll, 因为你可能会说，并不需要那么多空间去 unroll block 使其可用——在没有足够内存去 unroll bolock 的情况下，如果得到持久化级别的允许，将直接在这部分内存 unroll block。至于广播变量，当它的持久化级别为 MEMORY_AND_DISK 时，就会缓存到此。

2.Execution Memory. 这部分内存用于存储执行 task 过程中的一些对象。例如，它可以用来 shuflle map 端的中间缓存，也可以用来存储 hash aggregation 过程的 hash table. 在没有足够内存的时候，这部分内存支持溢室到磁盘，但是这部分内存的 blocks 不会被其它线程的 task 挤出去。

下边我们来说一下 Storage Memory 和 Execution Memory 之间的边界移动。从 Execution Memory 的本质来看，你不能将这部分内存空间的数据挤出去，因为这部分内存的数据是用来计算的中间结果，如果计算过程找不到原来存到这的 block 数据任务就会失败。但是对于 Storage Memory 内存就不会这样，它只是用来缓存内存中数据，如果将里边的 block 数据驱逐出去，就会更新 block 元数据映射信息使用到时告知该 block 被移除了，要想再拿到这些数据从 HDD 中读取即可（或者如果缓存级别没有溢写就重新计算）。

所以，我们只能 Execution Memory 可以向 Storage Memory 挤用空间，反之不可。那么当什么时候会发生 Execution Memory 向 Storage Memory 挤用空间呢？有两种可能：

•只要 Storage Memory 有可用空间，就可以增大 Execution Memory 大小，减少 Storage Memory 大小。

•Storage Memory 的空间大小已经超出了初始设定的大小，并且将这部分空间全部占用，在这种情况下就可以强制将从 Storage Memory 中移出 Blocks, 减少它的空间到初始大小。

反过来，在只有当 Execution Memory 空间有空余时，Storage Memory 才可以向 Execution Memory 借用空间，也就是说 Execution Memory 只要不够用了就可以向 Storage Memory 挤占空间不管 Storage Memory 有没有空余，而 Storage Memory 只能当 Execution Memory 有空余时才要以借用不能抢占。

初始 Storage Memory 大小：“Spark Memory”* spark.memory.storageFraction = (“Java Heap”–“Reserved Memory”) * spark.memory.fraction * spark.memory.storageFraction。根据默认值，即(“Java Heap”– 300MB) * 0.75 * 0.5 = (“Java Heap”– 300MB) * 0.375. 如果 Java Heap=4G，那么就有 1423.5MB 大小的 Storage Memory 空间。

这就意味着当我们使用 Spark cacheu 并加载全部数据到 executor 中时，至少要将 Storage Memory 大小等于默认初始值大小。因为当 Storage Memory 区域还没满时，Execution Memory 区域已经膨胀大于其初始设定大小时，我们不能强制将 Execution Memory 抢占的空间数据驱逐，所以最终 Storage Memory 会变小。

希望这篇文章可以帮你更好的理解 spark 新的内存管理机制，并以此来应用。

译自：spark-memory-management

更多 Spark 相关教程见以下内容：

CentOS 7.0 下安装并配置 Spark http://www.linuxidc.com/Linux/2015-08/122284.htm

Spark1.0.0 部署指南 http://www.linuxidc.com/Linux/2014-07/104304.htm

Spark 官方文档 – 中文翻译 http://www.linuxidc.com/Linux/2016-04/130621.htm

CentOS 6.2(64 位)下安装 Spark0.8.0 详细记录 http://www.linuxidc.com/Linux/2014-06/102583.htm

Spark 简介及其在 Ubuntu 下的安装使用 http://www.linuxidc.com/Linux/2013-08/88606.htm

安装 Spark 集群(在 CentOS 上) http://www.linuxidc.com/Linux/2013-08/88599.htm

Hadoop vs Spark 性能对比 http://www.linuxidc.com/Linux/2013-08/88597.htm

Spark 安装与学习 http://www.linuxidc.com/Linux/2013-08/88596.htm

Spark 并行计算模型 http://www.linuxidc.com/Linux/2012-12/76490.htm