Java GC 及HBase RegionServer GC调优

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/wwwxxdddx/article/details/50981089

1背景

1.1问题描述

HBase RegionServer由于GC等原因Stop World超过40s,RS在ZK上创建的临时节点被删除,造成Master认为RS已经下线,重新分配该RS上的Region。RS恢复后,由于种种原因(WAL被其它RSSplit并删除,Master通知RS下线等)只能主动退出。

经过长时间观察和参考网络资料,确定和HBase RS GC有关,需要调整GC参数以降低Full GC的频率。

 

1.2JVM GC简介

Java GC(Garbage Collection,垃圾收集,垃圾回收)机制主要负责3件事:1、确定哪些内存需要回收,2、确定什么时候需要执行GC,3、如何执行GC。该机制对 JVM(Java Virtual Machine)中的内存进行标记,并确定哪些内存需要回收。然后,根据一定的回收策略,自动的回收内存,永不停息(Nerver Stop)的保证JVM中的内存空间,防止出现内存泄露和溢出问题。

如JVM架构图,JAVA程序运行时的内存可以分为5个部分,这些模块的各自作用如下:程序计数器,每个线程有一个独立的程序计数器,记录下一条要运行的指令。如果执行的是JAVA方法,计数器记录正在执行的java字节码地址,如果执行的是native方法,则计数器为空;虚拟机栈 ,线程私有的,与线程在同一时间创建。管理JAVA方法执行的内存模型。每个方法执行时都会创建一个桢栈来存储方法的私有变量、操作数栈、动态链接方法、返回值、返回地址等信息。栈的大小决定了方法调用的可达深度(递归多少层次,或嵌套调用多少层,-Xss参数可以设置虚拟机栈大小)。栈的大小可以是固定的,或者是动态扩展的。如果栈的深度是固定的,请求的栈深度大于最大可用深度,则抛出StackOverflowError;如果栈是可动态扩展的,但没有内存空间支持扩展,则抛出OutOfMemoryError;本地方法区,和虚拟机栈功能相似,但管理的不是JAVA方法,是本地方法,本地方法是用C实现的;JAVA堆,线程共享的,存放所有对象实例和数组。垃圾回收的主要区域;方法区,线程共享的,用于存放被虚拟机加载的类的元数据信息:如常量、静态变量、即时编译器编译后的代码。也称为永久代。如果hotspot虚拟机确定一个类的定义信息不会被使用,也会将其回收。回收的基本条件至少有:所有该类的实例被回收,而且装载该类的ClassLoader被回收。

常见的GC策略有:标记-清除算法(Mark-Sweep),从根节点开始标记所有可达对象,其余没标记的即为垃圾对象,执行清除。但回收后的空间是不连续的;复制算法(copying),将内存分成两块,每次只使用其中一块,垃圾回收时,将标记的对象拷贝到另外一块中,然后完全清除原来使用的那块内存。复制后的空间是连续的。复制算法适用于新生代,因为垃圾对象多于存活对象,复制算法更高效;标记-压缩算法(Mark-compact),适合用于老年代的算法(存活对象多于垃圾对象)。标记后不复制,而是将存活对象压缩到内存的一端,然后清理边界外的所有对象。

 目前java中可作为GC Root的对象有:虚拟机栈中引用的对象(本地变量表);方法区中静态属性引用的对象;方法区中常量引用的对象;本地方法栈中引用的对象(Native对象)。

1.3分代GC

据IBM统计,98%对象瞬间消失,仅有2%对象存活较长时间。 HotSpot VM将堆分为Young generation和Old generation。大部分对象在Young generation创建,很快就不可达,发生在该区域的GC称为 "minor GC" 。Young generation 中存活下来的对象被拷贝(Promotion)到Old generation,该区GC频率较低,发生在该区的GC称为majorGC" (或"full GC") 。 

绝大多数刚创建的对象会被分配在Eden区,其中的大多数对象很快就会消亡。Eden区是连续的内存空间,因此在其上分配内存极快。Minor GC过程如下: 当Eden区满的时候,执行MinorGC,将消亡的对象清理掉,并将剩余的对象复制到一个存活区Survivor0(此时,Survivor1是空白的,两个Survivor总有一个是空白的); 此后,每次Eden区满了,就执行一次Minor GC,并将剩余的对象都添加到Survivor0;当Survivor0也满的时候,将其中仍然活着的对象直接复制到Survivor1,以后Eden区执行Minor GC后,就将剩余的对象添加Survivor1(此时,Survivor0是空白的)。 当两个存活区切换了几次(HotSpot虚拟机默认15次,用-XX:MaxTenuringThreshold控制,大于该值将对象提升到老年代)之后,仍然存活的对象,将被复制到老年代。

 年老代(Old Generation):对象如果在年轻代存活了足够长的时间而没有被清理掉(即在几次 Young GC后存活了下来),则会被复制到年老代,年老代的空间一般比年轻代大,能存放更多的对象,在年老代上发生的GC次数也比年轻代少。当年老代内存不足时, 将执行Major GC(或Full GC)。可以使用-XX:+UseAdaptiveSizePolicy开关来控制是否采用动态控制策略,如果动态控制,则动态调整Java堆中各个区域的大小以及进入老年代的年龄。如果对象比较大(比如长字符串或大数组),Young空间不足,则较大的对象会直接分配到老年代上。用-XX:PretenureSizeThreshold来控制直接升入老年代的对象大小,大于这个值的对象会直接分配在老年代上。

