在Flink作业中，发现某个Subtask的Checkpoint时间显著高于其他Subtask，且出现Kafka的DisconnectException错误。调整request.timeout.ms后，异常减少但Checkpoint延迟增加。日志显示问题可能与网络稳定性、Kafka源端背压及特定Subtask的TM（TaskManager）PS_Scavenge次数过多有关。考虑到可能是由于keyby操作中使用了三个中文字符拼接的key导致内存消耗过大，怀疑与机器资源分配及内存管理配置有关。尽管调整TM内存有一定效果，但问题依然存在，且每次重启作业，问题Subtask ID保持不变，表明这可能是固定资源分配问题。
文章目录
1.概述
遇到有遇到过这种情况的么？某个subtask的ck时间总是比其他的subtask久很多，检查各个subtask的消费，也没有数据倾斜，好几次ck超时都是被这个subtask拖垮的
日志开始报org.apache.kafka.common.errors.DisconnectException: null，调整request.timeout.ms后就不怎么报了。
TM的PS_Scavenge次数较大，但是3个TM都较大，唯独每次都是同一个subtask的ck时间较突出。
作业背压在kafka source端，下游数据处理也没有背压啊。
我觉得调大request.timeout，虽然kafka不超时了，但是拖得时间长了，导致ck start delay 久了？
因为根据文章：Kafka : kafka errors.DisconnectException: null
DisconnectException: null 这个和网络有关，应该是网络不好，这个报错和kafka 不稳定有关 检测topic详情 网络稳定性等。
做ck的时候 会提交offset 如果提
订阅专栏 解锁全文
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
