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權威指南中沒有不建議使用雲平台的原因，容易隱藏問題，還享受不到雲平台本身帶來的那些優勢。
謹記！！！！