永久代的回收有两种:常量池中的常量,无用的类信息,常量的回收很简单,没有引用了就可以被回收。对于无用的类进行回收,必须保证3点:类的所有实例都已经被回收;加载类的ClassLoader已经被回收;类对象的Class对象没有被引用(即没有通过反射引用该类的地方)。

1.4常见GC策略

Serial收集器:新生代收集器,使用停止复制算法,使用一个线程进行GC,其它工作线程暂停。使用-XX:+UseSerialGC可以使用Serial+Serial Old模式运行进行内存回收(这也是虚拟机在Client模式下运行的默认值)

ParNew收集器:新生代收集器,使用停止复制算法,Serial收集器的多线程版,用多个线程进行GC,其它工作线程暂停,关注缩短垃圾收集时间。使用-XX:+UseParNewGC开关来控制使用ParNew+Serial Old收集器组合收集内存;使用-XX:ParallelGCThreads来设置执行内存回收的线程数。

ParallelScavenge 收集器:新生代收集器,使用停止复制算法,关注CPU吞吐量,即运行用户代码的时间/总时间,比如:JVM运行100分钟,其中运行用户代码99分钟,垃 圾收集1分钟,则吞吐量是99%,这种收集器能最高效率的利用CPU,适合运行后台运算(关注缩短垃圾收集时间的收集器,如CMS,等待时间很少,所以适合用户交互,提高用户体验)。使用-XX:+UseParallelGC开关控制使用 Parallel Scavenge+Serial Old收集器组合回收垃圾(这也是在Server模式下的默认值);使用-XX:GCTimeRatio来设置用户执行时间占总时间的比例,默认99,即 1%的时间用来进行垃圾回收。使用-XX:MaxGCPauseMillis设置GC的最大停顿时间(这个参数只对Parallel Scavenge有效)

 Serial Old收集器:老年代收集器,单线程收集器,使用标记整理(整理的方法是Sweep(清理)和Compact(压缩),清理是将废弃的对象干掉,只留幸存的对象,压缩是将移动对象,将空间填满保证内存分为2块,一块全是对象,一块空闲)算法,使用单线程进行GC,其它工作线程暂停(注意,在老年代中进行标 记整理算法清理,也需要暂停其它线程),在JDK1.5之前,Serial Old收集器与ParallelScavenge搭配使用。

Parallel Old收集器:老年代收集器,多线程,多线程机制与Parallel Scavenge差不错,使用标记整理(与Serial Old不同,这里的整理是Summary(汇总)和Compact(压缩),汇总的意思就是将幸存的对象复制到预先准备好的区域,而不是像Sweep(清 理)那样清理废弃的对象)算法,在Parallel Old执行时,仍然需要暂停其它线程。Parallel Old在多核计算中很有用。Parallel Old出现后(JDK 1.6),与Parallel Scavenge配合有很好的效果,充分体现Parallel Scavenge收集器吞吐量优先的效果。使用-XX:+UseParallelOldGC开关控制使用Parallel Scavenge +Parallel Old组合收集器进行收集。

CMS(Concurrent Mark Sweep)收集器:老年代收集器,致力于获取最短回收停顿时间,使用标记清除算法,多线程,优点是并发收集(用户线程可以和GC线程同时工作),停顿小。使用-XX:+UseConcMarkSweepGC进行ParNew+CMS+Serial Old进行内存回收,优先使用ParNew+CMS(原因见后面),当用户线程内存不足时,采用备用方案Serial Old收集。

G1收集器:JDK7开始支持,面向服务器的垃圾收集器,旨在取代CMS。

1.5CMS GC异常

对于采用CMS进行老年代GC的程序而言,尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况,当这两种状况出现时可能会触发Serial Old GC (或Full GC)。

promotion failed:是在进行Minor GC时,survivor space放不下、对象只能放入老年代,而此时老年代也放不下造成的;

concurrent modefailure:是在执行CMS GC的过程中同时有对象要放入旧生代,而此时老年代空间不足造成的。

