flink内存模型

小路遥同学

已于 2024-07-12 15:21:38 修改

阅读量5k

点赞数 1

分类专栏： java 文章标签： java flink

于 2022-03-31 16:33:19 首次发布

本文链接：https://blog.youkuaiyun.com/weixin_43691132/article/details/123812201

版权

jvm中java对象模型缺陷

基于 JVM 的数据分析引擎都需要面对将大量数据存到内存中,当然也包括flink，这就不得不面对JVM内存管理存在的几个问题：
1.有效数据密度低
java对象由三部分构成，对齐填充仅起到占位符的作用，例如：一个只包含 boolean 属性的对象占用了16个字节内存：对象头占了8个，boolean 属性占了1个，对齐填充占了7个。而实际上只需要一个bit（1/8字节）就够了。
在这里插入图片描述

2.垃圾回收机制
JVM的内存回收机制，优点是开发者无需关心资源回收，但是由于自主回收是不可控的，在大数据场景下，这个缺点被放大，海量数据导致空间不足，可能出现秒级甚至分钟级的Full GC，不仅影响效率，其引起的中断可能导致心跳超时被踢出集群。（所以需要JVM参数调优提升回收效率，减少FullGC）

3.OOM问题
当执行Full GC后空间仍然不足，则抛出OOM导致JVM崩溃，影响分布式框架的健壮性和性能

4.缓存未命中问题
从 L1/L2/L3 缓存读取数据的速度比从主内存读取数据的速度快好几个量级。通过性能分析可以发现，CPU时间中的很大一部分都是浪费在等待数据从主内存过来上。如果这些数据可以从 L1/L2/L3 缓存过来，那么这些等待时间可以极大地降低。
CPU将经常访问的数据及其下一步可能访问的附近的数据搬运到缓存中，以便下次访问，但由于java对象在堆中不连续（java中，为了提高效率，是按照8byte的整数倍进行存储的，所以不连续），所以搬运的附近数据往往不是下一步计算需要的，这就是缓存未命中，导致执行效率降低。
在这里插入图片描述

flink自主管理内存来解决jvm的几个问题

所以目前，越来越多的大数据项目开始自己管理JVM内存了，像 Spark、Flink、HBase，为的就是获得像 C 一样的性能以及避免 OOM 的发生。

早期flink内存模型

在flink中，使用固定长度的内存块（默认32KB）来管理java对象（而不是将存对象在堆上），即memorySegment，它是flink中内存分配的最小单元。一个java对象序列化为二进制数据流后可能占用1个或多个memorySegment。flink给这样的内存块提供了非常高效的读写方法，部分运算可以直接操作二进制数据，不需要反序列化即可执行（它的 DBMS 风格的sort和join算法尽可能多地对这个二进制数据进行操作，以此将序列化和反序列化开销降到最低，这部分内容暂时不详述）。
在这里插入图片描述

早期时候flink还未使用堆外内存，memorySegement的都是放在堆上的，基于这样的内存管理模式可以改善jvm的部分问题：

针对有效数据密度低的问题：
因为只存储实际数据的二进制内容，避免了对齐填充等占位符，节省了内存空间。
针对Full GC的问题：
从GC的角度讲，数据以二进制的形式存在memorySegment中一直呆在老年代不会被GC回收，而其他的数据对象基本上是由用户代码生成的短生命周期对象，这部分内存可以看成新生代，可以被Minor GC快速回收，让对象尽量在minor GC时被回收不要进入老年代，老年代空间充足的话就可以降低发生Full GC的概率
针对OOM的问题：
分配的内存段的数量是固定的，因此监控剩余的内存资源是非常简单的，在内存吃紧的情况下，算法(sort/join等)会高效地将一大批内存块写到磁盘，之后再读回来，防止OOM。
针对缓存未命中的问题：
该二进制形式数据把将算法中需要操作的数据（如sort中的key）连续存储，容易被缓存到L1/L2/L3中，可以减少CPU等待的时间，获得性能的提升。