hbase gc调优(CMS与G1)

一:hbase gc调优目的:

在HBase中,有两个在内存中的结构消费了绝大多数的heap空间。BlockCache缓存读操作的HFileblock,Memstore缓存近期的写操作,基于HBase是一个响应时间敏感,并且需要对GC时间可控的应用的出发点。

二:hbase的gc调优本文通过CMS与g1两种算法进行设置参考。

需要大致了解两种垃圾收集器的概念及不同

三:几个基本概念:

  1. Full GC == Major GC指的是对老年代/永久代的stop the world的GC
  2. Full GC的次数 = 老年代GC时 stop the world的次数
  3. Full GC的时间 = 老年代GC时 stop the world的总时间
  4. CMS 不等于Full GC,我们可以看到CMS分为多个阶段,只有stop the world的阶段被计算到了Full GC的次数和时间,而和业务线程并发的GC的次数和时间则不被认为是Full GC
  5. Full GC本身不会先进行Minor GC,我们可以配置,让Full GC之前先进行一次Minor GC,因为老年代很多对象都会引用到新生代的对象,先进行一次Minor GC可以提高老年代GC的速度。比如老年代使用CMS时,设置CMSScavengeBeforeRemark优化,让CMS remark之前先进行一次Minor GC。

四:CMS调优:

1.CMS收集器在老年代内存回收中执行的阶段说明:

(1) 初始标记 (Initial Mark) (Stop the World Event,所有应用线程暂停):在老年代(old generation)中的对象, 如果从年轻代(young generation)中能访问到, 则被 “标记,marked” 为可达的(reachable).对象在旧一代“标志”可以包括这些对象可能可以从年轻一代。暂停时间一般持续时间较短,相对小的收集暂停时间.

(2) 并发标记 (Concurrent Marking):在Java应用程序线程运行的同时遍历老年代(tenured generation)的可达对象图。扫描从被标记的对象开始,直到遍历完从root可达的所有对象. 调整器(mutators)在并发阶段的2、3、5阶段执行,在这些阶段中新分配的所有对象(包括被提升的对象)都立刻标记为存活状态.

(3) 再次标记(Remark):(Stop the World Event, 所有应用线程暂停) 查找在并发标记阶段漏过的对象,这些对象是在并发收集器完成对象跟踪之后由应用线程更新的.

(4) 并发清理(Concurrent Sweep):回收在标记阶段(marking phases)确定为不可及的对象. 死对象的回收将此对象占用的空间增加到一个空闲列表(free list),供以后的分配使用。死对象的合并可能在此时发生. 请注意,存活的对象并没有被移动.

(5) 重置(Resetting):清理数据结构,为下一个并发收集做准备.

2.CMS的失效模式(CMS Failure)

并发模式失败

第一种失败的模式,是简单的并发模式失败。最好的一个例子:假设有一个8GB堆,已经使用了7GB。当CMS的收集开始第一阶段,它欢快的隆隆的做着并发标记。与此同时,有更多的数据被分配到老年代。如果老年代增长的速度太快,在CMS完成第一阶段标记工作之前就填满了全部老年代。这时候因为没有自由空间,CMS就无法工作!CMS必须放弃并行工作,并回落到停止世界(stop-the-world)单线程复制收集算法。此算法开始搬迁堆,检查所有活动对象,并释放了所有死角。长时间的停顿后,该程序可能会继续。
但我们可以很容易的通过调整JVM参数避免并发模式失败:我们只需要鼓励CMS提前开始工作!设置-XX:CMSInitiatingOccupancyFraction = N,其中N是堆在开始收集过程中的百分比。HBase仔细的计算了内存使用,以保持其只使用60%的堆空间,所以我们通常将此值设置为大约70。(译者注:同时也可以考虑Old区的30%要比Young区大,这样即使Young区在CMS之前全部搬迁到Old区也不会把Old区填满)

碎片导致的CMS失败