造成这些异常的原因主要有:老年代内存不足,需要提前进行CMS;老年代内存碎片化,需要进行压缩整理。

 

2GC调优实战

2.1常见JVM参数

JVM参数分为:标准参数(-),所有的JVM实现都必须实现这些参数的功能,而且向后兼容;非标准参数(-X),默认jvm实现这些参数的功能,但是并不保证所有jvm实现都满足,且不保证向后兼容;非Stable参数(-XX),此类参数各个jvm实现会有所不同,将来可能会随时取消,需要慎重使用(但是,这些参数往往是非常有用的)。

非标准参数示例:

-Xms 为Heap区域的初始值,线上环境建议与-Xmx设置为一致

-Xmx 为Heap区域的最大值

-Xmn1024k,-Xmn512m,-Xmn1g(-Xms,-Xmx也是种写法)

对于非Stable参数,使用方法有4种:

    1. -XX:+<option> 启用选项

    2. -XX:-<option> 不启用选项

    3. -XX:<option>=<number> 给选项设置一个数字类型值,可跟单位,例如 32k,1024m, 2g

    4. -XX:<option>=<string> 给选项设置一个字符串值,例如-XX:HeapDumpPath=./dump.core

2.2看懂GC日志

JVM的GC日志的主要参数包括如下几个:

-XX:+PrintGC 输出GC日志

-XX:+PrintGCDetails 输出GC的详细日志

-XX:+PrintGCTimeStamps 输出GC的时间戳(以基准时间的形式)

-XX:+PrintGCDateStamps 输出GC的时间戳(以日期的形式, 2013-05-04T21:53:59.234+0800)

-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息

-Xloggc:../logs/gc.log 日志文件的输出路径

ParNew GC日志

[GC2016-03-25T02:35:26.074+0800:35289.315: [ParNew: 885174K->48101K(943744K), 0.0197790 secs]10343272K->9506199K(16672384K), 0.0199760 secs] [Times: user=0.27 sys=0.01,real=0.02 secs]

[GC时间: JVM启动时间: [类型: GC前年轻代大小A-> GC后年轻代大小B(年轻代总大小C), 耗时] GC前堆大小D->GC后堆大小E(堆的总大小F),GC总耗时] [Times: user=0.27 sys=0.01, real=0.02 secs]

B是GC后存活的对象大小,这里是不是需要分析一下MaxTenuringThreshold;F-C老年代堆大小;E-D此次GC释放内存大小;(E-D)-(B-A)年轻态提升到老年代的大小;(D-A)/(F-C)GC前老年代使用比例;(E-B)/(F-C)GC后老年代使用比。

CMS GC日志

2016-01-15T12:58:23.597+0800: 4215.939:[GC [1 CMS-initial-mark: 11025382K(15728640K)] 11130602K(16672384K), 0.0848720secs] [Times: user=0.0

3 sys=0.05, real=0.09 secs] 【1.初始标记,暂停JVM

2016-01-15T12:58:23.682+0800: 4216.024:[CMS-concurrent-mark-start]

2016-01-15T12:58:24.052+0800: 4216.393:[CMS-concurrent-mark: 0.369/0.369 secs] [Times: user=2.05 sys=0.04, real=0.37secs] 【2.并发标记】

2016-01-15T12:58:24.052+0800: 4216.393:[CMS-concurrent-preclean-start]

2016-01-15T12:58:24.091+0800: 4216.433:[CMS-concurrent-preclean: 0.039/0.039 secs] [Times: user=0.04 sys=0.00,real=0.04 secs] 【3.并发预清理】

2016-01-15T12:58:24.091+0800: 4216.433:[CMS-concurrent-abortable-preclean-start]

 CMS: abort preclean due to time2016-01-15T12:58:29.188+0800: 4221.530: [CMS-concurrent-abortable-preclean:5.094/5.097 secs] [Times: user=5.77 sys=0.18, real=5.09 secs]

2016-01-15T12:58:29.189+0800: 4221.531:[GC[YG occupancy: 317194 K (943744 K)]2016-01-15T12:58:29.189+0800: 4221.531:[Rescan (parallel) , 0.0365570 secs]2016-01-15T12:58:29.226+0800: 4221.567:[weak refs processing, 0.0047560 secs]2016-01-15T12:58:29.231+0800: 4221.572:[scrub string table, 0.0006960 secs] [1 CMS-remark: 11025382K(15728640K)]11342577K(16672384K), 0.0425260 secs] [Times: user=0.57 sys=0.01, real=0.05secs] 【4.重新标记,暂停JVM

2016-01-15T12:58:29.232+0800: 4221.574:[CMS-concurrent-sweep-start]

2016-01-15T12:58:30.903+0800: 4223.245:[CMS-concurrent-sweep: 1.666/1.671 secs] [Times: user=1.98 sys=0.06, real=1.67secs] 【5.并发清除】

