HBASE性能优化之最佳内存实践

最近生产上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