最近生产上rs服务频繁挂,都是因为gc时间过久导致的session超时,其实服务是好的,只是被zk认为死了,所以rs自己也就把自己kill了
首先会考虑到调高Session的容忍度,默认180000其实这个回话有效期已经够长的了,但是有的集群是可以
降低了这个值,可能会造成Session 超时,这个参数是 zookeeper.session.timeout 默认18000。
针对上面这个参数,有的博文认为即使设为180000也不能真正的达到目的,因为zookeeper 会将minSessionTimeout 设为 2*ticktimes ,而将maxSessionTimeout 设为
20*ticktimes 当 zookeeper.session.timeout 设置超过20*ticktimes 的时候,系统会取 min(zookeeper.session.timeout,20*ticktimes) 来出来。
针对上述观点,我从源码中找到了结论,首先如果是分布式的Hbase那 会启动HQuorumPeer 进程 看下这个源码:
-
- HQuorumPeer.main 方法中会调用 writeMyID(zkProperties) ,而就在此方法中已经将 maxSessionTimeout设置为 zookeeper.session.timeout 的时长。
- 调用HQuorunPeer.runZKServer
- 调用QuorumPeerMain.runFromConfig
- 设置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());
- 由此可看此件并没有直接和tickTime对比的机会。倒是minSessionTimeout没有设置,默认是2*ticktime
由此可见 其实如果设置了Zookeeper.session.timeout的话 不会轻易去截取20*ticktime,再不信可以用echo conf|nc zserver 2181 看一下 zookeeper系统参数
其实,真正要解决的是gc导致的停止,hbase中不能有较长的gc等待,具体的gc经过实践,可以参考以下配置:
我们目前的系统是使用export HBASE_HEAPSIZE=16384,16G的内存,这个数字从哪来呢?相信这还得查看官网,官网不是万能的,但不看官网是万万不能的。一下是官网的一段话:
Thus, ~20-24Gb or less memory