这种故障模式是多一点复杂。回想一下,CMS收集不搬迁对象,而是简单地跟踪所有堆的自由空间,而且自有空间是分开的。作为一个思想实验,想象我拨出1亿个对象,每个1KB,这正是1GB堆的总用量为1GB。然后,我释放所有奇数对象,所以我有500MB的自有空间,然而自由空间都是1KB的块。如果我需要分配一个2KB的对象,尽管我表面上有500MB免费空间,依然会无处可放。这就是所谓的内存碎片。因为CMS不搬迁对象,不管如何让CMS提前启动,都不可以解决这个问题!发生此问题时,CM再次回落到复制收集器,该方法能够压缩所有的对象并释放。

3.CMS收集器参数设置参考:

-Xmx64g -Xms64g -Xmn2g -Xss256k 
-XX:MaxPermSize=256m -XX:SurvivorRatio=2  
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 
-XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15 -XX:+UseCMSCompactAtFullCollection  -XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC 
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:/usr/local/deploy/logs/gc.log

4.参数说明:

-Xmx 分配给JVM最大堆内存

-Xms 分配给JVM初始堆内存

-Xmn 分配给young区的内存大小

-Xss 分配给每个线程的堆栈大小

-XX:MaxPermSize 分配给持久代的大小

-XX:SurvivorRatio 表示young区中Eden与Survivor区的内存大小比例,默认为8.

-XX:+UseConcMarkSweepGC 该标志首先是激活CMS收集器。默认HotSpot JVM使用的是并行收集器。

-XX:+UseParNewGC 当使用CMS收集器时,该标志激活年轻代使用多线程并行执行垃圾回收。这令人很惊讶,我们不能简单在并行收集器中重用-XX:UserParNewGC标志,因为概念上年轻代用的算法是一样的。然而,对于CMS收集器,年轻代GC算法和老年代GC算法是不同的,因此年轻代GC有两种不同的实现,并且是两个不同的标志

-XX:+CMSParallelRemarkEnabled 当该标志被启用时,并发的CMS阶段将以多线程执行(因此,多个GC线程会与所有的应用程序线程并行工作)。该标志已经默认开启,如果顺序执行更好,这取决于所使用的硬件,多线程执行可以通过-XX:-CMSConcurremntMTEnabled禁用。

-XX:MaxTenuringThreshold 如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代.对于年老代比较多的应用,可以提高效率.如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活 时间,增加在年轻代即被回收的概率,该参数只有在串行GC时才有效.

-XX:+UseCMSCompactAtFullCollectionCMS 是不会移动内存的, 因此, 这个非常容易产生碎片, 导致内存不够用, 因此, 内存的压缩这个时候就会被启用。 增加这个参数是个好习惯。可能会影响性能,但是可以消除碎片

-XX:+UseCMSInitiatingOccupancyOnly 禁止hostspot自行触发CMS GC

-XX:CMSInitiatingOccupancyFraction 使用cms作为垃圾回收使用70%后开始CMS收集

-XX:-DisableExplicitGC 关闭System.gc()

五:g1垃圾收集器:

1.概念介绍:

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征. 在Oracle JDK 7 update 4 及以上版本中得到完全支持, 专为以下应用程序设计:
可以像CMS收集器一样,GC操作与应用的线程一起并发执行
紧凑的空闲内存区间且没有很长的GC停顿时间.
需要可预测的GC暂停耗时.
不想牺牲太多吞吐量性能.
启动后不需要请求更大的Java堆.
G1的长期目标是取代CMS(Concurrent Mark-Sweep Collector, 并发标记-清除). 因为特性的不同使G1成为比CMS更好的解决方案. 一个区别是,G1是一款压缩型的收集器.G1通过有效的压缩完全避免了对细微空闲内存空间的分配,不用依赖于regions,这不仅大大简化了收集器,而且还消除了潜在的内存碎片问题。除压缩以外,G1的垃圾收集停顿也比CMS容易估计,也允许用户自定义所希望的停顿参数(pause targets)

