flink taskmanager 因为内存超了container限制 被yarn kill 问题定位

[柯四海]

Hi 大家好，

我用github上Blink分支(1.5)编译的flink来运行一些实时任务，发现Taskmanager 因为内存超了container限制被yarn kill.

有没有人有比较好的问题定位方案？

尝试过但是还没有解决问题的方法：

  1. 尝试增加taskmanager内存

        修改： 从8G 提高到 36G, state back  从fileSystem 改为RocksDB. 

        现象：taskmanager运行时间增加了好几个小时，但是还是因为内存超了被yarn kill.

  2. dump taskmanager 堆栈，查看什么对象占用大量内存

       操作： jmap -dump ....

       现象： 还没有dump结束，taskmanager就因为没有heartbeat 被主动kill. (尝试过修改heartbeat时间，还是无果)

  3. 借用官网debug方式，如下，但是没有dump出文件.

   4. 设置containerized.heap-cutoff-ratio，希望触发 oom 从而产生dump文件，但是这个参数似乎不起作用.

[Congxian Qiu]

Hi
   比较好奇你为什么在 Blink 分支做测试，而不是用最新的 1.11 做测试呢？
Best,
Congxian


柯四海 <[hidden email]> 于2020年8月24日周一 下午5:58写道：

> Hi 大家好，
> 我用github上Blink分支(1.5)编译的flink来运行一些实时任务，发现Taskmanager
> 因为内存超了container限制被yarn kill.
> 有没有人有比较好的问题定位方案？
>
> 尝试过但是还没有解决问题的方法：
>   1. 尝试增加taskmanager内存
>         修改： 从8G 提高到 36G, state back  从fileSystem 改为RocksDB.
>         现象：taskmanager运行时间增加了好几个小时，但是还是因为内存超了被yarn kill.
>   2. dump taskmanager 堆栈，查看什么对象占用大量内存
>        操作： jmap -dump ....
>        现象： 还没有dump结束，taskmanager就因为没有heartbeat 被主动kill.
> (尝试过修改heartbeat时间，还是无果)
>   3. 借用官网debug方式，如下，但是没有dump出文件.
>    4. 设置containerized.heap-cutoff-ratio，希望触发 oom 从而产生dump文件，但是这个参数似乎不起作用.
>

[柯四海]

我不是在做测试，公司flink是别人用的blink 分支编译的，我最近也有切换到 flink 1.11 来运行的打算, 我用flink 1.11 来试试.




------------------&nbsp;原始邮件&nbsp;------------------
发件人:                                                                                                                        "user-zh"                                                                                    <[hidden email]&gt;;
发送时间:&nbsp;2020年8月24日(星期一) 晚上8:22
收件人:&nbsp;"user-zh"<[hidden email]&gt;;

主题:&nbsp;Re: flink taskmanager 因为内存超了container限制 被yarn kill 问题定位



Hi
&nbsp;&nbsp; 比较好奇你为什么在 Blink 分支做测试，而不是用最新的 1.11 做测试呢？
Best,
Congxian


柯四海 <[hidden email]&gt; 于2020年8月24日周一 下午5:58写道：

&gt; Hi 大家好，
&gt; 我用github上Blink分支(1.5)编译的flink来运行一些实时任务，发现Taskmanager
&gt; 因为内存超了container限制被yarn kill.
&gt; 有没有人有比较好的问题定位方案？
&gt;
&gt; 尝试过但是还没有解决问题的方法：
&gt;&nbsp;&nbsp; 1. 尝试增加taskmanager内存
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 修改： 从8G 提高到 36G, state back&nbsp; 从fileSystem 改为RocksDB.
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 现象：taskmanager运行时间增加了好几个小时，但是还是因为内存超了被yarn kill.
&gt;&nbsp;&nbsp; 2. dump taskmanager 堆栈，查看什么对象占用大量内存
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 操作： jmap -dump ....
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 现象： 还没有dump结束，taskmanager就因为没有heartbeat 被主动kill.
&gt; (尝试过修改heartbeat时间，还是无果)
&gt;&nbsp;&nbsp; 3. 借用官网debug方式，如下，但是没有dump出文件.
&gt;&nbsp;&nbsp;&nbsp; 4. 设置containerized.heap-cutoff-ratio，希望触发 oom 从而产生dump文件，但是这个参数似乎不起作用.
&gt;

[Xintong Song]

首先，TaskManager 因为内存超用被杀，只能是 native 内存造成的。因为 flink 指定了 jvm 的 xmx 参数，heap
内存是不可能出现超用的，如果内存不足只会出现 OOM。所以你去排查 heap dump 这个方向是有问题的。

解决思路应该是调大 containerized.heap-cutoff-ratio，这个参数的含义是在 yarn container 中留出一定比例的
native 内存，让 jvm 只去使用剩余部分的内存。这些 native 主要用于：java native 方法调用、jvm
自身开销（类元数据、线程栈等）、rocksdb。flink 是无法控制这部分内存的用量的，只能是通过预留足够多的内存的方式，防止 container
超用。

Thank you~

Xintong Song



On Mon, Aug 24, 2020 at 8:56 PM 柯四海 <[hidden email]> wrote:

> 我不是在做测试，公司flink是别人用的blink 分支编译的，我最近也有切换到 flink 1.11 来运行的打算, 我用flink 1.11
> 来试试.
>
>
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人:
>                                                   "user-zh"
>                                                                     <
> [hidden email]&gt;;
> 发送时间:&nbsp;2020年8月24日(星期一) 晚上8:22
> 收件人:&nbsp;"user-zh"<[hidden email]&gt;;
>
> 主题:&nbsp;Re: flink taskmanager 因为内存超了container限制 被yarn kill 问题定位
>
>
>
> Hi
> &nbsp;&nbsp; 比较好奇你为什么在 Blink 分支做测试，而不是用最新的 1.11 做测试呢？
> Best,
> Congxian
>
>
> 柯四海 <[hidden email]&gt; 于2020年8月24日周一 下午5:58写道：
>
> &gt; Hi 大家好，
> &gt; 我用github上Blink分支(1.5)编译的flink来运行一些实时任务，发现Taskmanager
> &gt; 因为内存超了container限制被yarn kill.
> &gt; 有没有人有比较好的问题定位方案？
> &gt;
> &gt; 尝试过但是还没有解决问题的方法：
> &gt;&nbsp;&nbsp; 1. 尝试增加taskmanager内存
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 修改： 从8G 提高到 36G,
> state back&nbsp; 从fileSystem 改为RocksDB.
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> 现象：taskmanager运行时间增加了好几个小时，但是还是因为内存超了被yarn kill.
> &gt;&nbsp;&nbsp; 2. dump taskmanager 堆栈，查看什么对象占用大量内存
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 操作： jmap -dump ....
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 现象：
> 还没有dump结束，taskmanager就因为没有heartbeat 被主动kill.
> &gt; (尝试过修改heartbeat时间，还是无果)
> &gt;&nbsp;&nbsp; 3. 借用官网debug方式，如下，但是没有dump出文件.
> &gt;&nbsp;&nbsp;&nbsp; 4. 设置containerized.heap-cutoff-ratio，希望触发 oom
> 从而产生dump文件，但是这个参数似乎不起作用.
> &gt;