记一次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,从而引起重新选举。

 最后经同事反馈,极有可能是由于大数据所依赖的云平台的IO问题造成的,因为云平台出问题的时间与我们大数据平台故障的时间相一致,而另一个小的物理集群依然正常,

其实这个问题,我分析的时候,按正常的逻辑,应该先检查系统本身的问题,要去var/log/messages中去检查有没有IO相关的错误或其他错误,这是第一步。

因为是云平台的问题,他们坏了一块盘,刚好分在了CDH的管理节点上,我们在日志中找不到INPUT/OUTPUT的错误,只是超时。

这就是HADOOP权威指南中没有不建议使用云平台的原因,容易隐藏问题,还享受不到云平台本身带来的那些优势。

谨记!!!!

 

posted on 2018-12-31 21:01  tneduts  阅读(1544)  评论(0编辑  收藏

导航