优酷土豆资深工程师:GC 调优实战

前情概要

对于线上高并发、高吞吐的Java web服务来说,长时间的GC暂停(也叫 stop- the-world)会严重影响系统吞吐、稳定性和用户体验。下文是我们的一个真实线上web系统针对GC调优过程的一个总结。这个系统在调优前,经常会反映有超秒的GC暂停问题,这种GC问题可能会导致调用方(可能是上层服务调用方、负载均衡层或客户端)阻塞、超时、甚至雪崩的情况。我们在系统资源不变的情况下,经过多轮调优,大幅降低了GC的频率和暂停时间。

前期准备

1、统计应用数据(峰值TPS、平均TPS,每秒平均分配内存大小、每个请求的平均分配内存大小)
2、统计GC分配、回收内存的数据(MinorGC、FullGC停顿时长,平均多长时间触发一次GC,每次Eden->Old的平均晋升大小等)
3、搭建压力测试环境
4、模拟线上真实用户行为及相应压力(记录用户访问的accesslog作为压力测试源,使用的压力测试软件为http_load和httperf)

第一轮调优

1、 尝试使用JDK7的G1回收,在安装JDK7时失败,原因是操作系统版本必须是 RedHat5.5+/CentOS5.5+ 暂时不准备升级操作系统,所以放弃JDK7 G1;

2、改为使用JDK6 Update26版本的G1回收。设置最大回收时间为40ms,通过12小时的观察,发现有大量超时,感觉G1在JDK6上还不够成熟,所以决定暂时放弃G1,改为ParallelGC;

3、使用ParallelGC后,压力测试发现每次MinorGC的耗时降低到40ms左右(以前是200ms以上),但每隔3小时就会有一次FullGC发生,每次FullGC耗时3~4秒;

4、由于FullGC造成的应用暂停在这个应用中是不能接受的。所以放弃ParallelGC,改为使用CMSGC。

第二轮调优

1、观察 gcutil 发现PermSpace接近100%,调大PermSize 和 MaxPermSize;

2、调整-Xms和-Xmx相等(如果Xms小于Xmx,则应用启动初期老生代相对较小,会导致CMS GC更加频繁);

3、尝试优化每次ParNew的时长(优化前每次在200ms以上):

增加“-XX:+PrintTenuringDistribution”参数观察gc.log,发现对象在SurvivorSpace中的age过多,会导致大量老对象在新生代无法晋升到老生代。而JVM在ParNewGC时分析这些老对象的引用关系是非常耗时的。观察MaxTenuringThresh-old 和 TargetSurvivorRatio 设置的过大,所以将 MaxTenuringThreshold 值调小为15即达到优化目的(优化后每次ParNew在20~40ms之间)。并且为了提高SurvivorSpace的利用率,将TargetSurvivorRatio设置为100( 代表强制GC关闭动态调整MaxTenuringThreshold,这个参数设置为100会略为激进,增加了Survivor区使用率的同时,降低了Survivor区应对突发流量的承载能力,不同应用可以看情况调整)。

4、尝试优化ParNew之间的间隔时间(优化前3~4秒一次):观察gc.log发现每次ParNew后大约有不到780MB的存留对象,希望这些对象尽量活在SurvivorSpace里,并且同时又要保证ParNew的时间间隔,所以在Xmx和SurvivorRatio不变的情况下,将Xmn扩大到7800MB。(因为SurvivorRatio=8,所以整个EdenSpace需要780*10=7800MB)

5、再次观察优化后的GC情况(gcutil),发现由于大量对象都在EdenSpace消亡,所以OldGen的晋升比率极低(0.01%~0.02%),所以可以考虑增大CMSInitiatingOccupancyFraction以提高OldGen的利用率,降低CMS GC的触发频率(增大到80%)。

6、去掉CMSFullGCsBeforeCompaction(去掉后默认为0,表示每次FullGC后都会进行压缩碎片整理)。因为CMS GC导致的内存碎片必须清除,否则OldGen的利用率会降低。

第三轮调优

运营一段时间后,发现CMSGC超过一秒的情况非常多(图中箭头指向):
优酷土豆资深工程师:GC 调优实战_第1张图片

GC日志:

优酷土豆资深工程师:GC 调优实战_第2张图片

可以看出,在remark中的Rescan阶段耗费了1.57秒,并且这个过程是会导致应用暂停的。问题定位在了Rescan阶段。


发现在Rescan时新生代过大(4313641 K(7188480 K)),是导致Rescan慢的关键原因,如果能尽量保持新生代很小的时候就终止preclean阶段,就可以控制住在Rescan时新生代的大小。查看JVM参数发现-XX:CMSScheduleRemarkEdenPenetration的意思是当新生代存活对象占EdenSpace的比例超过多少时,终止preclean阶段并进入remark阶段。这个参数的默认值是50%,按照现在的配置,就是7800m*50%=3900m左右,所以更改此参数设置为: -XX:CMSScheduleRemarkEdenPenetration=1

