flink taskmanager oom 调优过程

文章详细描述了在Flink1.14.3版本中遇到的Savepoint大小增加和TaskManager内存逐渐升高的问题,以及相应的排查和解决策略。通过设置TTL、调整Checkpoint间隔、选择RocksDBStateBackend并启用增量模式,以及在源和接收端指定主键来优化状态管理。此外,还通过调整RocksDB配置参数来平衡内存使用和I/O性能。最后,提到了参数调优的重要性以及Flink社区的持续优化。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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的默认参数不一致,这个也是社区在不断调优的表现,所以最好按新版的参数来调整默认参数。

<think>好的,我现在需要回答用户关于Flink的JobManager日志和TaskManager日志区别的问题。首先,我要确认自己对这两个概念的理解是否正确,然后整理出它们的区别,并确保回答结构清晰,符合用户之前的要求。 用户之前询问过关于OutOfMemoryError的问题,现在转向日志的区别,可能是为了故障排除或化性能。我需要从功能、内容、作用、常见日志类型、查看方式等方面展开,帮助用户理解两者的不同。 首先,JobManager负责作业度和协,所以它的日志应该包含作业的生命周期信息,比如提交、checkpoint协、资源分配等。而TaskManager执行具体任务,日志更多涉及数据处理、网络通信、内存使用等。需要明确两者的角色差异,进而说明日志的不同。 接下来,我需要考虑用户可能的潜在需求。他们可能在遇到问题时需要查看不同的日志,比如作业启动失败时看JobManager日志,任务执行问题看TaskManager日志。因此,在回答中应强各自日志的应用场景,帮助用户快速定位问题。 另外,用户可能对如何访问这些日志感兴趣,需要简要说明查看方式,比如通过Web UI或日志文件路径。同时,需要确保使用中文,避免专业术语过多,必要时进行解释。 还要注意之前用户提到的系统级指令,比如正确使用LaTeX格式,但这个问题可能不涉及数学公式,所以重点放在结构清晰和内容准确上。需要分点列出区别,可能用标题分隔,但用户要求避免使用Markdown,所以用文字描述结构。 最后,总结两者的核心差异,帮助用户形成清晰的认知。需要检查是否有遗漏的关键点,比如日志文件的位置、常见错误示例等,确保信息全面且准确。</think>Flink的**JobManager日志**和**TaskManager日志**是两类不同角色的组件生成的日志,分别用于记录集群中不同职责模块的运行状态。以下是具体区别和分析: --- ### 一、角色与职责差异 | **组件** | **核心职责** | **日志记录重点** | |----------------|--------------------------------------|-------------------------------------------| | **JobManager** | 作业度、协(如Checkpoint触发、故障恢复) | 全局作业生命周期、资源分配、协事件 | | **TaskManager**| 执行具体任务(数据处理、Shuffle) | 本地任务执行细节、网络通信、内存/CPU使用、异常堆栈 | --- ### 二、日志内容对比 #### 1. **JobManager日志** - **作业提交与度** 记录作业的提交、生成执行图(ExecutionGraph)、资源申请(如Slot分配)。 ```log INFO org.apache.flink.runtime.jobmaster.JobMaster - Starting execution of job: JobName (f6d2b1d3e0c9d4a5b6c7...) ``` - **Checkpoint协** 记录Checkpoint触发、完成或失败事件(如Barrier对齐超时)。 ```log WARN org.apache.flink.runtime.checkpoint.CheckpointCoordinator - Checkpoint 42 of job f6d2b1d3... expired before completing. ``` - **故障恢复** 作业级容错(如JobManager主备切换、从Checkpoint恢复)。 ```log ERROR org.apache.flink.runtime.jobmaster.JobMaster - Job f6d2b1d3... failed due to TaskManager崩溃. ``` #### 2. **TaskManager日志** - **任务执行细节** 记录算子的数据处理、Watermark生成、状态后端操作。 ```log INFO org.apache.flink.streaming.runtime.io.StreamInputProcessor - Received barrier for checkpoint 42 at channel 0. ``` - **资源使用异常** 直接内存溢出(如`DirectBuffer`不足)、堆内存GC压力。 ```log ERROR org.apache.flink.runtime.io.network.netty.PartitionRequestClient - java.lang.OutOfMemoryError: Direct buffer memory ``` - **网络通信问题** Shuffle数据交换失败、连接超时、反压(Backpressure)事件。 ```log WARN org.apache.flink.runtime.io.network.partition.consumer.RemoteInputChannel - Backpressure: High buffer usage for channel InputChannel... ``` --- ### 三、常见问题定位场景 | **问题类型** | **先查看的日志** | **原因示例** | |-----------------------|------------------|-----------------------------------------| | 作业提交失败 | JobManager | 资源配置不足、依赖冲突 | | Checkpoint持续失败 | JobManager | Barrier超时、全局状态过大 | | 单个Task持续OOM | TaskManager | 数据倾斜、用户代码内存泄漏 | | 网络通信异常 | TaskManager | 物理网络中断、反压导致缓冲区堆积 | --- ### 四、日志文件位置 1. **JobManager日志** - 路径:`${FLINK_HOME}/log/flink-<user>-jobmanager-<hostname>.log` - Web UI入口:Flink Dashboard → JobManager → Logs 2. **TaskManager日志** - 路径:`${FLINK_HOME}/log/flink-<user>-taskmanager-<hostname>-<id>.log` - Web UI入口:Flink Dashboard → TaskManagers → 选择节点 → Logs --- ### 五、试建议 1. **JobManager日志**重点关注: - 作业启动阶段的异常(如序列化错误) - Checkpoint相关警告(超时、元数据丢失) 2. **TaskManager日志**重点关注: - 本地线程的异常堆栈(如`NullPointerException`) - 资源耗尽警告(内存、文件句柄) - 网络层错误(连接重置、缓冲区溢出) --- ### 总结 - **JobManager日志**是“全局指挥官日志”,用于跟踪作业整体生命周期。 - **TaskManager日志**是“士兵执行日志”,用于诊断具体任务的问题根源。 两者结合使用,可快速定位从集群度到数据处理的各类问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值