【大数据】Flink 内存管理(二):JobManager 内存分配(含实际计算案例)

2024-02-25 15:04

本文主要是介绍【大数据】Flink 内存管理(二):JobManager 内存分配(含实际计算案例),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Flink 内存管理》系列(已完结),共包含以下 4 篇文章:

  • Flink 内存管理(一):设置 Flink 进程内存
  • Flink 内存管理(二):JobManager 内存分配(含实际计算案例)
  • Flink 内存管理(三):TaskManager 内存分配(理论篇)
  • Flink 内存管理(四):TaskManager 内存分配(实战篇)

😊 如果您觉得这篇文章有用 ✔️ 的话,请给博主一个一键三连 🚀🚀🚀 吧 (点赞 🧡、关注 💛、收藏 💚)!!!您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容!!!

Flink 内存管理(二):JobManager 内存分配

  • 1.分配 Total Process Size
  • 2.分配 Total Flink Size
  • 3.单独分配 Heap Size
  • 4.分配 Total Process Size 和 Heap Size
  • 5.分配 Total Flink Size 和 Heap Size

JobManager 是 Flink 集群的控制元素。它由三个不同的组件组成: 资源管理器(Resource Manager)、调度器(Dispatcher)和每个运行中的 Flink 作业的一个作业管理器(JobMaster)。

JobManager 的内存模型如下:
在这里插入图片描述
以上 Total Process Memory 的模型图可以分为以下的 4 个内存组件,如果在分配内存的时候,显示的指定了组件其中的 1 1 1 个或者多个,那么 JVM Overhead 的值就是在其它组件确定的情况下,用 Total Process Size - 其它获取的值,必须在 min - max 之间,如果没有指定组件的值,那么就按照 0.1 0.1 0.1 的比例进行计算得到,如果计算出的值小于 minmin,如果大于 maxmax,如果 minmax 指定的相等,那么这个 JVM Overhead 就是一个确定的值!

内存组件
配置选项
内存组件的功能
JVM Heapjobmanager.memory.heap.sizeJobManager 的 JVM 堆内存大小。这个大小取决于提交的作业个数和作业的结构以及用户代码的要求。主要用来运行 Flink 框架,执行作业提交时的用户代码以及 Checkpoint 的回调代码。
Off-Heap Memoryjobmanager.memory.off-heap.sizeJM 的对外内存的大小。涵盖了所有 Direct 和 Native 的内存分配。用来执行 akka 等外部依赖,同时也负责运行 Checkpoint 回调及作业提交时的用户代码,有默认值 128 M 128M 128M
JVM Metaspacejobmanager.memory.jvm-metaspace.sizeJM 的元空间大小,有默认值 256 M 256M 256M, 属于 Native Memory。
JVM Overheadjobmanager.memory.jvm-overhead.min jobmanager.memory.jvm-overhead.max jobmanager.memory.jvm-overhead.fractionJVM 额外开销。为 Thread Stacks,Code Cache,Garbage Collection Space 预留的 Native Memory,有默认的 faction of total process size,但是必须在其 min & max 之间。

在 《Flink 内存管理(一):设置 Flink 进程内存》中我们提到,必须使用下述三种方法之一配置 Flink 的内存(本地执行除外),否则 Flink 启动将失败。这意味着必须明确配置以下选项子集之一,这些子集没有默认值。

序号for TaskManagerfor JobManager
1️⃣taskmanager.memory.flink.sizejobmanager.memory.flink.size
2️⃣taskmanager.memory.process.sizejobmanager.memory.process.size
3️⃣taskmanager.memory.task.heap.sizetaskmanager.memory.managed.sizejobmanager.memory.heap.size

1.分配 Total Process Size

  • jobmanager.memory.process.size

在这里插入图片描述
在这里插入图片描述

此时我们只显示指定了 jobmanager.memory.process.size 的值,没有指定其它组件,此时整个 JobManager 的 JVM 进程能占用的内存为 2000 M 2000M 2000M

  • Total Process Size = 2000 M = 2000M =2000M(这是分配的基准值)
  • JVM Overhead 因为没有指定其它组件内存,所以被按照 0.1 0.1 0.1 的比例推断成: 2000 M × 0.1 × 1024 × 1024 = 209715203 B = 200 M 2000M × 0.1 × 1024 × 1024 = 209715203B = 200M 2000M×0.1×1024×1024=209715203B=200M
  • JVM Metaspace 默认值为 256 M 256M 256M
  • Off-Heap Memeory 默认值为 128 M 128M 128M
  • JVM Heap 最终被推断为 2000 M − 200 M − 256 M − 128 M = 1.38 G 2000M - 200M - 256M - 128M = 1.38G 2000M200M256M128M=1.38G

为啥 JVM Heap 只有 1.33 G B 1.33GB 1.33GB 而不是 1.38 G B 1.38GB 1.38GB 呢?

