Flink1.12-之JobManagerTaskManager内存管理

2023-12-10 13:33
文章标签 内存 管理 flink1.12 jobmanagertaskmanager

本文主要是介绍Flink1.12-之JobManagerTaskManager内存管理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Flink1.12-之内存管理

1、前言

flink为了让用户更好的调整内存分配，达到资源的合理分配，在Fllink1.10引入了TaskManager的内存管理，后续在Flink1.11版本引入了JobManager的内存管理，用户可以通过配置的方式合理的分配资源。

不管是TaskManager还是JobManager都是单独的JVM进程，他们共用一套内存模型抽象（TaskManager的内存模型更加复杂），如下。
在这里插入图片描述

该模型由heap和off-heap内存组成，这里有以下3种调整内存的方式，3种方式必须选一种，不然会启动失败，最好不要同时指定2种方式，否则有可能会产生配置冲突。

for TaskManager:for JobManager:
taskmanager.memory.flink.sizejobmanager.memory.flink.size
taskmanager.memory.process.sizejobmanager.memory.process.size
taskmanager.memory.task.heap.size and taskmanager.memory.managed.sizejobmanager.memory.heap.size

  • 直接调整jobmanager.memory.process.size或者taskmanager.memory.process.size的方式

    • 该方式是最简单的方式，该配置下的所有的组件的内存分配都会有默认值，或者通过推导得到，通常在yarn或者k8s、mesos的时候这样指定，container部署通过该参数的配置来申请容器的大小。

  • 直接调整jobmanager.memory.flink.size或者taskmanager.memory.flink.size的方式

    • 这种方式通常在standalone的时候使用的比较多，其它组件的

  • 第三种是直接配置heap和off-heap组件的大小，达到更细粒度的控制,或者配合前2种方式中的其中之一使用也是可以的。

以上三种方式任选一种～！！

2、JobManager内存分配

JobManager的内存模型如下.

在这里插入图片描述

以上total process size的模型图可以分为以下的4个内存组件,如果在分配内存的时候，显示的指定了组件其中的1个或者多个，那么JVM overhead的值就是在其它组件确定的情况下，用total process size - 其它 获取的值，必须在min～max之间,如果没有指定组件的值，那么就按照0.1的fraction进行计算得到，如果计算出的值小于min取min，如果大于max取max，如果min、max指定的相等，那么这个JVM overhead就是一个确定的值！

内存组件配置选项内存组件的功能
JVM Heapjobmanager.memory.heap.size这个大小取决于提交的作业个数和作业的结构以及用户代码的要求。=>>>> 主要用来运行flink框架，执行作业提交时的用户代码以及checkpoint的回调代码
Off-heap Memoryjobmanager.memory.off-heap.size（默认128M）JM的对外内存的大小. 涵盖了所有direct和native的内存分配。=>>>>用来执行akka等外部依赖，同时也负责运行checkpoint回调及作业提交时的用户代码
JVM metaspacejobmanager.memory.jvm-metaspace.size（默认256M）JM的元空间大小，有默认值jobmanager.memory.jvm-metaspace.size = 256M， 属于native memory
JVM Overheadjobmanager.memory.jvm-overhead.min （192M）jobmanager.memory.jvm-overhead.max （1G）jobmanager.memory.jvm-overhead.fraction（0.1）为thread stacks, code cache, garbage collection space预留的native memory，有默认的faction of total process size，但是必须在其min & max之间

2.1、分配 total process size

  • jobmanager.memory.process.size

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

# 此时我们只显示指定了 jobmanager.memory.process.size 的值，没有指定其它组件，此时整个JobManager的JVM进程能占用的内存为2000M
0、total process size = 2000M(这是分配的基准值)
1、JVM overhead 因为没有指定其它组件内存，所以被按照0.1的fraction推断成 => 2000M * 0.1 * 1024 * 1024 = 209715203B（200M）
2、JVM Metaspace 默认值为 256M
3、Off-Heap Memeory 默认为 128M
4、JVM Heap最终被推断为 2000M - 200M - 256M - 128M = 1.38G（？？？？？？？？？？？？？）

