Hi, yidan 建议排查下 Leader 频繁选举时 JobManager 是否存在频繁 GC 的情况。 如果不是还可以通过 jobmanager.log 查看是否存在其他异常。
> 2022年3月11日 下午4:34，yidan zhao <hinobl...@gmail.com> 写道： > > 我指的选举主要是flink的选举，就是访问web ui后，显示正处于选举过程中。然后我一直等，一直处于选举过程中。 > > Biao Geng <biaoge...@gmail.com> 于2022年3月11日周五 13:00写道： > >> Hi yidian， >> >> 如果我没理解错的话，你提到集群没有flink作业时，zk也会有较低概率发生leader选举（你说的“重启”应该是指leader选举？）。这本身就是可能有问题的。你可以先去看看zk的日志判断一下zk重启的原因。 >> >> Best， >> Biao >> >> yidan zhao <hinobl...@gmail.com>于2022年3月11日 周五12:17写道： >> >>> 我zk主要就flink和kafka用，还有kafka-manager，应该用的不是不多。至少zk的磁盘IO很低。 >>> 除非说是zk所在机器本身压力高勉强可能，但是zk本身压力不会高。 >>> >>> >>> Biao Geng <biaoge...@gmail.com> 于2022年3月11日周五 12:06写道： >>> >>>> Hi yidian, >>>> >>>> 你说的应该是ZK >>>> >>>> >>> >> leader频繁选举？你可以看下ZK的日志，看看有没有更具体的原因。一般是因为ZK存储用量过大(znode数目过多)，导致ZK的leader和follower数据同步失败，触发选举。 >>>> Flink HA任务数目不多的话，一般在ZK侧压力不大。你可以看看有没有其他应用也使用了ZK服务。 >>>> >>>> Best, >>>> Biao >>>> >>>> yidan zhao <hinobl...@gmail.com>于2022年3月11日 周五11:51写道： >>>> >>>>> 如题，大家知道为啥吗。 >>>>> 一般如果集群没任务。重启问题出现概率低。 >>>>> 但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。 >>>>> >>>> >>> >>