在这里插入图片描述
其实这个取决于你使用的 GC 算法会占用其中很小一部分固定内存作为 Non-Heap,该占用部分大小为: 1.38 − 1.33 = 0.05 G B 1.38-1.33 = 0.05GB 1.381.33=0.05GB

2.分配 Total Flink Size

  • jobmanager.memory.flink.size

在这里插入图片描述
在这里插入图片描述

此时我们只显示指定了 jobmanager.memory.flink.size 的值,也没有指定其它组件如 Heap Size,此时整个 JobManager 的 JVM 进程除了 JVM OverheadJVM Metaspace 之外能占用的内存为 2000 M 2000M 2000M

  • Total Flink Size = 2000 M = 1.95 G = 2000M = 1.95G =2000M=1.95G(这属于 Total Process Size 的组件之一,Overhead 只能最后按剩余的内存来被推断)
  • JVM Metaspace 默认值为 256 M 256M 256M(固定默认值)
  • Off-Heap Memeory 默认值为 128 M 128M 128M(固定默认值)
  • JVM Heap = 2000 M − 128 M − 80 M B ( G C 算法占用) = 1.75 G B = 2000M - 128M - 80MB(GC算法占用)= 1.75GB =2000M128M80MBGC算法占用)=1.75GB
  • 根据 JVM Overhead = = =(JVM Overhead + Metaspace 256 M 256M 256M + Flink Size 2000 M ) × 0.1 2000 M) ×\ 0.1 2000M)× 0.1,计算可得:
    • Total Process Size = 2.448 G B = 2.448GB =2.448GB
    • JVM Overhead = 2.448 G B × 0.1 = 262843055 B = 250.667 M B = 2.448GB × 0.1 = 262843055B = 250.667MB =2.448GB×0.1=262843055B=250.667MB,在 192 M ~ 1 G B 192M~1GB 192M1GB,为有效

最终资源的分配如以下日志所示:

在这里插入图片描述

3.单独分配 Heap Size

  • jobmanager.memory.heap.size

在这里插入图片描述
在这里插入图片描述

此时我们只显示指定了 jobmanager.memory.heap.size 的值,相当于显示配置了组件的值,此时整个 JobManager 的 JVM Heap 被指定为最大内存为 1000 M 1000M 1000M

  • JVM Heap 被指定为 1000 M 1000M 1000M,但是得从 GC 算法中扣除 41 M B 41MB 41MB,实际 JVM Heap = 959 M B = 959MB =959MB
  • JVM Metaspace 默认值为 256 M 256M 256M
  • Off-Heap Memeory 默认值为 128 M 128M 128M
  • Total Flink Size = 1128 M B = 1.102 G B = 1128MB = 1.102GB =1128MB=1.102GB
  • JVM Overhead = ( 1128 M B + 256 M + = (1128MB + 256M + =(1128MB+256M+ JVM Overhead ) × 0.1 ) × 0.1 )×0.1
    • JVM Overhead = 153.778 < 192 M B = 153.778 < 192MB =153.778<192MB(默认的 min),所以 JVM Overhead = 192 M B = 192MB =192MB
  • Total Process Size = 1128 M B + 256 M + = 1128MB + 256M + =1128MB+256M+ JVM Overhead = 1576 M B = 1.5390625 G B = 1.539 G B = 1576MB = 1.5390625GB = 1.539GB =1576MB=1.5390625GB=1.539GB

在这里插入图片描述

4.分配 Total Process Size 和 Heap Size

在这里插入图片描述
在这里插入图片描述
由于指定了 heap.size 内存组件的的大小,那么 JVM Overhead 就是取剩余的 Total Process Size 的内存空间。

  • Total Process Size = 2000 M B = 2000MB =2000MB && JVM Heap = 1000 M B = 1000MB =1000MB,实际只有 959 M B 959MB 959MB,因为减去了 41 M B 41MB 41MB 的 GC 算法占用空间
  • JVM Metaspace 默认值为 256 M 256M 256M
  • Off-Heap Memeory 默认值为 128 M 128M 128M
  • Total Flink Size = 1000 M B + 128 M B = 1128 M B = 1000MB + 128MB = 1128MB =1000MB+128MB=1128MB
  • JVM Overhead = 2000 M B − 1128 M B − 256 M B = 616 M B = 2000MB - 1128MB - 256MB = 616MB =2000MB1128MB256MB=616MB

在这里插入图片描述

5.分配 Total Flink Size 和 Heap Size

在这里插入图片描述
在这里插入图片描述