进行压力测试,发现remark阶段的耗时确实降低了不少,说明优化有效。

第四轮调优

运行几天后观察GC日志(2011-09-05),发现每隔100000秒的CMSGC的峰值情况确实大大降低了,但是还是偶尔有超过1~2秒的CMSGC情况:
优酷土豆资深工程师:GC 调优实战_第3张图片

GC日志:

优酷土豆资深工程师:GC 调优实战_第4张图片

发现concurrent-abortable-preclean阶段超过了-XX:CMSMaxAbortablePrecleanTime 设置的最大值10秒,所以强制终止了preclean阶段而进入remark阶段。而这段时间的两次ParNew之间的间隔了17秒之多。希望的是在preclean阶段产生一次MinorGC,所以将preclean的最大时长调整为30秒: -XX:CMSMaxAbortablePrecleanTime=30000


第五轮调优

运行一段时间后,发现居然出现了FullGC,大概在3~5天左右出现一次,以下是FullGC时的日志:
优酷土豆资深工程师:GC 调优实战_第5张图片
发现在443310秒有promotion failed出现(新生代晋升到老生代空间不足导致的FullGC),但是此时的OldGen可以算出还剩1.45G的空间(5324800K-3871691K=1453109K),而根据gcLogViewer的统计,每次MinorGC后平均新生代晋升到老生代的内存大小仅为58K。所以并不是OldGen空间不够,而是OldGen的连续空间不够造成的promotion failed。

换句话说,是由于OldGen在距离上次CMSGC后,又产生了大量内存碎片,当某个时间点在OldGen中的连续空间没有一块足够58K的话,就会导致的promotion failed。以下是Sun针对这个问题的说明:

引用

Sometimes we see these promotion failures even when thelogs show that there is enough free space in tenured generation. The reason is'fragmentation' - the free space available in tenured generation is notcontiguous, and promotions from young generation require a contiguous freeblock to be available in tenured generation. CMS collector is a non-compactingcollector, so can cause fragmentation of space for some type of applications.In his blog, Jon talks in detail on how to deal with this fragmentationproblem: 链接
或者参考我的另一篇blog: 链接


考虑如果能够缩短CMSGC的周期,保证在出现promotion failed之前就进行CMSGC,就可以避免这个问题了。所以考虑将新生代空间缩小(相对来说就增加了老生代的空间),并且将CMSGC触发比率降低,同时保证Survivor空间不变。所以优化参数改动如下:

引用

-Xmn7800m -> -Xmn7020m
-XX:SurvivorRatio=8 –> -XX:SurvivorRatio=7
-XX:CMSInitiatingOccupancyFraction=80 ->
-XX:CMSInitiatingOccupancyFractio=70 

第六轮调优

上面的调优保持系统稳定运行了很长时间后,突然有一台机器出现大量FullGC,观察gc.log发现是由于持久带满造成的:

d4d249c1ae69ddc008b3a758e41fc609f61f4a5e

应对的方法为加大持久带,并让持久带也使用CMSGC方式回收:

引用

修改:

-XX:PermSize=64m  ->  -XX:PermSize=200m
-XX:MaxPermSize=128m -> -XX:MaxPermSize=200m 

增加:

-XX:+CMSClassUnloadingEnabled

 另外,对于持久带满的观测方法,可以参考Rednaxelafx给我的回答:  链接

总结

精细化的GC调优是需要耐心和时间的,往往一轮调优要经过GC数据集、分析、调整参数、压力测试、灰度发布、最终上线这几步,上线一段时间后,通过监控发现有新的GC问题,可能又会需要再一轮的调优。而且系统版本的迭代、对象生命周期的变化、线上流量和服务依赖的变化,都可能会对GC频率和时间有影响。所以对于线上的重点项目,建议每次大版本上线前都能建立一个GC监控、收集和调优的意识,最大程度上规避GC对系统带来的风险。

优化后整体参数

-Xmx13000m
-Xms13000m
-Xmn7020m
-Xss256k
-XX:PermSize=200m
-XX:MaxPermSize=200m
-XX:ParallelGCThreads=20
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:SurvivorRatio=7
-XX:TargetSurvivorRatio=100
-XX:MaxTenuringThreshold=15
-XX:CMSInitiatingOccupancyFraction=70
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+UseCMSCompactAtFullCollection
-XX:CMSMaxAbortablePrecleanTime=30000
-XX:CMSScheduleRemarkEdenPenetration=1
-XX:+CMSClassUnloadingEnabled
-server
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:./log/gc.log 


作者简介:高嵩,优酷土豆大数据基础平台资深工程师,热衷于高并发、高可用、分布式领域。热爱开源,为人和善,乐于分享。


                                                    中生代技术分享群微信公众号

                                                da9312524921e637b684eed7bf3249db58f7badc


你可能感兴趣的:(优酷土豆资深工程师:GC 调优实战)