flink-user-zh mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xintong Song <tonysong...@gmail.com>
Subject Re: Flink 内存类型相关疑问
Date Tue, 10 Mar 2020 02:38:56 GMT
>
> 这里的“所配置的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