2016-01-15T12:58:30.903+0800: 4223.245:[CMS-concurrent-reset-start]

2016-01-15T12:58:30.959+0800: 4223.300:[CMS-concurrent-reset: 0.055/0.055 secs] [Times: user=0.03 sys=0.02, real=0.05secs] 【6.并发重置】

如果不发生异常,我们只需要关注初始标记和重新标记。

 promotionfailed日志格式

2016-01-29T00:09:17.127+0800: 1167669.469:[GC2016-01-29T00:09:17.127+0800: 1167669.469: [ParNew (promotion failed): 943655K->943655K(943744K

), 0.1652200 secs]11986693K->12025719K(16672384K), 0.1655820 secs] [Times: user=0.99 sys=0.01,real=0.16 secs]

concurrent modefailure日志格式

2016-01-18T08:49:18.984+0800: 248471.326:[GC2016-01-18T08:49:18.984+0800: 248471.326: [ParNew (promotion failed): 943734K->924083K(943744K), 0.1256890secs]2016-01-18T08:49:19.110+0800: 248471.452:[CMS2016-01-18T08:49:23.288+0800: 248475.629: [CMS-concurrent-sweep:4.197/4.347 secs] [Times: user=4.79 sys=0.02, real=4.35 secs]

 (concurrent mode failure):11272744K->8215769K(15728640K), 10.5375280 secs]12182463K->8215769K(16672384K), [CMS Perm : 45065K->45060K(131072K)],10.6635700 secs] [Times: user=10.95 sys=0.04, real=10.67 secs]

 Full GC日志格式

2016-01-29T00:09:17.293+0800: 1167669.635:[Full GC 2016-01-29T00:09:17.293+0800: 1167669.635:[CMS2016-01-29T00:09:17.456+0800: 1167669.798:

[CMS-concurrent-abortable-preclean:0.447/0.637 secs] [Times: user=2.30 sys=0.19, real=0.64 secs]

 (concurrent mode failure):11082063K->7407560K(15728640K), 5.8053900 secs]12025719K->7407560K(16672384K), [CMS Perm : 45764K->45492K(131072K)],5.8056040 secs] [Times: user=5.75 sys=0.01, real=5.81 secs]

这个不是promotion failed引起的,应该是有较大的对象直接在老年代分配失败造成的,很少出现该现象。

2.3HBase调整CMS参数

原有参数

HBASE_HEAPSIZE:16G

-XX:+UseConcMarkSweepGC:设置年老代为并发收集

-Xmx16G -Xms16G:-Xms、-Xmx 相等以避免在GC 后调整堆的大小。

-Xmn1G:指定New Generation的大小, Yong区设置过大GC时间长。

-XX:PermSize=128M -XX:MaxPermSize=256M

-XX:SurvivorRatio=8:设置堆内存年轻代中Eden区与Survivor区大小的比值 。设置为8,则两个Survivor区与Eden区的比值为2:8,每个Survivor区占 整个年轻代的1/10。 

第一次新增

-XX:CMSInitiatingOccupancyFraction=70:表示年老代空间到70%时就开始执行CMS,确保年老代有足够的空间接纳来自年轻代的对象。

-XX:+UseCMSInitiatingOccupancyOnly:使用CMSInitiatingOccupancyFraction的值作为old区的空间使用率限制来启动CMS垃圾回收。

-XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=3 -XX:GCLogFileSize=128M:GC日志rotate

-XX:+UseParNewGC:设置年轻代为并发收集。可与CMS收集同时使用。JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值。

-XX:+CMSParallelRemarkEnabled:并发标记,降低标记停顿,1.6以上默认true。 

依据: CMS GC发生时剩余空间到达90%左右,极易发生promotion failed和concurrent mode failure,调整CMSInitiatingOccupancyFraction使CMS提前发生,给从年轻代提升的对象预留足够的空间。

效果:16台机器RS宕机频率由原来2~3天出现一台,下降至一个月出现一次

如上图,老年代使用达到了90%,此时发生promotion failed,需要提前进行CMS GC。

第二次新增

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

-XX:CMSFullGCsBeforeCompaction=0这个参数,指定进行多少次full GC之后,进行内存空间压缩,0是每次都会。

依据:老年代使用70%时CMS正常发生时出现concurrent mode failure,或老年代空间足够时出现promotionfailed,判断是老年代碎片化严重导致,需要对老年代压缩整理。

效果:2台机器RS宕机频率由原来一个月可能出现一台,修改至今一个多月没有出现,也没再出现promotion failed和concurrent mode failure等异常

如上图,CMS时出现concurrentmode failure,但是空余内存空间3GB以上,属于内存碎片化造成的异常。

 

展开阅读全文

没有更多推荐了,返回首页