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 久了?
因为根据文章:
在Flink作业中,发现某个Subtask的Checkpoint时间显著高于其他Subtask,且出现Kafka的DisconnectException错误。调整request.timeout.ms后,异常减少但Checkpoint延迟增加。日志显示问题可能与网络稳定性、Kafka源端背压及特定Subtask的TM(TaskManager)PS_Scavenge次数过多有关。考虑到可能是由于keyby操作中使用了三个中文字符拼接的key导致内存消耗过大,怀疑与机器资源分配及内存管理配置有关。尽管调整TM内存有一定效果,但问题依然存在,且每次重启作业,问题Subtask ID保持不变,表明这可能是固定资源分配问题。
订阅专栏 解锁全文
1万+

被折叠的 条评论
为什么被折叠?