由于指定了 head.size 组件的大小,那么 Overhead 就按照剩余 Total Process Size 的内存空间分配。

  • Total Flink Size = 2000 M B = 2000MB =2000MB && JVM Heap = 1000 M B = 1000MB =1000MB,实际 959 M B 959MB 959MB,减去了 GC 算法的占用空间
  • JVM Off-Heap = 2000 M B − 1000 M B = 1000 M B = 2000MB - 1000MB = 1000MB =2000MB1000MB=1000MB
  • JVM Metaspace = 256 M B = 256MB =256MB
  • 首先根据 JVM Overhead = ( = ( =(JVM Overhead + + + Metaspace 256 M 256M 256M + + + Flink Size 2000 M ) × 0.1 2000M) × 0.1 2000M)×0.1
    • Total Process Size = 2.448 G B = 2.448GB =2.448GB
    • JVM Overhead = 2.448 G B × 0.1 = 262843055 B = 250.667 M B = 2.448GB × 0.1 = 262843055B = 250.667MB =2.448GB×0.1=262843055B=250.667MB,在 192 M ~ 1 G B 192M~1GB 192M1GB,为有效
  • 最终确定 Total Process Size = 2.448 G B = 2.448GB =2.448GB && JVM Overhead = 250.667 M B = 250.667MB =250.667MB

在这里插入图片描述

这篇关于【大数据】Flink 内存管理(二):JobManager 内存分配(含实际计算案例)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/745846

相关文章

Python获取中国节假日数据记录入JSON文件

《Python获取中国节假日数据记录入JSON文件》项目系统内置的日历应用为了提升用户体验,特别设置了在调休日期显示“休”的UI图标功能,那么问题是这些调休数据从哪里来呢?我尝试一种更为智能的方法:P... 目录节假日数据获取存入jsON文件节假日数据读取封装完整代码项目系统内置的日历应用为了提升用户体验,

springboot循环依赖问题案例代码及解决办法

《springboot循环依赖问题案例代码及解决办法》在SpringBoot中,如果两个或多个Bean之间存在循环依赖(即BeanA依赖BeanB,而BeanB又依赖BeanA),会导致Spring的... 目录1. 什么是循环依赖?2. 循环依赖的场景案例3. 解决循环依赖的常见方法方法 1:使用 @La

Java利用JSONPath操作JSON数据的技术指南

《Java利用JSONPath操作JSON数据的技术指南》JSONPath是一种强大的工具,用于查询和操作JSON数据,类似于SQL的语法,它为处理复杂的JSON数据结构提供了简单且高效... 目录1、简述2、什么是 jsONPath?3、Java 示例3.1 基本查询3.2 过滤查询3.3 递归搜索3.4

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景:内存吃得满满的类__slots__:你的内存管理小助手举个大概的例子:看看效果如何?1.

MySQL大表数据的分区与分库分表的实现

《MySQL大表数据的分区与分库分表的实现》数据库的分区和分库分表是两种常用的技术方案,本文主要介绍了MySQL大表数据的分区与分库分表的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有... 目录1. mysql大表数据的分区1.1 什么是分区?1.2 分区的类型1.3 分区的优点1.4 分

Mysql删除几亿条数据表中的部分数据的方法实现

《Mysql删除几亿条数据表中的部分数据的方法实现》在MySQL中删除一个大表中的数据时,需要特别注意操作的性能和对系统的影响,本文主要介绍了Mysql删除几亿条数据表中的部分数据的方法实现,具有一定... 目录1、需求2、方案1. 使用 DELETE 语句分批删除2. 使用 INPLACE ALTER T

Python Dash框架在数据可视化仪表板中的应用与实践记录

《PythonDash框架在数据可视化仪表板中的应用与实践记录》Python的PlotlyDash库提供了一种简便且强大的方式来构建和展示互动式数据仪表板,本篇文章将深入探讨如何使用Dash设计一... 目录python Dash框架在数据可视化仪表板中的应用与实践1. 什么是Plotly Dash?1.1

Redis 中的热点键和数据倾斜示例详解

《Redis中的热点键和数据倾斜示例详解》热点键是指在Redis中被频繁访问的特定键,这些键由于其高访问频率,可能导致Redis服务器的性能问题,尤其是在高并发场景下,本文给大家介绍Redis中的热... 目录Redis 中的热点键和数据倾斜热点键(Hot Key)定义特点应对策略示例数据倾斜(Data S

Python实现将MySQL中所有表的数据都导出为CSV文件并压缩

《Python实现将MySQL中所有表的数据都导出为CSV文件并压缩》这篇文章主要为大家详细介绍了如何使用Python将MySQL数据库中所有表的数据都导出为CSV文件到一个目录,并压缩为zip文件到... python将mysql数据库中所有表的数据都导出为CSV文件到一个目录,并压缩为zip文件到另一个

SpringBoot整合jasypt实现重要数据加密

《SpringBoot整合jasypt实现重要数据加密》Jasypt是一个专注于简化Java加密操作的开源工具,:本文主要介绍详细介绍了如何使用jasypt实现重要数据加密,感兴趣的小伙伴可... 目录jasypt简介 jasypt的优点SpringBoot使用jasypt创建mapper接口配置文件加密