CMS gc实践调整(续2)

简介:
本以为在上篇定稿的参数后应该能有比较好的表现,然后实际的表现大出我的意料,cms回收触发非常频繁,虽然每次都只是10-50毫秒,但是次数12个小时内能达到180多次,这显然不正常。通过gc日志和jstat可以看到,每次old区还在5%左右就开始进行CMS,此时的perm区也才30%,这两个数字有浮动并且CMS触发的时间上也没有规律,在测试环境和生产环境中都是如此。

    那么最后是怎么解决的呢?其实没有解决。我只是替换了一个参数就没再发生这个现象,上文提到为了避免System.gc()调用引起的full gc,使用了jdk6引入的新参数-XX:+ExplicitGCInvokesConcurrent来让System.gc()并发执行,但是测试表明恰恰是这个参数引起了CMS的频繁发生,去掉这个参数就没有那个奇特的现象。重复检查了代码,并且再次查看了GC日志,没有再发现有System.gc()的调用,我暂时将原因归结于使用了ExplicitGCInvokesConcurrent参数后其他方法触发了CMS,如果有知晓的朋友请留言告知,最后的方案还是彻底禁掉了显式GC调用。最终定稿的参数:

- server  - Xms1536m  - Xmx1536m  - XX:NewSize = 256m  - XX:MaxNewSize = 256m
- XX:PermSize = 64m  - XX:MaxPermSize = 64m  - XX: + UseConcMarkSweepGC
- XX: + UseCMSCompactAtFullCollection  - XX:CMSInitiatingOccupancyFraction = 70
- XX: + CMSParallelRemarkEnabled  - XX:SoftRefLRUPolicyMSPerMB = 0
- XX: + CMSClassUnloadingEnabled  - XX: + DisableExplicitGC
- XX:SurvivorRatio = 8

    删除了+CMSPermGenSweepingEnabled,这个参数在jdk6上跟
- XX: + CMSClassUnloadingEnabled作用重叠了,如果你还跑在jdk5上面,那么应该使用这个参数。救助空间设置为NewSize的1/10,也就是25M左右,让年轻代尽量回收,防止年轻对象跑到年老代过早触发CMS甚至full gc。CMS的触发阀值下降到70%,因为年老代增长较慢,宁愿回收次数多一点,降低长暂停的可能。

    24小时内的某台生产机器的表现,通过jstat观察:
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 
39.70     0.00     5.59    15.15    28.99    20260    326.041      14      0.592    326.633
 
39.70     0.00    65.49    15.15    28.99    20260    326.041      14      0.592    326.633
  
0.00    36.93    19.37    15.16    29.01    20261    326.059      14      0.592    326.650
  
0.00    36.93    93.23    15.16    29.01    20261    326.059      14      0.592    326.650
 
34.04     0.00    59.62    15.17    29.01    20262    326.076      14      0.592    326.668
  
0.00    38.55    12.76    15.19    29.01    20263    326.094      14      0.592    326.686
  
0.00    38.55    65.48    15.19    29.01    20263    326.094      14      0.592    326.686


    CMS两次暂停时间总和在100ms以下,minor gc平均一次执行花了16ms,平均3-4秒发生一次。暂时来看还不错,也许还可以适当调小一下NewSize,加快以下minor gc。

    此次调整总共花了大概一周多的时间,由于经验不足,还是走了不少弯路,幸好最终的结果还可以,也让自己对cms gc有比较深入的了解。我们的系统在周4晚上已经全部更新上线,从内部测试、压测、日常测试、beta测试以来,每个阶段都发现几个隐蔽的问题,在上线后暂时没有再发现问题,证明这个流程还是很有意义的,我过去对流程充满偏见,现在看来是可笑的。总结我在淘宝5个月越来学习到的东西,几个关键词:认真、负责、细心、快乐。

文章转自庄周梦蝶  ,原文发布时间2009-09-26

目录
相关文章
|
6月前
|
算法 Java 程序员
【GC的过程】
【GC的过程】
|
7月前
|
缓存 算法 Java
GC 的三种基本实现方式
GC 的三种基本实现方式
78 1
|
3月前
|
存储 Java
jvm性能调优实战 - 23 模拟Young GC的发生及分析GC日志
jvm性能调优实战 - 23 模拟Young GC的发生及分析GC日志
44 0
|
5月前
|
缓存 算法 Java
JVM CMS GC算法解析
JVM CMS GC算法解析
41 0
|
9月前
|
算法 Java
21-看懂CMS收集器工作机制
年轻代垃圾回收器机制我们都很清楚了,接下来我们介绍最核心的老年代垃圾回收环节。
75 0
21-看懂CMS收集器工作机制
|
9月前
|
前端开发 Java
Java虚拟机 CMS GC 调优解析
随着 JDK 版本的不断升级,其 GC 策略也随之不停革新,从早期的 1.4 到如今的 11(本文仅讨论在线上环境落地规模较大的版本),其对应的 GC 策略也随之由 Serial、Parallel、CMS 演进至当前的 G1 甚至即将落地的 ZGC 。每一次的调整无不是基于环境的适配性以及业务场景特性,无论如何,只要能够基于特定的操作系统内核、物理内存、JDK版本以及业务特性,达到收益最大化,采用何种实现策略都不为过。当然,还是建议大家以官方的推荐为准,基于自己的业务场景进行不断优化调整,这样才能保证万无一失,使得我们的业务能够健康发展。
90 0
|
Arthas 缓存 监控
JVM调优之G1换CMS
SIZE: 进程使用的地址空间,如果进程映射了 100M 的内存,进程的地址空间将报告为 100M 内存。事实上,这个大小不是一个程序实际使用的内存数。
JVM调优之G1换CMS
|
存储 缓存 算法
详述JVM的GC及垃圾回收策略
详述JVM的GC及垃圾回收策略
871 2
详述JVM的GC及垃圾回收策略
|
算法 安全 Java
【JVM性能优化】CMS回收器的Full-GC流程分析以及问题探究
【JVM性能优化】CMS回收器的Full-GC流程分析以及问题探究
535 0
【JVM性能优化】CMS回收器的Full-GC流程分析以及问题探究
|
Java
CMS垃圾回收器的工作流程
CMS垃圾回收器的工作流程
534 0