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权威指南中没有不建议使用云平台的原因，容易隐藏问题，还享受不到云平台本身带来的那些优势。
谨记！！！！