√ 为啥JVM Heap只有1.33GB而不是1.38GB呢？

在这里插入图片描述

其实这个取决于你使用的GC算法会占用其中很小一部分固定内存作为Non-heap，该占用部分大小为：1.38-1.33 = 0.05GB。

2.2、分配 total flink size

  • jobmanager.memory.flink.size

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

# 此时我们只显示指定了 jobmanager.memory.flink.size 的值，也没有指定其它组件如heap size，此时整个JobManager的JVM进程除了JVM Overhead及JVM Metaspace之外能占用的内存为2000M
0、total flink size = 2000M = 1.95G（这属于total process size的组件之一，overhead只能最后按剩余的内存来被推断）
1、JVM Metaspace 默认值为 256M（固定默认值）
2、Off-Heap Memeory 默认值为 128M（固定默认值）
3、JVM heap = 2000M - 128M = 1.828GB - 80MB(GC算法占用) = 1.75GB
4、根据JVM overhead  = (JVM overhead + 256M(Metaspace) + 2000(flink size)) * 0.1  
=> total process size =  2.448GB
=> JVM overhead = 2.448GB * 0.1 =  262843055B =  250.667MB(在192M～1GB)，为有效
5、最终资源的分配如以上日志所示～～

2.3、单独分配 heap size

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

# 此时我们只显示指定了 jobmanager.memory.heap.size 的值，相当于显示配置了组件的值，此时整个JobManager的JVM Heap被指定为最大内存为1000M
0、Jvm heap被指定为 1000M，但是得从GC算法中扣除 41MB(GC算法占用) => JVM heap(实际) = 959MB
1、JVM Metaspace 默认值为 256M
2、Off-Heap Memeory 默认值为 128M
3、flink total size = 1128MB = 1.102GB
4、（1128MB + 256M + JVM overhead）* 0.1 = JVM overhead => JVM = 153.778 < 192MB(默认的min) => JVM overhead = 192MB
5、total process size = 1128MB + 256M + JVM overhead = 1576MB = 1.5390625GB = 1.539GB

2.4、分配process size和 heap size

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

# 由于指定了heap.size内存组件的的大小，那么JVM overhead就是取剩余的total process size的内存空间
0、total process size = 2000MB && JVM heap = 1000MB,实际只有959MB，因为减去了41MB的GC算法占用空间
1、JVM Metaspace 默认值为 256M
2、Off-Heap Memeory 默认值为 128M
3、total flink size = 1000MB + 128MB = 1128MB
4、JVM overhead = 2000MB - 1128MB - 256MB = 616MB

2.5、分配flink size和 heap size

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

# 由于指定了head.size组件的大小，那么overhead就按照剩余total process size的内存空间分配
0、total flink size = 2000MB && JVM heap = 1000MB，实际959MB，减去了GC算法的占用空间
1、JVM off-heap = 2000MB - 1000MB = 1000MB
2、JVM Metaspace = 256MB
3、首先根据JVM overhead  = (JVM overhead + 256M(Metaspace) + 2000(flink size)) * 0.1  
=> total process size =  2.448GB
=> JVM overhead = 2.448GB * 0.1 =  262843055B =  250.667MB(在192M～1GB)，为有效
4、最终确定 total process size = 2.448GB && JVM overhead = 250.667MB

3、TaskManager的内存分配

TaskManager是计算用户任务的节点，他比JobManager的模型更加复杂和精细，合理的分配内存可以使应用更加稳定，TaskManager的细粒度内存模型如下。

在这里插入图片描述

其中包含的组件如下表

