flink-user-zh mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zhisheng <zhisheng2...@gmail.com>
Subject Re: Flink 内存类型相关疑问
Date Tue, 10 Mar 2020 03:39:46 GMT
hi, xintong

刚才我在 YARN 上分别测试了四种情况,第一种是默认不修改内存的配置,直接运行作业(Per
Job
模式,下面的都是这种模式),作业能够启动起来,能正常运行,内存分配是
Flink 自己分配的;

第二种情况是配置文件指定 taskmanager.memory.managed.size
和 taskmanager.memory.task.heap.size 参数的大小,分别是 1024m 和 256m,作业也能够正常启动运行,截图如下:

http://zhisheng-blog.oss-cn-hangzhou.aliyuncs.com/2020-03-10-031628.png

第三种情况是启动的时候通过参数(-ytm 4096m)指定 TM
整个的内存,这种情况我没有修改配置文件的内存分配,也是能够正常运行的,截图如下图所示,这些内存分配应该是根据计算公式算出来的大小

http://zhisheng-blog.oss-cn-hangzhou.aliyuncs.com/2020-03-10-031745.png

第四种情况是启动的时候通过参数(-ytm 4096m)指定 TM 整个的内存,这种情况我自己指定了
taskmanager.memory.managed.size 和 taskmanager.memory.task.heap.size
参数的大小,发现启动作业报异常,

Caused by: org.apache.flink.configuration.IllegalConfigurationException:
Derived JVM Overhead size (2.236gb (2400539987 bytes)) is not in configured
JVM Overhead range [192.000mb (201326592 bytes), 1024.000mb (1073741824
bytes)]

http://zhisheng-blog.oss-cn-hangzhou.aliyuncs.com/2020-03-10-032045.png

个人觉得原因可能是因为我指定了taskmanager.memory.managed.size
和 taskmanager.memory.task.heap.size 参数的大小,Flink 就将 4096m
减去指定的大小,然后将剩下来的分配给其他的几种内存,结果超出了
Overhead 的默认最大值,所以检查就返回异常了,不知道是不是这样的原理?

那么就有个问题了,因为在生产环境其实很难知道所有作业的运行状态,所以我们都是这边都是通过
参数(-ytm 4096m)指定 TM
的内存,如果不指定是使用默认的,那么如果和上面情况四一样,既改了配置文件中的配置,又想通过参数(-ytm)去控制整个
TM 的内存,就有冲突了?

对于这种情况,我觉得是不是可以多加个参数控制,这个参数的作用是
heap 内存的 fraction,这样我只需要根据我配置的 fraction
来分配总的内存值,因为我看 managed 和 network、overhead 这些都是有这个参数的

eg:
taskmanager.memory.task.heap.fraction

不清楚这个建议是否得当,感谢!

Xintong Song <tonysong820@gmail.com> 于2020年3月10日周二 上午10:39写道:

> >
> > 这里的“所配置的direct内存”,是指按照task.manager.network.memory.fraction计算得到的network
> > memory大小。我想是不是这部分内存按照memory segment全部预分配了,所有metrics里显示的是全部是被Used了?
>
>
> 是的,Network Buffer Pool 是在 TM 初始化时预申请好的。在所有内存类型中,只有
Network Memory
> 是预申请的。Managed Memory 1.9 以前是有一个配置可以预申请(默认不开),1.10
起不再支持预申请。
>
>
> Thank you~
>
> Xintong Song
>
>
>
> On Tue, Mar 10, 2020 at 10:30 AM pkuvisdudu <zjkingdom2010@163.com> wrote:
>
> > 多谢解答。
> > 关于“第二个是我看到metrics里directMemoryUsed总是和所配置的direct内存大小是一样的,不知道具体原因是啥?”
> > 这里的“所配置的direct内存”,是指按照task.manager.network.memory.fraction计算得到的network
> > memory大小。我想是不是这部分内存按照memory segment全部预分配了,所有metrics里显示的是全部是被Used了?
> >
> >
> >
> >
> > | |
> > 张江
> > |
> > |
> > 邮箱:zjkingdom2010@163.com
> > |
> >
> > 签名由 网易邮箱大师 定制
> >
> > 在2020年03月10日 10:16,zhisheng 写道:
> > hi,xintong,感谢耐心且专业的回答👍
> >
> > Xintong Song <tonysong820@gmail.com> 于2020年3月10日周二 上午10:04写道:
> >
> > > Hi Zhisheng,
> > >
> > > 1、Non-Heap 那个 UI 上展示的是否是 MetaSpace 和 Overhead 加起来的值?
> > >
> > >
> > > 从物理含义上来说,Non-Heap 描述的内存开销是包含在 Metaspace
+ Overhead 里的。
> > >
> > >
> > > > 2、为什么本地起的 Standalone Flink,为啥 UI 上展示的 Heap
会超过设置的
> > > > taskmanager.memory.process.size 的值?
> > >
> > >
> > > 这主要是因为,我们只针对 Metaspace 设置了 JVM 的参数,对于其他
Overhead 并没有设置 JVM 的参数,也并不是所有的
> > > Overhead 都有参数可以控制(比如栈空间)。
> > >
> > > Non-Heap Max 是 JVM 自己决定的,所以通常会比 Flink 配置的 Metaspace
+ Overhead
> > > 要大。可以这样理解,Flink 将整个 TM 的内存预算划分给了不同的用途,但是并不能严格保证各部分的内存都不超用,只能是
Best
> > > Effort。其中,Managed、Network、Metaspace 是严格限制的,Off-Heap、Overhead
> > > 是不能完全严格限制的,Heap 整体是严格限制的但是 Task/Framework
之间是非严格的。
> > >
> > > Non-Heap 这个 metric 对用户的意义不大,且容易造成用户误解。FLIP-102
目前还在讨论中,我们也在给 Yadong
> > > 提建议是否就不展示 Non-Heap了。
> > >
> > > 3、默认 Flink 自身的配置下,启动 Flink 1.9 和
> > > >
> > 1.10,运行相同的作业他们性能之间的差距大概是什么样的?如果上生产是否可以使用默认的内存配置?会不会堆内存有点小了?这个我说下我自己简单测试了下
> > > > Flink 1.9 和 1.10 下运行同一个有状态的作业,他们的 GC
情况差别还挺大的。1.10 Young GC 次数差不多是
> 1.9
> > > 的两倍。
> > >
> > >
> > > 1.10 默认配置比起 1.9,减小了 Heap 增大了 Managed,可以参考
Memory Calculation Sheet [1]
> 中的
> > > 1.9/1.10
> > >
> > >
> >
> 默认配置各部分内存大小对比(可以把这个表复制到自己的空间取得写权限,对各配置项的值进行修改可以直接看到各部分内存大小的变化)。至于对作业性能的影响,主要取决于作业类型(流还是批、statebackend类型等),没法一概而论。默认配置主要考虑的是用户初始尝试
> > > Flink 的需求,如果上生产的话,通常是需要改配置的。
> > >
> > >
> > > Hi 张江,
> > >
> > >
> > > 一是您前面说native内存是无法知道使用情况的,那么除了cut-off里的native内存,在Flink
配置项中
> task/framework
> > > > offheap(包括 direct 和 native内存)其中的native内存,以及1.10里managed
> memory使用的native
> > > > 内存,是不是也无法在metrics里展示使用情况?
> > >
> > >
> > > Task/Framework OffHeap 也无法在 metrics 里展示。Managed Memory 理论上
Flink
> > > 自己有统计,我们也在考虑增加相应的 metrics 展示,目前的话也还是看不到的。
> > >
> > >
> > > 第二个是我看到metrics里directMemoryUsed总是和所配置的direct内存大小是一样的,不知道具体原因是啥?
> > >
> > >
> > > 要看你所说的“所配置的direct内存大小”是指什么?
> > >
> > >
> > > Thank you~
> > >
> > > Xintong Song
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://docs.google.com/spreadsheets/d/1mJaMkMPfDJJ-w6nMXALYmTc4XxiV30P5U7DzgwLkSoE/edit#gid=0
> > >
> > > On Tue, Mar 10, 2020 at 12:07 AM pkuvisdudu <zjkingdom2010@163.com>
> > wrote:
> > >
> > > > 多谢解答。
> > > > managed memory和network buffers在作业启动后会有调整是在
> > > >
> > >
> >
> https://ci.apache.org/projects/flink/flink-docs-release-1.9/ops/mem_setup.html
> > > > 里看到的,是1.9版本里的。
> > > >
> > > >
> > > > 还有两个小地方想确认一下,一是您前面说native内存是无法知道使用情况的,那么除了cut-off里的native内存,在Flink
> 配置项中
> > > > task/framework offheap(包括 direct 和
> native内存)其中的native内存,以及1.10里managed
> > > > memory使用的native 内存,是不是也无法在metrics里展示使用情况?
> > > > 第二个是我看到metrics里directMemoryUsed总是和所配置的direct内存大小是一样的,不知道具体原因是啥?
> > > >
> > > >
> > > > 再次非常感谢~
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 在 2020-03-09 18:39:13,"Xintong Song" <tonysong820@gmail.com>
写道:
> > > > >>
> > > > >> 图1中的Direct类型里面所包含的framework offheap、task
offheap以及shuffle就是您讲的“不在
> > JVM
> > > > >> 堆上但受到 JVM 管理的内存:Direct”么?
> > > > >
> > > > >是的
> > > > >
> > > > >
> > > > >> 这部分内存是可以知道其使用情况并在metrics里看到的么?
> > > > >
> > > > >应该是与metrics中的Direct是对应的(因为绝大多数情况我们没有使用Mapped
> > Buffer),这里细节我记不太清楚了最好再确认下。
> > > > >
> > > > >另外,flink 1.10里将RocksDBStateBackend改为使用managed
> memory,不过网页上显示的是managed
> > > > >> memory统一使用offheap内存,您的解答里说的是native内存,不知道是不是您说的“完全不受
JVM
> > > 管理的内存:Native”这个?
> > > > >
> > > > >是的
> > > > >
> > > > >不是太清楚offheap和direct以及native的关系是怎样的
> > > > >
> > > > >Flink 配置项中的 task/framework offheap,是包括了 direct
和 native
> > > > >内存算在一起的,也就是说用户不需要关心具体使用的是
direct 还是 native。
> > > > >
> > > > >最后,我在官网上看managed memory和network buffers在作业启动后会有变化
> > > > >
> > > >
> > > >
> > >
> >
> >能把具体的页面链接发一下吗,可能指的是1.9以前的情况,1.10是不会变化的。1.9以前的话,TM会在进程启动并初始化之后触发一次GC,然后以GC后的空闲内存作为Heap内存重新算一遍managed、network内存应该多大。
> > > > >
> > > > >Thank you~
> > > > >
> > > > >Xintong Song
> > > > >
> > > > >
> > > > >
> > > > >On Mon, Mar 9, 2020 at 3:23 PM pkuvisdudu <zjkingdom2010@163.com>
> > > wrote:
> > > > >
> > > > >> 非常详细的解答,非常感谢~~
> > > > >>
> > > > >> 还有一些小疑问。图1中的Direct类型里面所包含的framework
offheap、task
> > > > offheap以及shuffle就是您讲的“不在
> > > > >> JVM 堆上但受到 JVM 管理的内存:Direct”么?这部分内存是可以知道其使用情况并在metrics里看到的么?
> > > > >>
> > > > >> 另外,flink 1.10里将RocksDBStateBackend改为使用managed
> > memory,不过网页上显示的是managed
> > > > >> memory统一使用offheap内存,您的解答里说的是native内存,不知道是不是您说的“完全不受
JVM
> > > > >> 管理的内存:Native”这个?不是太清楚offheap和direct以及native的关系是怎样的
> > > > >>
> > > > >> 最后,我在官网上看managed memory和network
> > > > >> buffers在作业启动后会有变化,但我一直看不懂是咋变化的,不知道这里能否解答一下
> > > > >>
> > > > >> 再次感谢详细的解答~~
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> | |
> > > > >> 张江
> > > > >> |
> > > > >> |
> > > > >> 邮箱:zjkingdom2010@163.com
> > > > >> |
> > > > >>
> > > > >> 签名由 网易邮箱大师 定制
> > > > >>
> > > > >> 在2020年03月09日 11:22,Xintong Song 写道:
> > > > >> Hi,
> > > > >>
> > > > >>
> > > > >> 关于你的几个问题:
> > > > >>
> > > > >>
> > > > >> 1. 关于 JVM 的内存,堆内存(Heap
> Memory)的定义通常是比较清晰的,但堆外/非堆内存(Off-Heap/Non-Heap
> > > > >> Memory)的定义却有很多不同的版本,这应该是导致你困惑的主要原因。让我们先抛开这些名词,本质上
Java 应用使用的内存(不包括
> > JVM
> > > > >> 自身的开销)可以分为三类:
> > > > >> JVM 堆内存:Heap
> > > > >> 不在 JVM 堆上但受到 JVM 管理的内存:Direct
> > > > >> 完全不受 JVM 管理的内存:Native
> > > > >> Direct 内存是直接映射到 JVM 虚拟机外部的内存空间,但是其用量又受到
JVM 的管理和限制,从这个角度来讲,认为它是
> JVM
> > > > 内存或者非
> > > > >> JVM 内存都是讲得通的。
> > > > >>
> > > > >>
> > > > >> 关于 Off-Heap/Non-Heap,广义上讲只要不是 Heap 内存就可以称为
Non-Heap,但是我们经过实验发现
> > MXBean
> > > 的
> > > > >> Non-Heap 是不包括 Direct,而是由 Code Cache、Metaspace、Compressed
Class
> Space
> > > > >> 几个部分组成。FLIP-102 讨论的是 metrics 如何在
WebUI 上展示,Flink metrics 是通过
> MXBean
> > > > >> 获取的,因此图一展示的 Non-Heap 是与 MXBean 的
Non-Heap 定义的。
> > > > >>
> > > > >>
> > > > >> 2. Heap/Non-Heap 前面已经介绍过,而 Direct/Mapped 则同样是通过
MXBean 统计两个 Buffer
> > > Pool
> > > > >> 的情况。这里的 Direct 指的是 Direct Buffer Pool 而不是
Direct Memory,这两个 Buffer
> > > Pool
> > > > 都是受
> > > > >> -XX:MaxDirectMemorySize 控制的,可以认为都是 Direct
Memory 的一部分。
> > > > >>
> > > > >>
> > > > >> 这几个 metrics 加在一起不是 TM 的总内存,一方面是因为
Native 内存没有被算进去(也就是 Cut-off
> > > 的主要部分),因为
> > > > >> Native 是不受 JVM 管理的,MXBean 完全不知道它的使用情况。另一方面,JVM
> > > > 自身的开销也并不是都被覆盖到了,比如对于栈空间,JVM
> > > > >> 只能限制每个线程的栈空间有多大,但是不能限制线程的数量,因此总的栈空间大小也是不受控制的,也没有通过
Metric 来体现。
> > > > >>
> > > > >>
> > > > >> 总的来说,JVM 的内存机制是非常复杂的,且并不是每一个部分都能够由用户参数控制的。Flink
1.10
> > > > >> 简化了内存模型,目的是让用户不需要去关心这其中的细节,只关注
Flink 各功能模块所需的相关内存大小即可。而目前在 1.10 中的
> > > > metric
> > > > >> 是比较缺失的无法完全描述 Flink 的内存使用情况,社区提出
FLIP-102 梳理 metrics 及 UI
> > > > >> 展示也正是为了解决这个问题。但即便如此,受
JVM 内存机制本身的限制,恐怕也很难做到每个部分都完全匹配到对应的
metrics
> 上。
> > > > >>
> > > > >>
> > > > >> 3. 这个应该是存在 state 里的,具体用哪种类型的内存取决于你的
State Backend
> > > > >> 类型。MemoryStateBackend/FsStateBackend 用的是 Heap
> 内存,RocksDBStateBackend
> > > 用的是
> > > > >> Native 内存,也就是 1.10 中的 Manage Memory。
> > > > >>
> > > > >>
> > > > >>
> > > > >> Thank you~
> > > > >>
> > > > >> Xintong Song
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Sun, Mar 8, 2020 at 4:49 PM pkuvisdudu <zjkingdom2010@163.com>
> > > > wrote:
> > > > >>
> > > > >>  Hi all,
> > > > >>
> > > > >>
> > > > >> 我是Flink新人,最近在看一些flink资源管理机制的知识,有3个内存类型方面的问题想请教大家:
> > > > >>
> > > > >>
> > > > >> 1.
> > > > >>
> > > >
> > >
> >
> Flink的内存类型如下图1所示,其中Heap内存和NonHeap内存由JVM管理,我想问一下Direct内存是否也是由JVM管理?因为我同时也看到过图2所示的内存类型,上面标示的是JVM
> > > > >> Direct,但在FLIP102里看到的是属于Outside JVM,所以现在有点困惑。另外,我从相关页面上只看到了Network
> > > > buffers,
> > > > >> Managed memory,
> Heap的计算方法,但不知道按照图1所示的内存类型,Direct内存和NonHeap是怎么计算分配的?
> > > > >> 图1
> > > > >> 图2
> > > > >> 2. Flink metrics里展示的内存方面的信息以Status.JVM.Memory为前缀,包含Heap,
NonHeap,
> > > > Direct,
> > > > >>
> > > >
> > >
> >
> Mapped四种。我测试过,这四种内存Used之和应该并不是TM真正所使用的总内存。那么TM使用的总内存还包括哪些,是在哪里用到的?(不知道是不是cut-off那部分使用的内存?)Flink
> > > > >> 1.10似乎对内存进行了更细致的划分和分配,但在metrics里展示的内配置和使用信息还是跟1.9一样的么?
> > > > >> 3.
> Window相关的算子会将窗口内的数据作为状态保存在内存里,等待窗口触发再进行计算。想问一下这里的状态是存在哪种类型的内存里面?
> > > > >>
> > > > >>
> > > > >> 祝好,
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message