本文主要根据这篇PDF(GCTuningGuidelines)写成。
首先是JDK1.5引入的新功能 Ergonomic Settings(自动优化的参数)
对于有2块CPU和2GB内存及更佳配置的服务器,Sun的hotspot jdk默认设置了如下参数:
我在网上发现了这篇文章,也是根据那篇PDF写的,基本都翻译过来了,那我就不再做造轮子的过程了。有些自己的想法会用红色标出。
摘自 http://unixboy.javaeye.com/
原文链接 JVM调优总结 -Xms -Xmx -Xmn -Xss
典型设置(例子中的堆分配的都比较大,注意自己平台的限制,下文同):
-Xms3550m:设置JVM促使内存为3550m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存(就是收缩和扩张,分代回收加上Sun内存分配的算法,避免了IBM JDK最小堆和最大堆一样上的缺陷,但是这对-Xms和-Xmx的设置有了更高的要求,应该是多次试验确定一个合适的大小)。
-Xmn2g:设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。从下图,应该可以看到整个堆大小=年轻代大小 + 年老代大小,Xms和Xmx不包括Perm Size。
-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值。设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概率。下面要介绍的CMS(并发)收集器,SurvivorRatio默认为1024 MaxTenuringThreshold默认为0,可以手动调整,降低年老代的回收压力,即照顾到吞吐率,又关注到相应时间。
典型配置:
-XX:ParallelGCThreads=20:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。应该等于或者小于cpu数量(核),否则没有意义,而当服务器的CPU数小于等于2时,用并发收集和串行收集效率一样。
典型配置:
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值。
-XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩。可能会影响性能,但是可以消除碎片
34.702: [GC {Heap before gc invocations=7:
def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
to space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
to space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)
tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs]
四、调优总结
减少年轻代和年老代花费的时间,一般会提高应用的效率
五、PDF中提到的另外一些参数
-XX:+AggressiveOpts:作用如其名(aggressive),启用这个参数,则每当JDK版本升级时,你的JVM都会使用最新加入的优化技术(如果有的话)
-XX:+UseBiasedLocking:不是很理解,请自行阅读http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2.5
五、参考资料
Java HotSpot VM Options
Java Tuning White Paper
Diagnosing a Garbage Collection problem
J2SE 5.0 Performance White Paper
Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine
Garbage Collector Ergonomics
Can anyone help me understand UseAdaptiveSizePolicy flag?
备注:
本文转载自:http://www.hashei.me/2009/05/tuning-the-sun-hotspot-jdk.html