组件配置选项描述
Framework Heap Memorytaskmanager.memory.framework.heap.size（默认128M）专用于运行Flink框架，通常不用修改该值,它可能与特定的部署环境或作业结构有关，例如高并行度.
Task Heap Memorytaskmanager.memory.task.heap.size专用于用户提交作业划分的Tasks
Managed memorytaskmanager.memory.managed.size taskmanager.memory.managed.fraction（默认0.4）这是一块被Flink管理的堆外内存，属于Native Memory, 用于批处理作业的排序，hash运算，缓存中间结果，以及RocksDB状态后端的元数据
Framework Off-heap Memorytaskmanager.memory.framework.off-heap.size（默认128M）专用于运行Flink框架，通常不用修改该值,它可能与特定的部署环境或作业结构有关，例如高并行度.
Task Off-heap Memorytaskmanager.memory.task.off-heap.size（默认0Byte）专用于用户提交作业划分的Tasks，不受GC的影响
Network Memorytaskmanager.memory.network.min （默认64MB）taskmanager.memory.network.max （默认1GB）taskmanager.memory.network.fraction（默认0.1）为Task之间的数据交换预留的内存，比如说网络缓冲区，默认是total flink size的0.1,通常不需要去调整这个值
JVM metaspacetaskmanager.memory.jvm-metaspace.size（默认256M）JM的元空间大小，有默认值256M， 属于native memory
JVM Overheadtaskmanager.memory.jvm-overhead.min （192MB）taskmanager.memory.jvm-overhead.max （1GB）taskmanager.memory.jvm-overhead.fraction（0.1）为thread stacks, code cache, garbage collection space预留的native memory，有默认的faction of total process size，但是必须在其min & max之间

3.1、单独分配total process size

# 单独分配total process size，其它的组件都会自动分配
taskmanager.memory.process.size: 2000m

在这里插入图片描述

在这里插入图片描述

# 内存分配步骤如下
# 1
1、首先 total process size = 2000M
# 2 native memory = 【456M】
2、因为没有显示分配组件中的任何参数，所以 JVM overhead = 200M
3、JVM MetaSpace = 默认256M
# 3
4、total flink size = 2000M - 200M - 256M = 1544MB = 1.508GB# 4 total direct memory = 154.4M + 0 + 128M = 【282.4M】
5、network memory = 1544 * 0.1 = 154.4M
6、Task offheap = 默认0MB
7、FrameWork Off-heap = 默认128M# 5 managed memeory = 【617.6M】
8、Managed Memory = 1544MB * 0.4 = 617.6M# 6 total JVM heap memory = 1544M - 282.4M - 617.6M = 644MB
9、FrameWork Heap = 128M
10、Task Heap = 644M - 128M = 516M# 7 与以上的日志进行对比，完全能对上，okay！！

3.2、单独分配total flink size

# 单独分配 total flink size 
taskmanager.memory.flink.size: 2000m

在这里插入图片描述

# 假如直接只分配 taskmanager.memory.flink.size: 2000m，没有设计以上表格中的组件# 1 total flink size = 【2000M】
total flink size = 2000M# 2 managed memory 
Managed Memory = 2000M * 0.4 = 800M
# 3 total direct memory = 200M + 128M = 328M
NetWork Memory = 2000M * 0.1 = 200M
FrameWork Off-Heap = 128M
Task Off-Heap = 0Byte = 0M
# 4 total off heap = 800M + 328M = 【1128M】# 5 total JVM heap = 【872M】
total jvm heap = 2000M - 800M - 328M = 872M 
FrameWork heap = 128M 
Task Heap = 872M - 128M = 744M# 6 native memory 
JVM MetaSpace = 默认 256M
JVM overhead = （JVM overhead + 256M(Metaspace)+ 2000M(total flink size)）* 0.1=> JVM overhead = 250.667M 在[192MB~1GB]，生效# 7 total process size 
total process size = 2000M + 256 + 250.667 = 2506.667M = 2.448GB

3.3、单独分配 heap size && managed memory

# 单独分配组件JVM heap 和 mamaged memory
taskmanager.memory.task.heap.size: 1000m
taskmanager.memory.managed.size: 1000m

在这里插入图片描述

# total JVM heap = 【1128M】 = 【1.102 GB】
FrameWork heap = 128M（默认）
Task Heap = 1000M# total off-heap = 【1378.667M】
# managed memory
Managed Memory = 1000M
# total direct memory = 378.667M
FrameWork off-heap = 128M
Task off-heap = 0M
NetWork = (NetWork + 1128M + 1000M + 128M + 0M ) * 0.1   =>  NetWork = 250.667MB 处于[64MB ～ 1GB]
=> total direct memory = 128M + 250.667M = 378.667M# total flink size = 【2506.667M】
total flink size = 1128M + 1378.667M  = 2506.667M = 2.448GB# native memory
JVM Metaspace = 256M
JVM overhead = （JVM overhead + 1128M + 1000M + 378.667M + 256M）* 0.1 = 306.963M 处于[192M ～ 1GB]，生效# total process size = 【3069.63M】= 【2.998G】
total process size = 2506.667M + 256M + 306.963M = 3069.63M = 2.998G

