flink 1.11.0 chk超时
http://apache-flink.147419.n8.nabble.com/file/t538/QQ%E6%88%AA%E5%9B%BE20201105165123.jpg http://apache-flink.147419.n8.nabble.com/file/t538/QQ%E6%88%AA%E5%9B%BE20201105165200.jpg chk的历史如图，第三个subtask未能ack，同时在TM中只能找到如下信息：
2020-11-05 13:13:38,101 INFO org.apache.flink.streaming.api.functions.sink.filesystem.Buckets [] - Subtask 2 checkpointing for checkpoint with id=16 (max part counter=6). 2020-11-05 13:13:38,143 INFO org.apache.flink.streaming.api.functions.sink.filesystem.Buckets [] - Subtask 1 checkpointing for checkpoint with id=16 (max part counter=0). 2020-11-05 13:14:37,779 WARN org.apache.kafka.clients.NetworkClient [] - Connection to node -3 could not be established. Broker may not be available. 2020-11-05 13:14:37,786 WARN org.apache.kafka.clients.NetworkClient [] - Connection to node -2 could not be established. Broker may not be available. 2020-11-05 13:33:38,115 INFO org.apache.flink.runtime.taskmanager.Task [] - Attempting to cancel task Source: Custom Source -> Process -> (Sink: ***, Sink: *** sink, Sink: ***) (3/3) (68bfa6305a9aa5a7381b9ca4a8fef2fa).
请路过的大佬们指点下排查方式，多谢（当前日志级别暂无法改成debug）*来自志愿者整理的flink邮件归档
写回答
-
CP 超时的原因一般是因任务而议的。从你提供的 2 张截图来看，卡在第二个 operator 的 subtask3 上。 上下两个 operator 之间的关系是 forworad 还是 reblance 呢？如果是 forward 的话，可以看下是不是数据倾斜，subtask3 需要处理的数据量比较多。 如果是 reblance 的话，以为 subtask1 和 subtask2 都成功了，所以上游的 barrier 应该都往下发了，所以 subtask3也收到了上游的 barrier，而 reblance 数据量都一样，所以可以看下是不是 sink 出去太慢导致。 查看任务一般可以看下任务的日志， GC，采堆栈，画火焰图等。*来自志愿者整理的flink邮件归档
2021-12-07 11:25:14赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
