Flink 使用Memory State导致OOM问题与解决

一、现象

1.1 程序现象

程序是处理一个业务由2个表、4条数据、互相Join形成2条结果。Flink读取Kafka。模拟数据程序持续往Kafka插入数据,在TaskManager只有较低内存时，模拟了2000次插入（8000条数据时）,Flink的TaskManager就发生了OOM问题。使用jstat -gcutil
（遇到一个小问题root用户无法查看yarn用户的jvm jstat信息 找不到socket文件，
Unable to open socket file: target process not responding or HotSpot VM not loaded
需要切换过去。切换yarn用户遇到 资源不够。需要修改linux配置https://www.cnblogs.com/taiguyiba/p/7868894.html）

查看JVM进程发现Old区域在年轻代做垃圾回收时,每次持续5%左右的增长，直到达到100%的状态。即使做FGC，Old的内存也降不下去。持续一段时间FGC无响应后，则被JobManager认为该container中的TaskManager无响应，并移除这个TaskManager。直到整个应用的TaskManager都被移除。最后程序Finished （异常退出崩溃）。

二、解决

2.1 加内存

最初步定位是的内存不够，于是一开始就想着给TaskManager加内存。直到加到16G内存。但是OOM的问题丝毫没有改善。在处理24条数据后。Old区用完且下降。持续FGC。异常退出。

2.2 分析Dump文件

在16G内存TaskManager情况下。dump出Old区大概为90%的情况下的堆文件 （11G）。将dump文件拷贝到一台8G的windows机器，使用MAT工具进行分析，但是一直分析失败。windows机器不够用。

解决：在linux机器上使用 Mat Linux版。使用命令行工具进行分析。（参考：https://blog.csdn.net/lxhandlbb/article/details/76695607
linux使用MAT分析dump文件 http://www.moheqionglin.com/site/blogs/84/detail.html
）
./ParseHeapDump.sh 12303.hprof org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components

结果会生产如下三个zip文件，很小可以直接拷贝到本机
jmap_Leak_Suspects.zip
jmap_System_Overview.zip
jmap_Top_Components.zip
将分析结果zip文件 导出到本地打开浏览器观察。

可以明显的看到是CopyOnWriteStateTable占据了5.3G的内存空间。存活在Old区。无法被垃圾回收。

该CopyOnWriteStateTable是Flink的Memory State 。并不推荐生产使用。

2.6 引入RocksDB

于是在程序中引入 rocksdb （
RocksDB介绍：
https://www.jianshu.com/p/73fa1d4e4273 、
https://www.ververica.com/blog/stateful-stream-processing-apache-flink-state-backends、
https://blog.csdn.net/zhangjun5965/article/details/88885534）、并修改代码使用rocksDB，配置好路径。

<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-statebackend-rocksdb_2.11</artifactId>
</dependency>

重新打包程序运行后。
13分钟内往kafka持续插入160万条数据。

old 区几乎不增长。增长也是0.01%的速度匀速增长。解决OOM问题。Flink程序正常运行。