2.G1收集器在老年代堆内存中执行阶段.(注意有些阶段也是年轻代垃圾收集的一部分):

(1) 初始标记(Initial Mark):(Stop the World Event,所有应用线程暂停) 此时会有一次 stop the world(STW)暂停事件. 在G1中, 这附加在(piggybacked on)一次正常的年轻代GC. 标记可能有引用指向老年代对象的survivor区(根regions).

(2) 扫描根区域(Root Region Scanning):扫描 survivor 区中引用到老年代的引用. 这个阶段应用程序的线程会继续运行. 在年轻代GC可能发生之前此阶段必须完成.

(3) 并发标记(Concurrent Marking):在整个堆中查找活着的对象. 此阶段应用程序的线程正在运行. 此阶段可以被年轻代GC打断(interrupted).

(4) 再次标记(Remark):(Stop the World Event,所有应用线程暂停) 完成堆内存中存活对象的标记. 使用一个叫做 snapshot-at-the-beginning(SATB, 起始快照)的算法, 该算法比CMS所使用的算法要快速的多.

(5) 清理(Cleanup):(Stop the World Event,所有应用线程暂停,并发执行)

在存活对象和完全空闲的区域上执行统计(accounting). (Stop the world)

擦写 Remembered Sets. (Stop the world)

重置空heap区并将他们返还给空闲列表(free list). (Concurrent, 并发)

(*) 拷贝(Copying) (Stop the World Event,所有应用线程暂停) 产生STW事件来转移或拷贝存活的对象到新的未使用的heap区(new unused regions). 只在年轻代发生时日志会记录为 [GC pause (young)]. 如果在年轻代和老年代一起执行则会被日志记录为 [GC Pause (mixed)].

3.G1收集器参数配置参考:

-XX:+UseG1GC 
-Xms100g -Xmx100g 
-XX:MaxGCPauseMillis=100 
–XX:+ParallelRefProcEnabled 
-XX:-ResizePLAB 
-XX:ParallelGCThreads=28
Promotion Local Allocation Buffers(PLABs)是在Young代回收时被使用。并且是多线程。每个需要分配空间的对象被拷贝到Survior或者Old代。PLABs 需要避免使用线程共享的数据结构为了管理空闲内存。每个GC线程有一个PLAB用于一个Survival区和一个Old区。我们需要重新配置PLAB的大小来避免GC线程间的大量通信,这也是影响GC的一个变量
-XX:G1NewSizePercent=1修改Eden大小
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintAdaptiveSizePolicy

4.G1收集器参数说明:

-XX:+UseG1GC 使用 G1 (Garbage First) 垃圾收集器

-XX:MaxGCPauseMillis=n 设置最大GC停顿时间(GC pause time)指标(target). 这是一个软性指标(soft goal), JVM 会尽量去达成这个目标.

-XX:InitiatingHeapOccupancyPercent=n 启动并发GC周期时的堆内存占用百分比. G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示"一直执行GC循环". 默认值为 45.

-XX:NewRatio=n 新生代与老生代(new/old generation)的大小比例(Ratio). 默认值为 2.

-XX:SurvivorRatio=n eden/survivor 空间大小的比例(Ratio). 默认值为 8.

-XX:MaxTenuringThreshold=n 提升年老代的最大临界值(tenuring threshold). 默认值为 15.

-XX:ParallelGCThreads=n 设置垃圾收集器在并行阶段使用的线程数,默认值随JVM运行的平台不同而不同.

-XX:ConcGCThreads=n 并发垃圾收集器使用的线程数量. 默认值随JVM运行的平台不同而不同.

-XX:G1ReservePercent=n 设置堆内存保留为假天花板的总量,以降低提升失败的可能性. 默认值是 10.

-XX:G1HeapRegionSize=n 使用G1时Java堆会被分为大小统一的的区(region)。此参数可以指定每个heap区的大小. 默认值将根据 heap size 算出最优解. 最小值为 1Mb, 最大值为 32Mb.