HBase的gc调优，为什么

大多数Hadoop客户以至少24G内存运行Hadoop,HBase使用的内存不断增长，但JDK可用的垃圾收集算法仍然相同。这导致了HBase的许多用户的一个主要问题：随着Java使用堆大小继续增长，垃圾回收导致的垃圾回收时停止程序所占用的时间变得越来越长。在垃圾回收导致的“stop-the-world”期间，任何到HBase客户端请求都不会被处理，造成用户可见的延迟，甚至超时。如果因为暂停导致请求超过一分钟响应，HBase本身也可能会停止.

HBase依赖Apache Zookeeper的管理群集成员和生命周期。如果服务器暂停的时间过长，它将无法发送心跳ping消息到Zookeeper，其余的服务器将假定该服务器已经死亡。这将导致主服务器启动特定的恢复程序，替换被认为死亡的服务器。当这个服务器从暂停中恢复时，会发现所有它拥有的租约都被撤销，进而只好自杀。

      问题扩展

由于Java GC导致的心跳包没有及时响应问题，在对延时要求敏感的场景非常普遍。集群中的服务器每500ms发送一次心跳包到mater服务器，而master服务器由于GC导致没有及时响应心跳包，进而认为服务器死亡，导致故障

Hadoop这个回收时间比较恐怖，在线上服务分配36G Heap，平均FullGC暂停时间是6-8秒，因此万恶不是“大堆”为首，而是“内存使用方式不当”为首.