gc调优实战

Source的内存运行情况

Source作为公司内部代码托管工具，用户通过git的push、pull、clone等操作以及在web端查看代码进行代码对比的操作都将在短时间内产生大量的对象，并且这些对象的存活时间也不会很长。

调优之前的jvm运行情况分析

调优之前jvm使用的垃圾回收策略是新生代老年代均使用parallel Scanvenge，也就是默认策略，堆大小为2G。出现的问题是：

1. 永久代初始内存64M设置过小，运行过程中永久代内存可达到90M
2. Minor gc频繁，说明eden区内存不足
3. Minor gc时间过长，平均一次需要80ms
4. 垃圾收集的并行线程数43个，服务器是8核，线程数偏多
5. Full gc频繁，平均是半个小时一次，一次full gc耗时800ms左右

第一次调优

参数设置：
-XX:+PrintGCDetails
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:ParallelGCThreads=20
-Xmn900m
-XX:SurvivorRatio=1
-XX:PermSize=128m
-Xmx2048m
-Xms2048m
第一次调优新生代收集器改用parnew，parnew收集器不会动态的去调整新生代大小去达到吞吐率要求，但更容易控制。垃圾收集线程数改为20，减少线程之间的切换开销，提升minor gc速度，设置survivor:eden=1:1，永久代初始大小设置为128m，老年代收集器默认是单线程的serial old。同时禁止代码显式GC。
得到的结果是full频率下降很多，这里的原因在于survivor区增大，因为survivor区内存不足而直接进入老年代的情况减少，minor gc频率有所提高，minor gc耗费的平均时间变为此前的一半，频率更高的原因可能在于eden区300m大小偏小，而耗费时间的减少一方面是eden区较小，另一方面则是垃圾收集线程的切换开销减小了。

第二次调优

参数设置：
-XX:+PrintGCDetails
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:ParallelGCThreads=20
-Xmn900m
-XX:SurvivorRatio=2
-XX:PermSize=128m
-XX:MaxTenuringThreshold=10
-Xmx2048m
-Xms2048m
第二次调优修改eden区大小为450m，力图降低minor gc频率，同时设置经过多少次minor gc过后，存活的对象进入老年代，默认值15，调整过后full gc的频率有所提高，minor gc频率仍然偏高，说明eden区还是太小，此外过小的survivor区大小也影响了full gc的频率。

第三次调优

参数设置：
-XX:+PrintGCDetails
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:ParallelGCThreads=8
-Xmn1000m
-XX:SurvivorRatio=2
-XX:PermSize=128m
-XX:MaxTenuringThreshold=10
-Xmx2048m
-Xms2048m
第三次增大年轻代大小到1000m，减少gc时的并发线程数至CPU核数相同，结果是minor gc频率降低，并且每次minor gc时间骤降到16ms左右，十个小时内进行过一次full gc，耗时接近1s。
继续观察出现的问题，由于短暂的出现大量的大对象，造成短时间内大量的minor gc并且由此引发了数次full gc，判断是否是一次“良好”的minor gc可以从本次gc时新生代大小判断，如果大小接近最大值说明引发gc的对象不大，如果当前新生代大小很小，说明出现了大对象，并且该对象很有可能将会由于survivor不够大而进入老年代。
结合三次调优可以发现source jvm的内存空间还不太够。

第四次调优

参数设置：
-XX:+PrintGCDateStamps
-XX:TargetSurvivorRatio=100
-XX:+PrintTenuringDistribution //minor gc后打印分代信息
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled //启用CMS并发标记
-XX:+UseCMSCompactAtFullCollection //启用碎片整理
-XX:CMSFullGCsBeforeCompaction=0 //设置多少次FULL GC过后执行一次碎片整理
-XX:+UseCMSInitiatingOccupancyOnly //启用CMS占比阈值
-XX:CMSInitiatingOccupancyFraction=80 //设置阈值百分比，内存超过该百分比将执行CMS GC
-XX:SurvivorRatio=2
-XX:+PrintGCDetails
-XX:+UseParNewGC
-XX:ParallelGCThreads=8
-Xmn1500m
-XX:+DisableExplicitGC
-XX:PermSize=128m
-XX:MaxTenuringThreshold=10
-Xmx4096m
-Xms4096m
这一次调优是经过了几个参数调整的最终成型结果，有如下一些比较重要的改变

