记一次ZOOKEEPER集群超时问题分析

Posted huaxiaoyao

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次ZOOKEEPER集群超时问题分析相关的知识,希望对你有一定的参考价值。

CDH安装的ZK,三个节点,基本都是默认配置,一直用得正常,今天出现问题,
客户端连接超时6倍时长,默认最大会话超时时间是一分钟。
原因分析:
1.首先要确认网络正确。确认时钟同步。
2.查看现有的配置,基本都是默认配置 JVM配置是1G 有 2g的,不一样
3.查看dataDir目录,du -sh .发现已经有五百多M
具体原因不确定,没有看到日志中出现的问题,
分析可能是因为随着时间的推移,ZOOKEEPER中的数据信息量增大,启动后
因为需要同步的数据量和初始同步时间过短简(initLimit=10)等原因,
造成集群不健康,
解决方案:
1.增大JVM堆栈内存从1G到3G,确认机器上有足够内存,不能SWAP。
2.增大TICKTIME FROM 2000 TO 3000  增加“tickTime”或者“initLimit和syncLimit”的值,或者两者都增大。
3.增大最大客户端连接数 统一为600 (以防万一)

查询相关的资料:

1 参考这位兄弟的文章:菜鸟小玄: https://www.jianshu.com/p/f30ae8e75d6d

一个server广播的数据包括4个部分:

自己所选取的leader的id:首次选举的话,这个id就是自己的id;

当前server保存的数据的zxid:越新就越应该被其它server选为leader,保证数据的最新

逻辑时钟:也就是这是第几次选举,越大表示这是越新的选举;

本机状态:LOOKING,FOLLOWING,OBSERVING,LEADING几种;

每个server收到其它server发来的值后,进行判断,选择所保存的数据最新(zxid最大)、逻辑时钟最大,且在选举状态的id作为leader(当然,还有其它条件,逻辑比较复杂,这里不再赘述),并重新广播。来来回回几次之后,系统达成一致,得票多的为leader,leader被选出。

现在leader被选出,但这并不意味着它能坐稳leader的位置,因为接下来,leader要向所有的follower同步自己所保存的数据(多写问题)。如果这个过程出错或超时,则又需要重新选举leader;

那么一般造成zookeeper集群挂掉的原因是什么呢?归根到底一句话:要同步的数据太大!多大?500M

zookeeper集群中leader和follower同步数据的极限值是500M,这500M的数据,加载到内存中,大约占用3个G的内存。数据过大,在每次选举之后,需要从server同步到follower,容易造成下面2个问题:

网络传输超时,因为文件过大,传输超过最大超时时间,造成TimeoutException,从而引起重新选举。

 

以上是关于记一次ZOOKEEPER集群超时问题分析的主要内容,如果未能解决你的问题,请参考以下文章

记一次zookeeper集群搭建

记一次kubernetes集群异常:kubelet连接apiserver超时

zook主要有哪些功能

“不敢去怀疑代码,又不得不怀疑代码”记一次网络请求超时分析

记一次ceph心跳机制异常的案例

为啥dubbo使用ZkClient作为zookeeper的客户端