我们线上有一套clickhouse集群，5分片2副本总计10个实例，每个实例独占1台物理机，配套混布一个3节点zookeeper集群。

　　进入登录界面后执行 ls /卡顿半天，然后返回timeout。应该是ZK集群通信出了问题，先对其进行滚动重启，重启后问题依然存在。

　　我们线套CK集群，每套都独占一套zk，其余3套集群的zookeeper的内存只有几十K，Node count只有几万，而出问题的这套Node count有2千多万clash节点怎么样，zookeeper进程内存30G左右。

　　该环境有一套kafka混用了ZK集群，为其搭建了一套专属ZK集群并将ZK元数据目录删除，node count和物理内存依然很高，问题没有解决。

　　清理无用表，找出600多个表，执行drop后，node count和物理内存依然很高，问题没有解决。降低Node count的尝试失败。

　　ZK的node count非常多，当前的3个ZK实例占用内存很高(RSS一直在30G上下浮动)

　　zookeeper实例本质是1个java进程，有没有可能是达到内存上限频繁的触发full gc，进而导致ZK服务响应经常性卡顿？

　　滚动重启ZK集群，启动完毕后问题依然存在，但是ZK实例的RSS从原来的30G上升到了33G，超出了Xmx上限。

　　再次重启ZK集群，ZK实例的RSS飙升到55G左右就不再上升，困扰多时的问题也自动消失了，看来刚刚的full gc猜想是正确的。

　　既然已经证明是JVM heap内存的问题，那么刚刚调整的ZK参数就全部回滚，然后滚动重启ZK集群。

　　系统自此稳定了，但是zk进程占用的物理内存越来越大，没几天就达到了64G，照这个消耗速度，256G内存被耗光是迟早的事情。

　　经和开发沟通后获悉，在7月的时候部分表的insert从每10s执行1次改成了1s执行1次，对应的就是part数量的飙升。

　　将这些表的insert统统改回了每10s执行1次，截止目前(10月28号)，10月份的part基本回落到了一个正常值。

　　至少目前可以确信znode不会再暴涨，zk进程的内存也不会继续增加，可以保证clickhouse集群稳定的运行下去。

　　这次案例前后耗费了2天的时间才得以定位原因并解决，又耗费了更长的时间才找到问题根源，距离发稿截止日期已经过了整整1个月，期间没有再复发过。