1. 老年代收集器使用CMS，CMS分为多个阶段，其中耗时的阶段都不是stop the world，因此可以显著提高系统响应性能，缺点是采用标记清除算法，因此存在内存碎片问题以及并发模式下的失败问题。内存碎片问题可以通过设置full gc后执行内存整理来解决，这里必须要注意的是CMS GC不是FULL GC，FULL GC停顿的时间会很长，理想情况下如果FULL GC频率超过一天一次，可以考虑在外部通过脚本在凌晨执行一次定时FULL GC以达到清理碎片的效果。并发模式下的失败问题一个显著的原因是垃圾收集的速度已经跟不上对象分配的速度， source针对大代码库的服务器会偶发这个失败问题。
2. -XX:TargetSurvivorRatio=100强调下这个参数，该参数表示survivor区的使用率，如果survivor去的对象大小超过了使用率则会以survivor区age的最大值作为晋升老年代的参考，最终取该参考值以及设置的最大晋升代数的较小值，hot spot默认是50，这里改成100，意思就是对象必须待满足够的代数才能进入老年代，结合-XX:MaxTenuringThreshold=10可知对象需要待满10代。为什么选择10代，这是通过设置-XX:+PrintTenuringDistribution观察存活对象晋升的情况作出的决定（这里并没有经过绝对准确的调研，要想准确的得到更合理的分代门限值可以做一个晋升的统计），实际当中发现大部分对象无法存活超过10代。
3. CMS GC启动阈值-XX:CMSInitiatingOccupancyFraction=80，这个值非常重要，实际情况下可以根据jvm具体情形设置。这里设置为80表示一旦老年代内存空间超过百分之八十将进行CMS GC。预留的空间可以保证在CMS GC的并发阶段新进入老年代的对象可以找到空间进行存储，一旦找不到足够的空间就将产生并发模式错误并触发FULL GC。
   调优之后新生代GC频率下降，时间有所提升，变为20+ms（完全可以接受），老年代GC频率骤降，平均一天一次（非大代码库），高峰期可能一天会出现2-3次，XX:TargetSurvivorRatio=100大大地降低了新生代对象进入老年代的可能性，因为大部分对象存活时间都无法超过10代。
   目前source非大代码库对应的服务器一直使用该配置，运行情况良好，并且比起调优之前性能好了很多。

二、商品接口运行状况

商品接口是印尼平台的基础服务，运行期间大对象不多，查询接口大多也有分页数量的限制。大boss也为关键接口设定了削峰计划——tp99不超过200ms。大多数情况下系统满足该要求，但是偶尔会有超过200ms的情况，一部分是由于查询数据量过大数据库响应和数据组装耗时所致，而另一部分则和jvm有关。
通过观测发现，jvm进行一次young gc耗时在100ms以上，full gc耗时更是达到了1s左右，大概一天一次，部分超过200ms的调用恰恰就在gc的节点上。

调优之前的策略

调优之前使用部署系统默认的垃圾收集策略，即parallel Scanvenge，堆空间2g，出现的问题是：

1. 永久代初始内存64M设置过小
2. Minor gc时间过长，平均一次超过100ms
3. 垃圾收集的并行线程数43个，服务器是2核，线程数偏多
   4 一次full gc耗时1s左右

使用g1进行调优

直接给出最后的调优参数
-xmx2560m
-xmn2560m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:InitiatingHeapOccupancyPercent=60
-XX:ParallelGCThreads=4
-XX:ConcGCThreads=4
-XX:G1ReservePercent=10
-XX:G1MixedGCCountTarget=4
-XX:PermSize=128m
-XX:+UnlockExperimentalVMOptions
-XX:G1NewSizePercent=15
-XX:+PrintAdaptiveSizePolicy
-XX:G1HeapWastePercent=5

调整点如下：

1. 内存最大4g，刚开始给了堆3g，后面发现会出现内存使用率达到99%的情况，因此改为2560m。事实上使用g1官方推荐至少6g，这里条件限制没有办法，可不可以使用cms呢，当然是可以的。
2. 停顿目标为100ms，这是和老大商议的结果，设置过低可能造成g1很频繁的young gc。
3. 启动并发阶段的阈值为60%，刚开始设定为85%，偏高了，存在并发失败导致full gc的可能。
4. 并行收集线程数为4，两核cpu，这个值可以了
5. 并发收集线程数为4，根据mix gc的耗时可动态调整，数量不宜过多。
6. mix gc的次数设置为4，通过几次dump发现老年代里面的垃圾大部分在g1的清理阶段回收了，少部分在mix gc阶段回收。
7. 打印自适应调整的日志，很重要！可以看到调整的原因，对于排查问题很有用
8. 启用实验参数，设置最低新生代比例为15%，未设置时发现g1在老年代中对象越来越多时会压榨年轻代，造成年轻代过小从而young gc频率很高；设置可浪费老年代比例5%，超过5%才进行mix gc；保留内存10%，这个是为了避免对象晋升时的to-space overflow的问题

调优之后的效果：

1. young gc平均耗时不到50ms（包括mix gc）
2. 未出现full gc
3. 一次并发阶段周期为一天
   观察dump文件发现存在大量的char数组，并且这些数组内容一模一样，大小1.15m。g1本身存在一个很大的弊端，即如果一个对象大小超过一个分区的一半则直接进入老年代，对于不到4g的堆空间，默认一个分区大小是1m。这里可以选择将分区大小调整为4m，但是更少的分区数会使得g1的自适应调整能力变弱，还是去代码中寻找。（注：这里还有一种策略是在jdk1.8的情况下使用实验参数设置每次young gc时尝试去回收老年代中的大对象，项目jdk1.7不适用）
   通过查看数组中的字符内容定位到这些数组是由于一个五分钟的定时任务从数据库查询出商品基本属性过后会将属性json化后全部存入redis，json是字符串，字符串内部是char数组，问题找到了。解决方案也很简单，总共3000多条数据，每次1000条数据存入redis，确保一次存入生产的字符串小于0.5m。经过这一次调整，一次并发阶段周期大概是5-6天。

作者：ImushroomT
链接：https://www.jianshu.com/p/2092cc9b6e20
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

作者：ImushroomT
链接：https://www.jianshu.com/p/d89905fc7574
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。