Spark的内存管理机制

最新推荐文章于 2024-01-14 21:04:59 发布

淡定一生2333

最新推荐文章于 2024-01-14 21:04:59 发布

阅读量591

点赞数 1

分类专栏： Spark学习

本文链接：https://blog.csdn.net/zc19921215/article/details/86442158

版权

Spark学习专栏收录该内容

31 篇文章 5 订阅

订阅专栏

本来是想着直接分析下UnsafeShuffleWriter源码内部是怎么实现的，碰到的一个尴尬的问题是代码内部涉及到了很多关于内存分配相关的代码，而且它使用了Tungsten优化，更加看不懂细节了，所以决定先了解下Spark的内存管理机制然后再看Shuffle的实现。

之前在“SparkContext初始化流程”那篇文章中提到过，内存管理是MemoryManager实现的，在SparkEnv中被初始化。本文不关注Driver上的MemoryManager，只分析Executor上的内存是如何管理的。

Spark1.6之前的静态内存管理机制介绍：

因为默认已经不使用这种方式了，所以这里只是提一提，结构如下所示，各个部分的作用稍后会解释(图片皆来源与“参考”中的“1”)：

堆内：

堆外：

Spark1.6之后的动态内存管理：

堆内：

Storage: 用于broadcast/cache/persist数据的存储

Execution: 用于Shuffle,例如join/agg/sort等操作都是在这部分内存中执行

Other(User Memory): 存储用户的数据结构，个人理解不是对RDD的操作用的都是这部分内存，例如在Executor端创建了一个HashMap

System Reserved: Spark给自身预留的内存，至少300M

System Reserved大小由”spark.testing.reservedMemory”参数控制

Storage+ Execution大小由“spark.memory.fraction”控制，默认0.6，个人感觉这个貌似可以调大…但是太大容易造成GC时间偏长，见“参考2”

Storage+ Execution所用内存中Execution所占的比例由“spark.memory.storageFraction”控制，默认0.5，官网建议不要改动这个配置，并且和1.6之前不同的是，它们之间的边界变成了“软边界”，内存可以在一定情况下相互借用。

(ps:Unroll已经完全归Storage管理了，它的大小不再固定)

堆外：

可以看到堆外和之前还是一样的，主要改动的是堆内。现在堆内的存储内存和执行内存可以动态调整，相互占用了(但是会优先保证执行内存足够)。动态内存机制如下：

查看UnifiedMemoryManager中acquire***()相关方法：

Execution向Storage借内存

1.1如果要申请的内存已经超过storagePool.memoryFree的话，那么会向Execution接内存，最多借executionPool.memoryFree。

1.2如果还不够，会调用evictBlocksToFreeSpace()，将不用的block移除，block要求不属于当前RDD并且memoryMode相关，就可以evict。

1.3 寻找可以移除的bloc，知道找到足够多的内存为止，如果找到了给它们加上写锁然后调用blockInfoMemory将它们移除。否则不移除并返回0L

2.Storage向Execution借内存

首先需要明确一点，单个Task不能拥有太多的内存，它被限制在了(1/N -1/2N) * MaxExecutionMemory之间，之所以加了个Max是当前Execution最大的内存，可能像Storage借了一部分，也可能被Storage拿走了一部分。

如果Execution空闲的空间不够时，首先会占用storagePool的空闲内存，如果不够就会要求storagePool归还它占用的那部分内存，还不够就叫storagePool evict掉一些block。

（注意：如果一开始进来storagePoolSize 就已经小于 storageRegionSize时，就不能要求evict了，storageRegionSize表示storagePoolSize最开始的大小，表示一开始storagePool的内存就已经不够用了，而且已经被Execution借走了一部分）

下面来分析下UnifiedMemoryManager其他的内部实现：

初始化：

UnifiedMemoryManager继承自MemoryManager,所以它先初始化父类

//1.初始化内存池

//2.判断tungsten是否启用了堆外内存

//3.判断一个page的大小，限定在1M~64M之间，我这里是16M，和服务器总核数以及内存总大小有关。page是tungsten中引入的优化概念，后面用到它的时候会讲到。

//4.根据模式确定任务在哪里分配内存：(这里是按照上面所说的Page分配内存，Unsafe/Tungsten模式下才会使用到，一般情况下都是直接申请多少个字节)

然后就初始化完毕了，可以看到其实一直都是在初始化父类中的属性。

这个MemoryManager是对于一个Executor而言的，同一个Executor内部的所有Task都调用它的接口来申请或者释放内存。申请时要指定申请的MemoryMode，表示申请的是堆内内存还是堆外内存

但是只有在使用Tungsten是才会使用到MemoryAllocator和Page的概念，看到目前为止是只有UnSafedShuffleWriter才会用到，可能有其他地方我没看到。

单个任务内存管理-TaskMemoryManager:

TaskMemoryManager负责管来一个Task的内存申请和释放,申请和释放内存的功能又依赖于上面的MemoryManager。

一个Task里面有很多地方需要使用到内存，它们都依赖TaskMemoryManager申请内存，被称为MemoryConcumer。申请和释放内存又分了使用Tungsten和非Tungsten模式。暂时先不看它申请和释放内存的方法，等到后面分析Shuffle或者其他API时自然会看到，本人大概就是瞄了一眼,重点了解下Tungsten模式。

Tungsten介绍：

Tungsten是Spark为了提升JVM带来的性能限制而提出的一个优化计划，主要是考虑如下两个因素：

Java对象所占的内存空间大，不像C/C++等更加底层的语言
JVM的GC机制在回收大空间时开销大

Tungsten优化体现在三个方面：

内存管理与二进制处理(Memory Management and Binary Processing):不处理Java对象的数据，而是直接处理二进制的数据，并引入了类似OS中的Page，提升性能。(堆外内存)
缓存敏感计算(Cache-aware computation): 设计算法和数据结构以充分利用memory hierarchy
动态代码生成(Code generation): 使用code generation去充分利用最新的编译器和CPU的性能

本文主要介绍第一点，后面那两点我也还没细看。

Page结构如下：