CONAN ZONE

你越挣扎我就越兴奋

BlogJava 首页 新随笔 联系 聚合 管理
  0 Posts :: 282 Stories :: 0 Comments :: 0 Trackbacks

1 资料

2 GC日志打印

  GC调优是个很实验很伽利略的活儿,GC日志是先决的数据参考和最终验证:

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps(GC发生的时间) -XX:+PrintGCApplicationStoppedTime(GC消耗了多少时间) -XX:+PrintGCApplicationConcurrentTime(GC之间运行了多少时间)

3 收集器选择

CMS收集器:暂停时间优先

   配置参数:-XX:+UseConcMarkSweepGC
   已默认无需配置的参数:-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(FullGC时压缩年老代)

   初始效果:1G堆内存的新生代约60m,minor gc约5-20毫秒,full gc约130毫秒。

Parallel收集器:吞吐量优先

    配置参数: -XX:+UseParallelGC -XX:+UseParallelOldGC(Parallel收集年老代,从JDK6.0开始支持)

    已默认无需配置的参数: -XX:+UseAdaptiveSizePolicy(动态调整新生代大小)

    初始效果:1G堆内存的新生代约90-110m(动态调整),minor gc约5-20毫秒,full gc没有UseParallelOldGC 参数约 1.3秒,有UseParallelOldGC参数约1.06秒,差别不大。

    另外-XX:MaxGCPauseMillis=100 设置期望minor gc的最大时间,JVM会以此来调整新生代的大小,但在此测试环境中对象死的太快,此参数作用不大。

4 调优实战

      Parallel收集高达1秒的暂停时间基本不可忍受,所以选择CMS收集器。

      不知为何在被压的Mule 2.0应用里,每秒都有大约400M的海量短命对象产生:

  1. 因为默认60M的新生代太小了,频繁发生minor gc,大约0.2秒就进行一次。
  2. 因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0,存活的临时对象不经过Survivor区直接进入年老代,不久就占满年老代发生full gc。

     对这两个参数进行调优,既要改善上面两种情况,又要避免新生代过大,复制次数过多造成minor gc的暂停时间过长。

  1. 使用-Xmn调到1/3 总内存。比较后设置-Xmn500m,新生代实际约460m。(-XX:NewRatio参数无效)。
  2. 添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小,观察后设置-XX:MaxTenuringThreshold=5。

      优化后,大约1.1秒才发生一次minor GC,同时年老代的增长速度大大减缓,预计几个小时才会发生一次GC,而minor gc速度依然保持在15-20ms之间。

      参数定稿:

 -Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC   -XX:MaxTenuringThreshold=5  -XX:+ExplicitGCInvokesConcurrent

      最后服务处理速度从1180 tps 上升到1380 tps,调整两个参数提升17%的性能还是笔很划算的买卖。

posted on 2008-07-09 19:07 CONAN 阅读(220) 评论(0)  编辑  收藏 所属分类: J2SEJAVA