3.4、分配 total process size 和 heap size && managed memory

# 指定total process size，同时显式分配组件JVM heap 和 mamaged memory
taskmanager.memory.process.size: 3000m
taskmanager.memory.task.heap.size: 1000m
taskmanager.memory.managed.size: 1000m

在这里插入图片描述

# 1 total process size = 【3000M】# 2 total flink size = 【1128M + 1378.667M】=【2506.667M】=【2.448GB】# 3 total JVM heap = 【1128M】= 【1.102M】
FrameWork heap = 128M
Task heap = 1000M # 4 total off-heap = 【1000M + 128M + 250.667M】= 【1378.667M】 = 【1.346GB】
# managed memory
managed memory = 1000M
# direct memory
FrameWork off-heap = 128M
Task off-heap = 0M
NetWork memory = (NetWork memory + 1128M + 1128M) * 0.1 = 250.667M 在[64M ～ 1GB]之间，满足要求# native memory
JVM Metaspace = 256M
JVM overhead = 3000M - 2506.667M - 256M = 237.333M 在[192M ～ 1GB]之间，满足要求

3.5、分配 total flink size 和 heap size && managed memory

# 指定total flink size，同时显式分配组件JVM heap 和 mamaged memory
taskmanager.memory.flink.size: 3000m
taskmanager.memory.task.heap.size: 1000m
taskmanager.memory.managed.size: 1000m

在这里插入图片描述

# 1 已知
total flink size = 3000M = 2.93GB
managed memory = 1000M
Task heap = 1000M# total JVM heap = 【1128M】
Task heap = 1000M
Frame heap = 128M# total off-heap = 【3000M - 1128M】 = 【1872M】 = 【1.828GB】
# managed memory = 1000M
# direct memory = 1872M - 1000M = 872M
Task off-heap = 0M
Frame off-heap = 128M
network memory = 872M - 128M = 744M # native memory 
JVM Metaspace = 256M
JVM overhead = (JVM overhead + 3000M + 256M) * 0.1 = 361.778M 处于[min192M ～  max1G]之间 符合条件# total process size = 【3617.778M】= 【3.533GB】
3000M + 256M + 361.778M. = 3617.778M = 3.533GB

4、内存分配汇总

在Flink的集群内存分配的过程中，我们大致可以通过3种方式进行分配

  • 指定 total process size ｜｜ total flink size 取决于你用什么方式部署

  • 单独指定某个组件比如Task-heap的大小，其它的组件都会被推导出来

  • 指定 total size && heap or off-heap其中之一，其它的组件通过默认值进行填充或者进推导

    • 如total flink size = total heap size + total off-heap size

    • total heap size = task heap + frame heap

    • total off-heap = task off-heap + frame off-heap + network memory

    • network = 0.1* total flink size（没有指定其它组件情况下）

    • JVM overhead = 0.1 * total process size (没有指定其它组件情况下)

    • …其它

这篇关于Flink1.12-之JobManagerTaskManager内存管理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/477247。

相关文章

NameNode内存生产配置

NameNode内存生产配置

Hadoop2.x 系列，配置 NameNode 内存 NameNode 内存默认 2000m ，如果服务器内存 4G ， NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列，配置 Nam
阅读更多...
综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

LntonAIServer视频质量诊断功能中的抖动检测是一个专门针对视频稳定性进行分析的功能。抖动通常是指视频帧之间的不必要运动，这种运动可能是由于摄像机的移动、传输中的错误或编解码问题导致的。抖动检测对于确保视频内容的平滑性和观看体验至关重要。 优势 1. 提高图像质量 - 清晰度提升：减少抖动，提高图像的清晰度和细节表现力，使得监控画面更加真实可信。 - 细节增强：在低光条件下，抖
阅读更多...
软考系统规划与管理师考试证书含金量高吗？

