Flink Checkpoint超时问题常见排查思路

最新推荐文章于 2024-09-18 20:21:46 发布
最新推荐文章于 2024-09-18 20:21:46 发布
阅读量1.8k 收藏 1
点赞数
文章标签： 大数据 runtime 网络
原文链接：https://juejin.im/post/5c374fe3e51d451bd1663756
版权

本文大致理一下checkpoint出现超时问题的排查思路：（本文基于flink-1.4.2）

超时判断逻辑

jobmanager定时trigger checkpoint，给source处发送trigger信号，同时会启动一个异步线程，在checkpoint timeout时长之后停止本轮 checkpoint，cancel动作执行之后本轮的checkpoint就为超时，如果在超时之前收到了最后一个sink算子的ack信号，那么checkpoint就是成功的。

那么超时的原因会是什么呢？时间要么花费在barrier对齐，要么花费在异步状态遍历和写hdfs 第二种类型会很好看，因为状态很大的时候就会出现这 个现象，下面分析第一类出现的原因

Barrier处理流程

StreamTask收集到相应的inputChannel的barrier，收集齐之后就将barrier下发，并开始自己task的checkpoint逻辑，如果上下游是rescale或者 forward的形式，下游只需要等待1个并发的barrier，因为是point-to-point的，如果是hash或者rebalance，下游的每一个task开始checkpoint的 前提就是要收集齐上游所有并发的barrier。

Barrier发送流程

RecordWriter#broadcastEvent

这个方法是专门用于barrier的下发，首先会将serializer中还没下发的部分已经写入数据的buffer下发防止barrier越过数据下发的行为，保证一致性， 同时会将barrier包装成buffer对象，此处不申请堆外内存，直接将堆内内存包装成一个buffer下发。

PipelinedSubpartition#add

将要发送给下游的数据add到subpartition中，同时通知监听的subpartitionView，notifybufferAvailable事件，这里notify操作会区分 本地和远程两种channel不同处理，我们看到的都是远程消费的延迟问题，本地其实就立马执行下游的barrier收集动作了，远程的需要有网络传输过程。

server netty handler

LengthFieldBasedFrameDecoder => messageDecode => PartitionRequestServerHandler => PartitionRequestQueue => messageEncoder notifybufferAvailable事件最终会触发PartitionRequestQueue去将数据writeAndFlush到netty client中，在flush之前会判断channel 是否可写，在flush成功后，会执行相应的listener -> barrier的处理逻辑，这里可以hack代码使其在发送barrier的时候回调打印barrier发送成功， 使我们确认barrier已经从上游发送成功。

barrie接收流程

LengthFieldBasedFrameDecoder => messageDecode => PartitionRequestClientHandler => messageEncoder 首先读入消息时候会判断是否有堆积的stagedMessages，如果有则不处理，add到堆积消息中，如果没有将数据从netty buffer中拷贝至localbuffer中 ，这时候需要requestBuffer，这个方法并不block消费流程，但是如果request不到buffer那么会将数据丢入到stagedMessages，同时监听bufferpool， 等到buffer有recyle的时候就会开始buffer的转化，并且这个是时候会将channel的auto read标志置为false，因此这个通道就不再读入数据，barrier 也是无法读入的，并且每个taskmanager共享一个channel，因此taskmanager上只要阻塞了就会影响这个taskmanager上的消费。

小结

从以上可以看出，其实barrier下游无法对齐的主要原因还是在于下游消费能力不足，会导致buffer堆积一段时间，但这时并不足以造成上游反压，因为反压 需要下游channel持续无法写入，导致tcp阻塞，导致上游的outputbuffer占满才会引起反压。

一般的排查方式

查看ui上的失败checkpoint的detail，可以看到失败的是Pending -> EventEmit xxx这个算子的10个subtask。

一般由于barrier对齐原因没开始的subtask会是开始时间都是n/a，因为在汇报CheckpointStats的时候根本还没开始checkpoint，注意这里的11，12 并不是subtaskIndex，这里千万不要被误导了去查看这个subtask的问题。

接着去jobmanager上查看这个checkpoint的一些延迟信息

