开发者社区> 问答> 正文

KafkaSource检查点的end to end duration较长(1min)原因是什么?

如题,我任务的检查点(对齐检查点)大多数时间成功,偶现失败。目前针对超时类失败做了分析,存在部分特点,希望大佬们分析下原因。

(1)KafkaSouce的e2e时间达到1min+,正常xxx

ms就结束了。同时对应e2e达到1min+的情况下,sync、async、alignment、start delay等都为0,偶尔几个x

ms的。 这个不是很明白什么情况会是这样呢?

(2)对于部分task,start delay假设为31s,alignment duration为43s,但是processed

data才xxxKB(几十到几百KB)。从我任务的正常处理情况对比来说,这个数据量几乎不需要时间就能处理完。

(3)有个window算子(前边是hash进来,keyBy的),检查点时间1m14s。然后看了下subtask的检查点,大多数都是2s内完成,其中1个subtask耗时1m14s。这个subtask对应的start-delay为1m13s。

这个就更奇怪了,首先前边是keyBy,所以是hash分区方式进入window算子。那么,对于正常subtask0,其start_delay为1s,那么subtask0收到第一个barrier耗时1s,假设这个barrier来自上游算子的

0 号子任务(preTask0)。那么preTask0既然已经发送了barrier,对于window任务的异常subtask就应该也能很快收到barrier,可是实际却耗时1min14s(start

delay)。*来自志愿者整理的flink邮件归档

展开
收起
彗星halation 2021-12-02 11:36:35 940 0
1 条回答
写回答
取消 提交回答
  • 我觉得问题是不是出在反压上面,你的job是不是有反压?*来自志愿者整理的FLINK邮件归档

    2021-12-02 11:52:21
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
Tracking-Ransomware-End-To-End 立即下载
Window_Time_Watermark 立即下载
低代码开发师(初级)实战教程 立即下载