前一篇JVM的恩恩怨怨中,说了对WebSphere优化的关键点——因不同JDK而异。本文将描述IBM JDK下常用参数的设置。
-Xms:最小堆大小
-Xmx:最大堆大小
-Xminf and -Xmaxf:GC(垃圾回收)之后可用空间的最小值最大值
-Xmine and -Xmaxe:堆增长的最小最大值
-Xmint and -Xmaxt:垃圾回收占时间整个运行时间的比例,默认是5%。如果回收时间小于5%,那么它就缩减堆,反之增大。
一般来说只要对Xms和Xmx设置合理,后面的三对不用特别设置。可以看看http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp上heap expasion和heap shrinkage两章的说明,除非有下文的情况:
如果使用大小可变的堆(比如,-Xms 和 -Xmx 不同),应用程序可能遇到这样的情况,不断出现分配失败而堆没有扩展。这就是堆失效,是由于堆的大小刚刚能够避免扩展但又不足以解决以后的分配失败而造成的。通常,垃圾收集周期释放的空间不仅可以满足当前的分配失败,而且还有很多可供以后的分配请求使用的空间。但是,如果堆处于失效状态,那么每个垃圾收集周期释放的空间刚刚能够满足当前的分配失败。结果,下一次分配请求时,又会进入垃圾收集周期,依此类推。大量生存时间很短的对象也可能造成这种现象。避免这种循环的一种办法是增加 -Xminf 和 -Xmaxf 的值。比方说,如果使用 -Xminf.5,堆将增长到至少有 50% 的自由空间。同样,增加 -Xmaxf 也是很合理。如果 -Xminf等于0.5,-Xmaxf 为默认值 0.6,因为 JVM 要把自由空间比例保持在 50% 和 60% 之间,所以就会出现太多的扩展和收缩。两者相差 0.3 是一个不错的选择,这样 -Xmaxf.8 可以很好地匹配 -Xminf.5。如果记录表明,需要多次扩展才能达到稳定的堆大小,但可以更改 -Xmine,根据应用程序的行为来设置扩展大小的最小值。目标是获得足够的可用空间,不仅能满足当前的请求,而且能满足以后的很多请求,从而避免过多的垃圾收集周期。-Xmine、-Xmaxf 和 -Xminf 为控制应用程序的内存使用特性提供了很大的灵活性。
摘自Java性能优化的策略和常见方法
所以在应用正式上线的头一段时间,最好把GC日志打开,观察一下堆(heap)的增长(expasion)和收缩(shrinkage)。最佳的情况就是,每次回收后可用的堆大小占整个堆的50%左右。如果回收后才腾出30%不到的可用空间,那就该再调整一下上述的参数了。下图看起来直观一点,使用-verbose:size参数可以查看当前的默认值。
那为何不把Xms和Xmx设置成一样大,就像SUN的JDK所推荐的那样?
Using the same values is not usually a good idea, because it delays the start of garbage collection until the heap is full. The first time that the Garbage Collector runs, therefore, becomes a very expensive operation. Also, the heap is more likely to be fragmented and require a heap compaction. Again this is a very expensive operation.……
If the Garbage Collector cannot find enough garbage, it runs compaction. If the Garbage Collector finds enough garbage, or any of the other conditions for heap expansion are met , the Garbage Collector expands the heap.
因为IBM JDK采用的是标记(mark)-扫描(sweep)-标记-……-扫描-紧凑排列(compact),如果还不能提供足够的空间,扩展堆(expasion)。依次循环,直到达到最大堆大小。每次扩展前,那些长存的对象就被调整到堆的底部,每次扩展后需要再动的量就很少。所以如果把Xms设置成和Xmx一样,那么扫描和紧凑排列这么一个充满内存碎片的大堆的开销将大大高于从小扩展堆的开销。
The overheads of expanding the heap are almost trivial compared to the cost of collecting and compacting a very large fragmented heap.
这是由于IBM的GC特点造成的,而SUN的JDK采用的是分代回收的策略,所以就没有这种情况,反而会受益于堆大小一致。不过这么说起来,用了-Xgcpolicy:gencon,就应该把最小堆最大堆设置成一样咯。
在Gencon回收策略下,可以通过-Xmn来设置婴儿区域(Nursery或者叫young)的大小,通过-Xmo来设置长存区(tenured或者old)的大小。注意-Xmn不能和-Xmns/-Xmnx参数一起使用,-Xmo不能和-Xmos/-Xmox一起使用,否则会报错。前者就是把年轻代和长存代的大小固定了,而后两者就是设定两个部分最大最小的范围,默认情况下:
-Xmns是-Xms的25%或者64M(在JDK 5.0中默认是25%)
-Xmnx是-Xmx的25%或者64M(同上)
-Xmos是-Xmx减去-Xmns的大小
-Xmox是和-Xmx一样大
可见默认的年轻代太小了,生产环境中有必要改大一点。因为年轻代使用的是复制策略,所以回收速度相当快(minor gc),而长存代使用的是和optavgpause 策略相似的方式进行并发标志、扫描策略,回收速度比较慢(major gc)。理想情况是minor gc和major gc的比值在1:1010:1左右。(可以通过GC日志查看回收的区域)
gencon中年老期限(Tenure age)和倾斜比率(Tilt ratio)这两个参数是JVM自己动态调整的。
针对固定对象问题(Pinned Objects),使用-Xk -Xp参数设定kCluster和pCluster,Avoiding Java heap fragmentation with Java SDK V1.4.2. 或者我这篇IBM JDK的Java堆空间的碎片问题。
一些不常用的参数:
-Xloainitial<percentage> -Xloamaximum<percentage> :调整大对象区域(Large Object Area)的大小。分配总是先在SOA(Small Object Area)中分配,如果没有空间并且需要分配的大小大于64K,那么分配到LOA。默认情况下为-Xloainitial0.05 (5%),-Xloamaximum0.5 (50%),如果你的程序确实需要分配许多大对象的话(大于64K),那么可以调整LOA的初始百分比。
以上两点可以参考我这篇IBM JDK的Java堆空间的碎片问题,获得更详细的解释。
总结一下来说,对于optthruput和optavgpause,设置恰当的最大堆和最小堆,设置-Xk和-Xp避免碎片问题,如果程序需要分配大对象较多,那么调整一下LOA的大小;对于gencon,可以调大最小堆和最大堆接近,调整young区域的大小,LOA也可以视情况调整。subpool一般用不到,就不去研究了。
一些另外的信息
Default settings for the JVM
http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/diag/appendixes/defaults.html
JVM environment settings
http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/diag/appendixes/env_var/env_jvm.html
默认的Heapdumps是关闭的,调试的时候记得打开;默认的Javadumps on out of memory和Heapdumps on out of memory都是开启的,但是默认的dump位置是profile的所在目录,最好在管理控制台java进程中把IBM_HEAPDUMPDIR和IBM_JAVACOREDIR设置到别的目录,防止dump内容把WAS的文件系统撑爆,影响正常业务使用。
在Windows机器上,如果内存大于4G,记得开启/3GB参数,这样可以使JVM Heap可以设置的更大一些,接近2G-1,(其它的三部分可以扩展到另外的1G上去),但一般最大不超过1.7G。
更详细内容,可见http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp
或者下载dig60 http://www.ibm.com/developerworks/java/jdk/diagnosis/查看JVM这一块
Sun的JDK配置,可以参考JAVA性能优化—Sun Hotspot JDK JVM参数设置
分享到:
相关推荐
6. **conf目录**(可能包含):存储配置文件,如java.security用于设置安全策略,以及jvm.options用于配置JVM参数。 配置IBM JDK 1.6到IDE(如Eclipse、IntelliJ IDEA)的过程大致如下: 1. **设置环境变量**:在...
IBM JDK与Oracle JDK相比,虽然它们都实现了Java标准,但IBM JDK通常在性能、内存管理和安全性方面有其独特的优化。IBM JDK 1.7的64位版本尤其适用于需要处理大量数据或需要高效内存管理的应用场景。 在安装和配置...
总之,理解和掌握JVM参数优化、运行时数据区的结构以及垃圾回收机制,是每个Java开发者提高应用性能、避免内存泄漏和优化系统资源利用率的关键。通过细心的调整和不断的实践,可以打造出更加高效稳定的Java应用程序...
在安装IBM JDK6 SR15时,用户应遵循官方文档的指导,注意系统需求,例如硬件配置、操作系统版本等,并根据实际环境设置合适的JVM参数。同时,进行充分的测试以确保应用程序在新的JDK环境下能够正常运行。
总结来说,IBM JDK 1.5.0是IBM针对Java SE 5.0标准的一个实现,它在保持与标准兼容的同时,提供了许多性能优化和特色功能,尤其适合在Windows 32位系统上的企业级Java应用开发。对于开发者而言,掌握IBM JDK的使用能...
通过细致的监控和分析,结合适当的JVM参数设置,可以有效地提升WebSphere的运行效率,减少因内存管理问题引发的性能瓶颈。同时,了解不同操作系统和JDK版本对JVM行为的影响也是优化过程中不可忽视的一环。
不同公司根据JVM规范实现了自己的JRE(Java运行环境),如Oracle的Hotspot JDK、IBM的JDK、阿里巴巴的淘宝JDK等。Oracle通过收购Sun和BEA,将Jrockit和Hotspot JDK整合到了一起,提供了-client和-server两种启动选项...
4. **JVM参数设置** - `-XX:MaxPermSize`:在JDK 1.7及更早版本中,用于设置永久代的最大大小,防止类信息溢出。 - `J9` 和 `JRockit`:IBM的JVM实现,支持不同的垃圾收集器和内存管理策略,如J9有自己的 perm gen...
6. **JVM优化**:JVM提供了多种工具和选项来查看和调整其行为,如`javap`用于反汇编字节码,`-verbose:gc`用于输出GC日志,`-XX:`系列参数可以调整JVM的内存设置、垃圾收集策略等。 了解JVM的底层原理对于Java...
7. **优化建议**:根据分析结果,我们可以调整代码,减少不必要的对象创建,优化数据结构,或者调整JVM参数,如增大堆大小,设置合理的垃圾收集策略等。 8. **持续监控**:解决问题后,应持续监控应用的内存和线程...
这包括了解如何调整JVM参数,如-Xms和-Xmx以控制内存分配,以及如何利用IBM JDK特有的性能监控工具来分析和优化应用程序。 总的来说,"java7_64_AIX.rar"提供了一种在AIX系统上运行和开发Java 7应用的解决方案。...
- 调优涉及内存大小设置、垃圾收集器选择、JVM参数调整等,目的是提高性能并避免内存问题。 8. JVM简单理解: - Java栈:每个线程都有自己的Java栈,用于存储方法调用的状态。 - 堆:所有对象实例都在堆中分配,堆...
Java虚拟机(JVM)是Java程序的核心组成部分,它为Java...总的来说,理解JVM的工作原理、内存管理、性能优化以及其在跨平台和跨语言方面的角色,对于Java开发者来说至关重要,这有助于编写出更高效、稳定的应用程序。
Sun JDK是由Java的原始开发者Sun Microsystems公司发布的版本,IBM JDK则由IBM公司提供,而BEA Jrockit专为运行大型企业级应用而优化。随着版本的更新和改进,JDK1.4.2是一个较早的版本,但也为理解后续版本打下了...
在Java应用程序中,可以通过设置JVM参数`-XX:+HeapDumpOnOutOfMemoryError`来配置当出现内存溢出错误时自动创建堆转储。也可以使用`jmap`命令(在JDK工具集中)手动生成堆转储。 IBMHeapAnalyzer的运行方式是在...
综上所述,理解和应用JVM GC原理以及heapsize调优的方法对于Java应用程序的性能优化至关重要。了解垃圾回收机制、合理设置堆内存大小、选择合适的垃圾回收算法,以及诊断和解决GC性能问题,都是进行性能调优时需要...
- **IBM JDK**:由 IBM 开发,其 JVM 性能在某些方面优于 Sun JDK。 - **BEA JRocket**:专为 x86 平台优化的服务端 JDK。 - **GNU Classpath**:开源项目,提供了一个与 Sun JDK 兼容的实现。 - **下载与安装**...
IBM的JDK因包含性能更优的JVM而受到好评,而Jrocket则在x86平台上提供更好的服务端运行效率。不过,初学者通常应从Sun JDK入手。 ##### 3、JDK的下载与安装 最新版本的JDK可从Sun的官方网站下载,下载链接为...