软考系统规划与管理师考试证书含金量高吗？

2024年软考系统规划与管理师考试报名时间节点： 报名时间：2024年上半年软考将于3月中旬陆续开始报名 考试时间：上半年5月25日到28日，下半年11月9日到12日 分数线：所有科目成绩均须达到45分以上（包括45分）方可通过考试 成绩查询：可在“中国计算机技术职业资格网”上查询软考成绩 出成绩时间：预计在11月左右 证书领取时间：一般在考试成绩公布后3~4个月，各地领取时间有所不同
阅读更多...
安全管理体系化的智慧油站开源了。

安全管理体系化的智慧油站开源了。

AI视频监控平台简介 AI视频监控平台是一款功能强大且简单易用的实时算法视频监控系统。它的愿景是最底层打通各大芯片厂商相互间的壁垒，省去繁琐重复的适配流程，实现芯片、算法、应用的全流程组合，从而大大减少企业级应用约95%的开发成本。用户只需在界面上进行简单的操作，就可以实现全视频的接入及布控。摄像头管理模块用于多种终端设备、智能设备的接入及管理。平台支持包括摄像头等终端感知设备接入，为整个平台提
阅读更多...
从状态管理到性能优化：全面解析 Android Compose

从状态管理到性能优化：全面解析 Android Compose

文章目录 引言一、Android Compose基本概念1.1 什么是Android Compose?1.2 Compose的优势1.3 如何在项目中使用Compose 二、Compose中的状态管理2.1 状态管理的重要性2.2 Compose中的状态和数据流2.3 使用State和MutableState处理状态2.4 通过ViewModel进行状态管理 三、Compose中的列表和滚动
阅读更多...
Sentinel 高可用流量管理框架

Sentinel 高可用流量管理框架

Sentinel 是面向分布式服务架构的高可用流量防护组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。 Sentinel 具有以下特性: 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应
阅读更多...
JVM内存调优原则及几种JVM内存调优方法

JVM内存调优原则及几种JVM内存调优方法

JVM内存调优原则及几种JVM内存调优方法 1、堆大小设置。 2、回收器选择。 　　1、在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存，这个数值不能准确的反应堆内存的真实占用情况，因为GC过后这个值是不会变化的，因此内存调优的时候要更多地使用JDK提供的内存查看工具，比如JConsole和Java VisualVM。 　　2、对JVM内存的系统级的调优主要的目的是减少
阅读更多...
JVM 常见异常及内存诊断

JVM 常见异常及内存诊断

栈内存溢出 栈内存大小设置：-Xss size 默认除了window以外的所有操作系统默认情况大小为 1MB，window 的默认大小依赖于虚拟机内存。 栈帧过多导致栈内存溢出 下述示例代码，由于递归深度没有限制且没有设置出口，每次方法的调用都会产生一个栈帧导致了创建的栈帧过多，而导致内存溢出(StackOverflowError)。 示例代码： 运行结果： 栈帧过大导致栈内存
阅读更多...
理解java虚拟机内存收集

理解java虚拟机内存收集

学习《深入理解Java虚拟机》时个人的理解笔记 1、为什么要去了解垃圾收集和内存回收技术？ 当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术实施必要的监控和调节。 2、“哲学三问”内存收集 what？when？how？ 那些内存需要回收？什么时候回收？如何回收？ 这是一个整体的问题，确定了什么状态的内存可以
阅读更多...
NGINX轻松管理10万长连接 --- 基于2GB内存的CentOS 6.5 x86-64

NGINX轻松管理10万长连接 --- 基于2GB内存的CentOS 6.5 x86-64

转自：http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=190176&id=4234854 一 前言 当管理大量连接时，特别是只有少量活跃连接，NGINX有比较好的CPU和RAM利用率，如今是多终端保持在线的时代，更能让NGINX发挥这个优点。本文做一个简单测试，NGINX在一个普通PC虚拟机上维护100k的HTTP
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2