hbase GC怎样优化 生产hbase优化

背景

一般来说RegionServer的堆内存越大越好，但是因为垃圾回收的缘故，内存大了之后，相应的FullGC时间也会线性增加，一般来说每G的内存需要的FullGC时间为：。FullGC优势可能达到好几分钟，这个阶段会停止响应任何请求，相当于所有线程挂起，这种暂停又叫做Stop-The-World(STW)，FullGc的对HBase造成严重后果比较严重：
在Zookeeper检测RegionServer心跳包的时候，RegionServer正在FullGc无法回应，而如果超过阀值等待时间会被标记为宕机，这时候会将该RegionServer上的数据向其他RegionServer迁移，并且该RegionServerFullGc结束后发现自己被宕机了，为了防止脑裂，会停止自己（RegionServer自杀，又叫朱丽叶暂停）。很多场景下会将zookeeper的心跳检测阀值调大，但是这并不可取。
RegionServer的堆内存要设定为合理的值，GC要选则适合的回收机制。

优化

系统环境
centos7
JDK8u45
regionserver 40% BlockCache ， 40% Memstore

为什么使用混合模式 （40% BlockCache ， 40% Memstore ） 具体可以看hbase的两种缓存结构MemStore和BlockCache

gc四种垃圾回收

Serial收集器：一个单线程的收集器，CPU利用率最高，停顿时间长。效率低消耗高。 通过JVM参数-XX:+UseSerialGC。
Parallel GC : Throughput friendly 目前处于维护模式，赶紧放弃吧 通过JVM参数 XX:+USeParNewGC
CMS GC: low latency for heap < 32GB 将会被G1GC取代 。通过JVM参数 -XX:+UseConcMarkSweepGC设置
G1 GC: low latency 一键GC 调优，自适应，通用性强，支持多CPU。 通过JVM参数 –XX:+UseG1GC 使用G1垃圾回收器。
G1实时目标：可配置在N毫秒内最多只占用M毫秒的时间进行垃圾回收

生产hbase GC优化参数

温馨提示: 此处内容需要回复后刷新页面 可查看.