一次Java垃圾收集调优实战(转载)
2008-07-10 17:27
555 查看
7月份的语言排行榜已经出来了,java仍然是主流之一。现在java的应用越来越多,也越来越大,但是,就个人而言对Java的性能还是不甚满意。写一下数据挖掘算法时总是显得力不从心,也许是本身功力不够吧。。。
对于此,除了加强自己的算法功底外,其实还有一个比较容易的解决办法:提高jvm的性能。个人认为这其实是java的web项目调优的一个很好的解决方案。
下面转了一篇文章,个人觉得不错,也特别感谢作者的分享:)
原文地址:http://blog.csdn.net/calvinxiu/archive/2008/07/09/2627794.aspx
原文如下:
编写对GC友好,又不泄漏的代码(花钱的年华)
JVM调优总结
JDK 6所有选项及默认值
初始效果:1g堆内存的新生代约60m,minor gc约5-20毫秒,full gc约130毫秒。
已默认无需配置的参数: -XX:+UseAdaptiveSizePolicy(动态调整新生代大小)
初始效果:1g堆内存的新生代约90-110m(动态调整),minor gc约5-20毫秒,full gc有无UseParallelOldGC 参数分别为1.3/1.1秒,差别不大。
另外-XX:MaxGCPauseMillis=100 设置minor gc的期望最大时间,JVM会以此来调整新生代的大小,但在此测试环境中对象死的太快,此参数作用不大。
在被压测的Mule 2.0应用里,每秒都有大约400M的海量短命对象产生:
因为默认60M的新生代太小了,频繁发生minor gc,大约0.2秒就进行一次。
因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0,存活的临时对象不经过Survivor区直接进入年老代,不久就占满年老代发生full gc。
对这两个参数的调优,既要改善上面两种情况,又要避免新生代过大,复制次数过多造成minor gc的暂停时间过长。
使用-Xmn调到1/3 总内存。观察后设置-Xmn500M,新生代实际约460m。(用-XX:NewRatio设置无效,只能用 -Xmn)。
添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小,观察后设置-XX:MaxTenuringThreshold=5。
优化后,大约1.1秒才发生一次minor gc,且速度依然保持在15-20ms之间。同时年老代的增长速度大大减缓,很久才发生一次full gc,
参数定稿:
最后服务处理速度从1180 tps 上升到1380 tps,调整两个参数提升17%的性能还是笔很划算的买卖。
对于此,除了加强自己的算法功底外,其实还有一个比较容易的解决办法:提高jvm的性能。个人认为这其实是java的web项目调优的一个很好的解决方案。
下面转了一篇文章,个人觉得不错,也特别感谢作者的分享:)
原文地址:http://blog.csdn.net/calvinxiu/archive/2008/07/09/2627794.aspx
原文如下:
1 资料
JDK5.0垃圾收集优化之--Don't Pause(花钱的年华)编写对GC友好,又不泄漏的代码(花钱的年华)
JVM调优总结
JDK 6所有选项及默认值
2 GC日志打印
GC调优是个很实验很伽利略的活儿,GC日志是先决的数据参考和最终验证:-XX:+PrintGC Details -XX:+PrintGCTimeStamps(GC发生的时间) -XX:+PrintGCApplicationStoppedTime(GC消耗了多少时间) -XX:+PrintGCApplicationConcurrentTime(GC之间运行了多少时间)
3 收集器选择
CMS收集器:暂停时间优先
配置参数:-XX:+UseConcMarkSweepGC 已默认无需配置的参数:-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(full gc时压缩年老代)初始效果: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/1.1秒,差别不大。
另外-XX:MaxGCPauseMillis=100 设置minor gc的期望最大时间,JVM会以此来调整新生代的大小,但在此测试环境中对象死的太快,此参数作用不大。
4 调优实战
Parallel收集高达1秒的暂停时间基本不可忍受,所以选择CMS收集器。在被压测的Mule 2.0应用里,每秒都有大约400M的海量短命对象产生:
因为默认60M的新生代太小了,频繁发生minor gc,大约0.2秒就进行一次。
因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0,存活的临时对象不经过Survivor区直接进入年老代,不久就占满年老代发生full gc。
对这两个参数的调优,既要改善上面两种情况,又要避免新生代过大,复制次数过多造成minor gc的暂停时间过长。
使用-Xmn调到1/3 总内存。观察后设置-Xmn500M,新生代实际约460m。(用-XX:NewRatio设置无效,只能用 -Xmn)。
添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小,观察后设置-XX:MaxTenuringThreshold=5。
优化后,大约1.1秒才发生一次minor gc,且速度依然保持在15-20ms之间。同时年老代的增长速度大大减缓,很久才发生一次full gc,
参数定稿:
-Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=5 -XX:+ExplicitGCInvokesConcurrent
最后服务处理速度从1180 tps 上升到1380 tps,调整两个参数提升17%的性能还是笔很划算的买卖。
相关文章推荐
- 一次Java垃圾收集调优实战
- 一次Java垃圾收集调优实战
- 一次Java垃圾收集调优实战
- 一次Java垃圾收集调优实战
- GC - 一次Java垃圾收集调优实战
- 一次Java垃圾收集调优实战
- 优化JVM参数提高eclipse运行速度及Java垃圾收集调优实战
- Java垃圾收集调优实战
- Java垃圾收集调优实战
- 【Java垃圾收集调优实战】
- Tomcat中Java垃圾收集调优
- Java的内存结构和垃圾收集图解【转载】
- Java垃圾收集调优
- 深入理解java虚拟机(六):java垃圾收集分析实战(内存分配与回收策略)
- 深入理解java虚拟机(六):java垃圾收集分析实战(内存分配与回收策略)
- Java的内存结构(Memory Structure)和垃圾收集(Garbage Collection)图解 (转载)
- Tomcat中Java垃圾收集调优
- Tomcat中Java垃圾收集调优
- Tomcat中Java垃圾收集调优
- 【转载】Java GC(垃圾收集)