2018-11-29 18:43:04,624 INFO  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Checkpoint 224 expired before completing.
2018-11-29 18:43:26,763 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from f2862289958b430bc3dc20f39794ca2c of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,766 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from 8f569166274106f22e49ed2ce919c930 of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,770 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from a29e34c210b39104004af7f067c1a5d0 of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,771 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from 7d4914521fd53fca56a4050d6f191ae9 of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,771 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from 618c78d0008d0d525728ff9824339229 of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,773 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from c8ba24a328234dc7f2f271db4a8eb1e3 of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,777 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from 72af6c722fcc085dc8f7c46e9124d82e of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,777 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from f824cb6920b04d19e05278ee362ec675 of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:26,780 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from af6d867d2f12be23c7b23a938aba7c5e of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:27,265 WARN  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Received late message for now expired checkpoint attempt 224 from cee0205fe9a85e3e89e023a1166ed1e6 of job 7c7769847d333438dd9ce845d5a2d980.
2018-11-29 18:43:44,624 INFO  org.apache.flink.runtime.checkpoint.CheckpointCoordinator     - Triggering checkpoint 225 @ 1543488224622
复制代码

可以根据这些失败的task的id去查询这些任务落在哪一个taskmanager上，经过排查发现，是同一台机器，通过ui看到该机器流入的数据明显比别的流入量大 因此是因为数据倾斜导致了这个问题，追根溯源还是下游消费能力不足的问题

指标

可以反映一个算子的指标有几个

  • inPoolUsage
  • OutPoolUsage
  • OutputQueueLength
  • inputQueueLength

首先前3个值都是未加锁获得的非准确数据，为了数据消费本身的性能，参考意义不大。而inputQueueLength可以加以参考，为什么这个加锁了，可能 是社区遗漏了。。这个值最大应该是（分区如果是hash，其他分区方式会更小一点）上游并发 * 2 + 8 + 上游并发，如果到达这个值左右，此时发送barrier 到下游会无法反序列化并进行正确的checkpoint操作，至于为什么最后一个上游并发单独拎开，是因为这个含义表示的barrier数量，barrier的数量也会算 在inputQueueLength内。

在flink1.5之后的@zhijiangW网络栈优化后的版本中据说checkpointBarrier是可以越过数据优先发送，需要确认这种情况下如何保障处理的exactly once语义呢？

转载于:https://juejin.im/post/5c374fe3e51d451bd1663756

