JVM的恩恩怨怨-WebSphere性能优化

WebSphere优化中不得不提的是对JVM的优化，OutOfMemory、GC时间太长太频繁、内存碎片、大对象问题……虽说JVM运行效率如何很大程度是和代码有关，但是恰当的参数设置还是可以避免很多问题。因为在JAVA程序中，垃圾回收（Garbage Collection——GC）是内存发生瓶颈的主要因素（在程序没有问题的情况下）。

但是JVM的优化（也就是优化GC）是一个很令人头疼的活。调整JVM需要根据不同的平台分别对待，如果不了解直接Google一个参数加上无法生效事小，适得其反就不好了。在 Sun ™Solaris™ 和 HP-UX 平台上，WebSphere使用的是Sun和HP提供的JDK，而所有其他平台，WebSphere提供的是IBM JDK。所以优化参数主要区别在IBM JDK和非IBM JDK上，Sun和Hp环境下的优化方案基本能共享。

通用配置

          GC优化的关键是降低频率（frequency）和减少持续时间（duration）。但是两者此消彼长，所以平衡一个恰当的值十分关键。频率和堆的大小和分配增长速度有关，而持续时间则和堆大小和堆中对象的多少有关。由此可以看出最先要考虑的就是堆的大小。

          最大堆、最小堆设置：现在32位的堆，一般设置为256～512M或者512～1024M，但是

       对于不同的应用程序，最优化堆大小的设置都有可能不同。如果堆设置较大，可能导致 GC 的次数变少，但每次 GC 所花的时间很长，从而导致系统的处理能力抖动很大。此外如果堆设置过大，会占用过多的内存，使内存资源耗尽，从而会频繁的进行 IO 操作来使用虚拟内存。 如果堆设置较小，可能导致 GC 变的频繁，但每次 GC 所花的时间不会太长，每次 GC 对系统的性能影响相对也会小些。但是如果堆设置过小， 会使得对象可分配空间变小，从而会频繁的 GC 来释放内存空间，而每次 GC，都会耗用一定的系统资源。因此，要通过试验和监控数据，设法使的我们所设置的堆大小能够使得系统运行最优化。

          具体合适的值，可以启用-verbose:gc来观察。一般良好的堆大小，要让回收频率保持在10秒左右，而一次的full gc回收时间在1到2秒之内（一般的回收时间更短才好）。要注意的是，对于32位的JDK，在Windows环境下单个堆不要超过1.7G，AIX平台不要超过3.2G。下面摘自 出色的“清洁工具” ― 理解 IBM Java 垃圾收集器，第一部分：: 对象分配

 

问题	建议措施
在堆达到稳定状态以前，GC 的频率太高。	使用 verbosegc 确定处于稳定状态的堆大小并将 -Xms 设置成这个值。
堆被完全扩展并且占用率大于 70%。	增加 -Xmx 值使堆占用率不超过 70%。为了获取最佳性能，尝试确保堆从不换页。物理内存应该能容纳最大的堆大小（如果可能）。
占用率为 70% 时，GC 的频率过大。	更改 -Xminf 的设置。缺省值是 0.3，它将通过扩充堆来尝试维持 30% 可用空间。设置为 0.4 将可用空间目标增加到 40%，从而降低 GC 的频率。
暂停时间过长。	尝试使用 -Xgcpolicy:optavgpause （在 1.3.1 中引入），它在堆占用增加时减少暂停时间并且使它们更一致。在吞吐量方面要付出代价。代价是变化的，大约在 5% 左右。

确定了堆大小，接下来要考虑的是

GC的策略

IBM JDK（1.5）下WebSphere首先要了解的是4个Policy：

IBM SDK 5.0 中的 GC 策略

针对吞吐量进行优化
-Xgcpolicy:optthruput（可选）
默认策略。对于吞吐量比短暂的 GC 停顿更重要的应用程序，通常使用这种策略。每当进行垃圾收集时，应用程序都会停顿。

针对停顿时间进行优化
-Xgcpolicy:optavgpause
通过并发地执行一部分垃圾收集，在高吞吐量和短 GC 停顿之间进行折中。应用程序停顿的时间更短。

分代并发
-Xgcpolicy:gencon
以不同方式处理短期存活的对象和长期存活的对象。采用这种策略时，具有许多短期存活对象的应用程序会表现出更短的停顿时间，同时仍然产生很好的吞吐量。

子池 （一般平台用不到）
-Xgcpolicy:subpool
采用与默认策略相似的算法，但是采用一种比较适合多处理器计算机的分配策略。建议对于有 16 个或更多处理器的 SMP 计算机使用这种策略。这种策略只能在 IBM pSeries® 和 zSeries® 平台上使用。需要扩展到大型计算机上的应用程序可以从这种策略中受益。

其中optthruput是默认的IBM JDK GC策略，我觉得不是很适合一般电子商务的情况。因为它的GC停顿时间是三种策略里最长的，而且对于频繁分配短生命周期、小对象的应用来说，很容易就产生了内存碎片，虽然标志-扫描-紧凑排列（mark-sweep-compact）的第三个阶段“紧凑排列”可以消除碎片，但是这种动作开销很大。一般需要设置P cluster、K cluster参数来减少碎片Avoiding Java heap fragmentation with Java SDK V1.4.2. （这个参数在1.5中也适用）

optavgpause是以一点吞吐量的牺牲（官方说是5%）换来响应时间的提高，用并发标记（JDK1.4）外加并发扫描（JDK1.5引入）的方式来减少GC “Stop the world”的时间。

但一般而言，我都是设置成-Xgcpolicy:gencon ，gencon就是我们常说的“分代回收”策略，在HP和SUN的JDK实现中是默认的回收策略。这篇文章Java 理论与实践: JVM 1.4.1 中的垃圾收集，介绍的就是分代回收策略，而且肯定是针对SUN的JDK，当然HP的也适用。可以关注下面这张图：

形象直观，文章里的文字总忘掉七零八落，但那些原理可以日后巩固，这幅图保存好了设置参数就没啥大问题。

注意下图显示的IBM JDK的分代回收参数设置和SUN/HP的不同

IBM没有设置MaxPermSize的地方，这点要注意了。

HP和SUN的JDK也有两种主要的回收策略，分别是对应高吞吐率的-XX:+UseParallelGC和快速响应时间的-XX:+UseConcMarkSweepGC。

本文主要是描述GC优化的纲领，指出不同的JDK优化对策的不同。详细的参数测试有待以后慢慢写。

相关阅读：

Java 技术，IBM 风格: IBM Developer Kit 简介

Java 理论与实践: 垃圾收集简史  可以了解为什么不同的回收策略，表现出的gc时间会如此迥异。虽然Java 技术，IBM 风格: 垃圾收集策略，第 1 部分一文也叙述的很详细，但是个人觉得《垃圾回收简史》一文写的更明了，毕竟这是最原始的设计，省略了实现过程中添加的许多特性。