flink taskmanager oom 调优过程

flink taskmanager oom 调优过程

flink版本：1.14.3

问题背景

1. savepoint保存逐步增大，单个任务一次savepoint10G以上。
2. taskmanager日志打印ttl到期
   INFO org.apache.flink.table.runtime.operators.sink.SinkUpsertMaterializer [] - The state is cleared because of state ttl. This will result in incorrect result. You can increase the state ttl to avoid this.
3. taskmanager 在任务启动后内存逐步增高，RES逐步逼近最大内存限制，即使停掉所有任务后，内存依然无法释放。

排查过程及解决方案

1.1排查过程：savepoint逐步增大主要是任务状态膨胀导致的，主要优化方向就是清理过期状态和调整快照模式
1.2解决方案：
1.2.1给任务设置ttl
set table.exec.state.ttl=7200000;
设置ttl的目的是为了让flink清除内存中过期状态，具体值根据业务需要，这里是保留2小时状态。
1.2.2 stateBackendType后端状态设置为RocksDBStateBackend，开启checkpoint增量模式。

state.backend=rocksdb
state.backend.incremental: true

1.2.3 调大 checkpointInterval间隔：900000(15min)，调大的主要目的减少快照的资源消耗。

2.1排查过程：这个报错非常具有迷惑性，一开始看到报错后便调大了set table.exec.state.ttl的值
这个参数，但是依然报错，后来把值设为0（这意味着它永远不会清除状态），这个报错依然持续。
查阅flink1.14.3源码发现，该报错是动态表在更新时，回撤流无法找到对应主键导致的，这个也是flink非确定性更新（NDU)问题，这个问题也会导致状态膨胀；排查发现flink sql中只在sink端指定了主键，未在source端指定主键。
2.2解决方案：source端和sink端都需要指定主键 PRIMARY KEY (id) NOT ENFORCED

3.1 排查过程：通过arthas的dashboard命令查看taskmanager jvm情况，发现jvm远小于taskmanager 进程的RES，且g1_eden_space占heap98%以上，而g1_old_gen只占1%左右，初步排除jvm无法回收老年代的问题；基本就是state backbend的问题，state backend 的内存回收不受flink控制。
3.2解决方案：
3.2.1 在flink-conf.yaml中调整RocksDB相关参数

#指定rocksdb日志输出路径
state.backend.rocksdb.log.dir: /tmp/rocksdb_log
#RocksDB文件的最大大小
state.backend.rocksdb.log.max-file-size: 25mb
#RocksDB应保留用于信息记录的最大文件数
state.backend.rocksdb.log.file-num: 4
#RocksDB日志级别
state.backend.rocksdb.log.level: INFO_LEVEL
#文件块大小
state.backend.rocksdb.block.blocksize: 4kb
#RocksDB中数据块的缓存量
state.backend.rocksdb.block.cache-size: 128mb
#监控驻留在块缓存中的条目的内存大小
state.backend.rocksdb.metrics.block-cache-usage: true

RocksDB的参数调整可以根据实际情况来，上述调整会导致RocksDB在内存中数据量相对减小，但是也会增大io和磁盘刷写频率，这个看取舍。

资料

taskmanager oom的原因很多，有可能是代码的问题，有可能是流量激增的问题，也有可能是任务状态的问题，排查时需要仔细判断；分享一些大佬的文章关于参数调优和错误排查的文章。
ps:flink官方文档中的一些默认参数配置也在不断优化，比如1.14.4的state.backend.rocksdb.log.file-num默认参数和1.16.0的默认参数不一致，这个也是社区在不断调优的表现，所以最好按新版的参数来调整默认参数。