weixin_34150224
关注
【flink】Flink常见Checkpoint超时问题排查思路
九师兄
11-20 5068
1.概述 转载：Flink常见Checkpoint超时问题排查思路 这里仅仅是自己学习。 在日常flink应用中，相信大家经常会遇到checkpoint超时失败这类的问题，遇到这种情况的时候仅仅只会在jobmanager处打一个超时abort的日志，往往一脸懵逼不知道时间花在什么地方了，本文就基于flink1.4.2版本理一下checkpoint出现超时问题的排查思路 2.超时判断逻辑 jobmanager定时trigger checkpoint，给source处发送trigger信号，同时会启动一个异步.
Flink Checkpoint 问题排查实用指南
SmartSi
09-23 492
在 Flink 中，状态可靠性保证由 Checkpoint 支持，当作业出现 failover 的情况下，Flink 会从最近成功的 Checkpoint 恢复。在实际情况中，我们可能会遇到 Checkpoint 失败，或者 Checkpoint 慢的情况，本文会统一聊一聊 Flink 中 Checkpoint 异常的情（包括失败和慢），以及可能的原因和排查思路。
Flink Checkpoint 超时问题详解
weixin_51981189的博客
01-25 2864
等于说每来一条数据，都需要对用户近24小时内所有的行为事件进行分类汇总，求比例，再汇总，再求比例，而QPS是1500，24小时1.5亿的累积数据，逻辑处理的算子根本无法将接收到的数据在合适的时间内计算完毕，这里还有个有趣的现象，为了提高处理性能，我将并行度翻倍，结果checkpoint的时间反而更长了，原因是Source的并行度也增加后，读取源数据的速度更快了～所以和算法同学商议后，将实现逻辑进行修改，进行批流分开计算，比如离线数据每半个小时进行一次计算，而实时计算只需要计算最近半小时内的数据即可。
Flink系列知识之：Checkpoint原理
最新发布
大数据开发、JAVA开发、人工智能AI
09-18 1324
Flink系列知识之：Checkpoint原理
Flink Checkpoint超时问题
热门推荐
lisenyeahyeah的博客
03-09 1万+
Flink Checkpoint超时问题排查 文章目录Flink Checkpoint超时问题排查问题现象问题分析问题1：TaskManager进程挂掉问题2：任务长时间处于CANCELING问题3：Checkpoint超时问题4：数据无法正常同步解决思路总结参考文档 问题现象 业务部门最近使用Flink来做数据实时同步，通过同步工具把CDC消息接入Kafka，其中上百张表同步到单个topic里，然后通过Flink来消费Kafka，做数据解析、数据分发、然后发送到目标数据库(mysql/oracle)，整个
记一次Flink checkpoint超时问题的排查
梦想成真那天
07-10 3837
最近在做Flink实时自定义报表,在临近上线的时候,在测试的过程中,运行一段时间后,发现Flink的checkpoint经常会超时导致数据计算延迟甚至会导致组中Flink程序挂掉. 由于这个程序在之前是运行了比较长的一段时间的,并没有报出问题,所一并没有怀疑到是程序本身的问题,最终经过修改测试,所以浪费了较多的时间,经过多方面测试,最终在查看代码的过程中,发现我每个窗口中存在一个查询SQL跟新配置...
flink checkpoint超时问题排查方法
csa121的博客
08-05 2774
一般来讲，checkpoint配置10s-60s都是合理的，默认的超时时间是600s，在业务逻辑不复杂的情况下，极少会出现超时的情况 如果发生了超时。就需要先定位到具体的机器和进程。 然后再根据业务场景排查具体是什么问题引起的超时。 flink集群和上下游组件正常运行的情况下，由于业务逻辑处理或者数据问题导致超时的概率应该在99%以上，所以在排除系统问题的情况下，直接从业务逻辑定位问题是正确的方向。 排查思路分3步： 1. 先找到超时的subtask序号 如果超时正在发生，可以直接在 这里看到超时的那一条
Flink｜checkpoint 超时报错问题处理（FlinkRuntimeException）
长行
01-07 2385
Flink 的 checkpoint 的超时时间时 600 秒，但是这个任务需要 11 分钟才能完成。另一方面也可能是因为线上运行时，对 MySQL 请求时走的是内网请求，而本地运行走的是外网请求。为了评估一个 Flink 程序的处理效果，我使用本地模式启动了 Flink 程序，并在上游表中一次性插入了大量数据（大概相当于线上单个并发 4 - 5 分钟的最大处理量），以触发计算。但是，在本地计算中，一直无法计算完成，观察后发现任务在被重复计算，进而发现 Flink 在不断从 checkpoint 恢复。
Flink checkpoint失败
野狼e族 的博客
04-06 2298
目录 前言 问题描述 问题定位 checkpoint的基本原理 思路 现象 问题解决 前言 Flink容错机制的核心部分是绘制分布式数据流和操作员状态的一致快照。这些快照充当一致的检查点，如果发生故障，系统可以回退到这些检查点。Flink绘制这些快照的机制在“分布式数据流的轻量级异步快照”中进行了介绍。它受用于分布式快照的标准Chandy-Lamport算法的启发，并且专门针对Flink的执行模型进行了量身定制。 问题描述 flink任务，从kafka中获取数据，经过处理，写...
【Flink】Flink 反压机制 导致checkpoint 失败
九师兄
11-20 1677
1.概述 转载：flink检查点checkpoint失败问题总结-2 问题描述：检查点刚开始是可以的做checkpoint的，后期越来越不能够做checkpoint的情况总结 2.反压问题 2.1 什么是反压(如下图1所示)？ 图2-1 部分算子反压表现（web ui） 2.2.flink中反压机制是干什么的？ ​ flink中的反压机制是flink中由于个别算子接收receive数据的速度远大于处理完成数据的速度，数据在算子接收之前的数据积压（在buffer缓冲区），过多的数据积压时反压导致上游的算.
flink 三种时间机制_Flink Checkpoint容错机制0448
weixin_39597987的博客
12-27 602
Checkpoint容错机制Checkpoint是Flink实现容错机制最核心的功能，它能够根据配置周期性地基于Stream中各个Operator/task的状态来生成一个轻量级的分布式快照，从而将这些状态数据定期持久化存储下来，当Flink程序一旦意外崩溃时，重新运行程序时可以有选择地从这些快照进行恢复，从而修正因为故障带来的程序数据异常。默认情况下，检查点不会保存，仅用于从失败中恢复作业。取消...
Flink:四大基石[Time,Window,Checkpoint,State]
07-27 4676
Time 与 Window Time: 在 Flink 的流式处理中，会涉及到时间的不同概念，如下图所示： Event Time：是事件创建的时间。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink 通过时间戳分配器访问事件时间戳。 Ingestion Time：是数据进入 Flink 的时间。 Processing Time：是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是 Processing Time。 例如: 一条日志进入 F
flink 三种时间机制_【Flink 精选】Checkpoint 机制如何保证 Exactly-Once 语义
weixin_29932039的博客
12-29 352
问题1：阐述 Flink 提供的三种数据处理语义，解释 Checkpoint 机制如何保证 Flink 程序结果的 Exactly-Once 语义？问题2：结合 Kafka 分析，如何通过两阶段提交协议，提供端到端的 Exactly-Once 处理？1.Flink 提供的三种数据处理语义① At-Most-Once：最多一次，如果产生故障，可能丢失数据。 ② At-Least-Once：最少一次，...
Flink 第2章 状态及Checkpoint调优
青冬的博客
03-18 2585
RocksDB大状态调优 RocksDB是基于LSM Tree实现的，写数据都是先写入到内存中，所有RocksDB的写请求效率较高。RocksDB使用内存结合磁盘的方式来存储数据，每次获取数据时，先从内存中的blockcache中查找，如果没有再去磁盘中查询。 使用RocksDB时，状态大小仅受可用磁盘空间量的限制，性能瓶颈主要在于RocksDB对磁盘的读请求，每次读写操作都必须对数据进行序列化或者反序列化。 当处理性能不够的时候，需要横向扩展并行度提高整个Job的吞吐量。 开启..
PostgreSQL检查点(checkpoint)详解
Focus on PostgreSQL
11-11 1万+
checkpoint简单点说就是一个数据库事件，用来保证数据一致性和完整性。 当我们在数据库中执行checkpoint时，就会将其之前的脏数据刷到磁盘，从而实现数据缩短数据库崩溃恢复时间的目的。 例如当我们更新任何数据的时候，对应于包含该数据的块将在shared buffers中更新。所做更改的记录保存在wal缓冲区中。提交后，我们所做的更改将被写入磁盘上的wal文件，从而使它们永久生效。如果实例立即崩溃，则将清除数据库共享缓冲区，但是在重新启动数据库时，PostgreSQL将把WAL文件中记录的更改应用于
记录：Flink checkpoint 过期导致失败（线上问题）
shi_xiansheng的博客
08-19 2546
报错信息： 2021-08-18 18:28:40,502 INFO org.apache.flink.runtime.checkpoint.CheckpointCoordinator [] - Triggering checkpoint 1 (type=CHECKPOINT) @ 1629282520408 for job 1cba827ad8a8d68521605157b77a6191. 2021-08-18 18:38:40,502 INFO org.apache.flink.runti
关于flink状态中使用TreeSet，当执行checkpoint时出现空指针错误。
qq_39902301的博客
02-09 808
flink状态中使用TreeSet，当执行checkpoint时出现空指针错误NullPointerException。
flink checkpoint失败
03-16
Flink checkpoint失败可能有多种原因，以下是一些常见的原因和解决方法： 1. 网络问题：Flink checkpoint需要将数据写入分布式文件系统或者其他存储介质，如果网络不稳定或者存储介质出现问题，就会导致checkpoint...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值