可怕的Full GC （转自Hbase不睡觉书）

PS：之前做项目的时候，需要做个复杂的查询，大量的查询总是导致hbase集群奔溃，最后定位到时full GC的原因。

以下转自《Hbase不睡觉书》------------------------

可怕的Full GC

随着内存的加大，有一个不容忽视的问题也出现了，那就是JVM的堆内存越大， Full GC的时间越久。 Full GC有时候可以达到好几分钟。在Full GC的时候JVM会停止响应任何的请求，整个JVM的世界就像是停止了一样，所以这种暂停又被叫做Stop-The-World（ STW）。当ZooKeeper像往常一样通过心跳来检测RegionServer节点是否存
活的时候，发现已经很久没有接收到来自RegionServer的回应，会直接把这个RegionServer标记为已经宕机。等到这台RegionServer终于结束了Full GC后，去查看ZooKeeper的时候会发现原来自己已经“ 被宕机” 了，为了防止脑裂问题的发生，它会自己停止自己。这种场景称为RegionServer自杀，它还有另一个美丽的名字叫朱丽叶暂停，而且这问
题还挺常见的，早期一直困扰着HBase开发人员。所以我们一定要设定好GC回收策略，避免长时间的Full GC发生，或者是尽量减小Full GC的时间。

GC回收策略优化
由于数据都是在RegionServer里面的， Master只是做一些管理操作，所以一般内存问题都出在RegionServer上。接下来主要用RegionServer来讲解参数配置，如果你想调整Master的内存参数，只需要把HBASE_REGIONSERVER_OPTS换成HBASE_MASTER_OPTS就行了。JVM提供了4种GC回收器：

串行回收器（ SerialGC）。
并行回收器（ ParallelGC），主要针对年轻带进行优化（ JDK 8默认策略）。
并发回收器（ ConcMarkSweepGC，简称CMS），主要针对年老带进行优化。
G1GC回收器，主要针对大内存（ 32GB以上才叫大内存）进行优化。

具体实现请参考《Hbase不睡觉书》第八章第一节。

《Hbase不睡觉书》下载 https://pan.baidu.com/s/1u6lA1zRcYvLGxGov19ObcA 提取码: 7xpb

其实spark也有这个问题。

巴特西

可怕的Full GC （转自Hbase不睡觉书）

最新文章

热门文章