调整 Java 虚拟机

    调整 Java 虚拟机

 应用程序服务器是一个基于 Java 的进程，需要 Java 虚拟机（JVM）环境才能运行，并且支持在该应用程序服务器上运行的 Java 应用程序。可配置 Java 运行时环境以调整性能和系统资源使用情况。

1. 优化启动和运行时性能

   在某些环境（例如开发环境）中，提高应用程序服务器的启动性能比提高运行时性能更重要。在另一些环境中，优化运行时性能更为重要。缺省情况下，IBM JVM 是针对运行时性能进行优化的，而基于 HotSpot 的 JVM 是针对启动性能进行优化的。

   Java JIT 编译器在很大程度上决定了是优化启动性能还是优化运行时性能。编译器使用的初始优化级别影响编译类方法所耗用的时间以及启动服务器所耗用的时间。为了提高启动速度，应该降低编译器所使用的初始优化级别。但是，如果降低初始优化级别，由于现在使用较低的优化级别来编译类方法，所以应用程序的运行时性能可能会下降。

   • -Xquickstart

     此设置影响 IBM JVM 使用较低优化级别来编译类方法的方式。较低的优化级别将提高服务器启动速度，但会使运行时性能下降。缺省情况下，如果未指定此参数，IBM JVM 最初将使用较高的初始优化级别来执行编译，这将提高运行时性能，但会减慢服务器启动速度。

     缺省值：	高初始编译器优化级别
     建议值：	高初始编译器优化级别
     用法：	-Xquickstart 将提高服务器启动速度。

   基于 Hotspot 的 JVM 最初使用低优化级别来编译类方法。使用此 JVM 选项来更改该行为：

2. 限制特定情况下接受的转储数。

   在特定错误情况下，多个应用程序服务器线程可能会失败，而 JVM 将为其中的各个线程请求 TDUMP。这种情况会导致同时接受大量 TDUMP，从而带来其他问题，例如缺乏辅助存储器。可使用 JAVA_DUMP_OPTS 环境变量来指示您希望 JVM 在特定情况下生成的转储数。但是，它不影响生成的 TDUMP 数，这是因为 com.ibm.jvm.Dump.SystemDump() 调用是从应用程序服务器上运行的应用程序执行的。

   例如，如果您指定 JAVA_DUMP_OPTS 变量并指定以下选项，那么 JVM 将执行以下操作：

   • 将接受的 TDUMP 数限制为 1。
   • 将接受的 JAVADUMP 数限制为最大值 3。
   • 如果发生 INTERRUPT，那么不捕获任何记录。

   JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE)

   请参阅 IBM Developer Kit 诊断指南，以了解有关如何使用 JAVA_DUMP_OPTS 环境变量的更多信息。

3. 配置堆大小

   Java 堆参数会影响垃圾回收的行为。增加堆大小会支持更多对象创建。由于大的堆要用较长时间进行填充，所以在垃圾回收发生前应用程序会运行较长时间。然而，较大的堆也会用较长时间进行压缩，导致垃圾回收的时间也较长。

   JVM 具有它用于管理 JVM 的存储器的阈值。当达到阈值时，调用垃圾回收器以释放未使用的存储。因此，垃圾回收会导致 Java 性能显著下降。在更改初始和最大堆大小之前，应考虑下列信息：

   • 在大多数情况下，您应将最大 JVM 堆大小设置为比初始 JVM 堆大小更大的值。这允许 JVM 不但在正常的稳定状态期间能够在初始堆大小范围内高效地运行，而且在事务高峰期也能够通过扩大堆大小（最多至最大 JVM 堆大小）高效地运行。在某些需要绝佳性能的罕见情况下，您可能要对初始堆大小和最大堆大小指定相同的值。这将消除某些当 JVM 需要扩大或减小 JVM 堆大小时出现的开销。确保该区域足够大，以便能够容纳指定的 JVM 堆。
   • 要小心将初始堆大小设置得太大。虽然它最初通过延迟垃圾回收会改进性能，但当垃圾回收最后介入时它最终会影响响应时间（因为它运行较长的时间）。

   developerWorks Web 站点提供的 IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide 包含有关调整堆大小的其他信息。

   要使用管理控制台来配置堆大小：

   1. 在管理控制台中，单击服务器 > 应用程序服务器 > server。
   2. 在“服务器基础结构”下，单击 Java 和进程管理 > 进程定义 > Java 虚拟机。
   3. 在“初始堆大小”或“最大堆大小”字段中指定新值。

      如果需要同时调整这两项设置，也可以对这两个字段都指定值。

      为进行性能分析，初始堆大小和最大堆大小应该相等。

      “初始堆大小”设置以兆字节为单位指定垃圾回收的运行频率。“最大堆大小”设置指定垃圾回收运行频率。两种设置都对性能产生重大影响。

      当调整 Java 应用程序的工作集大小未知的生产系统时，初始堆大小的适宜的启动值是最大堆大小的 25%。然后，JVM 尝试使堆大小适应应用程序的工作集大小。

      
      
      

      此插图表示三个 CPU 概要文件，每个概要文件都在运行具有可变 Java 堆设置的固定工作负载。在中间的概要文件中，将初始堆大小和最大堆大小设置为 128MB。发生四次垃圾回收。垃圾回收的总时间大约是运行总时间的 15%。当堆参数加倍为 256MB 时（如在顶部的概要文件中所示），在两次垃圾回收之间的工作时间长度会增加。仅发生三次垃圾回收，但每次垃圾回收的工作时间长度也会增加。在第三个概要文件中，堆大小减少为 64MB，而且会显示出相反的效果。使用较小的堆大小，两次垃圾回收之间的时间和每次垃圾回收的时间也会较短。对于这三种配置，垃圾回收的总时间大约是 15%。此示例说明有关 Java 堆大小和其与对象利用率的关系的重要概念。在 Java 应用程序中垃圾回收是有成本的。

      运行一系列改变 Java 堆设置的测试实验。例如，用 128MB、192MB、256MB 和 320MB 运行实验。在每次实验期间，监视全部内存使用情况。如果您对堆扩展太多，那么可能发生页面调度。使用 vmstat 命令或 Windows 2000/2003 性能监视器检查页面调度。如果发生页面调度，那么减少堆大小或将更多的内存添加到系统。当所有运行都完成时，比较以下各统计信息：

      • 垃圾回收调用次数
      • 一次垃圾回收调用的平均持续时间
      • 一次垃圾回收调用的工作时间长度和两次垃圾回收调用之间的平均时间之间的比率

      如果应用程序不是过度使用的对象而且没有内存泄漏，那么达到了稳定内存利用率的状态。垃圾回收也不会频繁发生，而且持续时间短。

      如果堆可用空间稳定在 85% 或更多，那么考虑降低堆大小的最大值，这是因为应用程序服务器和应用程序未充分利用为堆分配的内存。

   4. 单击应用或确定。
   5. 将更改保存至主配置。
   6. 停止并重新启动应用程序服务器。

   还可使用下列命令行参数来调整这些设置。这些参数适用于所有受支持的 JVM，用于调整每个应用程序服务器或应用程序服务器实例的最小堆大小和最大堆大小。

   • -Xms

     此设置控制 Java 堆的初始大小。正确调整此参数有助于降低垃圾回收开销，从而缩短服务器响应时间并提高吞吐量。对于某些应用程序来说，此选项的缺省设置可能会太低，这将导致发生大量小型垃圾回收。

     缺省值：	50MB。此缺省值同时适用于 32 位和 64 位配置。
     建议值：	随工作负载的不同而有所变化，但高于缺省值。
     用法：	-Xms256m 将初始堆大小设置为 256 兆字节。

   • -Xmx

     此设置控制 Java 堆的最大大小。增大此参数将增加可供应用程序服务器使用的内存量，并且将降低垃圾回收频率。增大此设置可以缩短服务器响应时间并提高吞吐量。但是，增大此设置也将延长所执行的垃圾回收的持续时间。此设置不应大于可供应用程序服务器实例使用的系统内存量。如果将此设置增大到超出可用系统内存量，将导致发生系统页面调度，从而导致性能显著下降。

     缺省值：	256MB。此缺省值同时适用于 32 位和 64 位配置。
     建议值：	随工作负载的不同而有所变化，但高于缺省值，并取决于可用物理内存量。
     用法：	-Xmx512m 将最大堆大小设置为 512 兆字节。

   • -Xlp

     此设置与 IBM JVM 配合使用，以使用大页（16MB）来分配堆。然而，如果使用此设置，那么必须将操作系统配置为支持大页。使用大页可以降低 CPU 跟踪堆内存时的开销，并且还允许创建较大的堆。

     请参阅调整操作系统 ，以了解有关调整操作系统的更多信息。

   • –Xlp64k

     此设置可以与 IBM JVM 配合使用，以使用 64 千字节页大小（中等页）来分配堆。由于硬件效率与页大小成正比，因此，对应用程序所需的内存使用此虚拟内存页大小可以提高该应用程序的性能和吞吐量。

     要支持 64KB 页大小，请在管理控制台中单击服务器 > 应用程序服务器 > server_name > 进程定义 > 环境条目 > 新建，然后在“名称”字段中指定 LDR_CNTRL 并在“值”字段中指定 DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K。

     AIX 围绕 64KB 页提供了丰富的支持，64KB 页的用途十分广泛。64KB 页的使用非常方便，如果使用 64KB 页来代替缺省的 4KB 页，许多应用程序的性能都会有所提高。您可以更改此设置，而不必更改操作系统配置。

     缺省值：	4KB
     建议值：	-Xlp64k 启用 64KB 页大小支持。 newfeat 注： （限于 POWER5+ 系统）在运行 64 位内核时，带有 5300-04 建议维护包的 AIX 5L V5.3 支持新的 64KB 页大小。

4. 调整 Java 内存
   用 Java 语言写的企业应用程序涉及复杂对象关系，并利用大量对象。虽然，Java 语言会自动管理与对象生命周期关联的内存，但了解对象的应用程序使用模式是重要的。特别要验证以下内容：

   • 应用程序不是过度使用的对象
   • 应用程序不是泄漏对象
   • 已正确设置 Java 堆参数以处理给定的对象使用模式
   1. 检查是否过度使用对象。

      您可以通过观察 JVM 运行时的计数器，使用 Tivoli Performance Viewer 检查应用程序是否是过度使用的对象。您必须设置 -XrunpmiJvmpiProfiler 命令行选项以及 JVM 模块最大级别，以便启用 Java 虚拟机概要分析程序接口（JVMPI）计数器。

      垃圾回收之间的最佳平均时间至少是单次垃圾回收的平均持续时间的 5 到 6 倍。如果没有达到此数字，那么应用程序将多用 15% 的时间用于垃圾回收。

      如果信息表明产生了垃圾回收瓶颈，那么有两种方法清除瓶颈。最划算的方法是优化应用程序以实现对象高速缓存和池。使用 Java 概要分析程序确定目标对象。如果您无法优化应用程序，那么添加内存、处理器和克隆可能会有帮助。添加的内存允许每个克隆保持合理的堆大小。添加的处理器允许克隆并行运行。

   2. 测试内存泄漏

      内存泄漏在 Java 语言中是造成垃圾回收瓶颈的一个危险因素。内存泄漏比内存过度使用更有破坏性，因为内存泄漏最终会导致系统不稳定。随着时间的过去，垃圾回收会发生得更加频繁，直到堆用尽，而且 Java 代码失败并返回致命的“内存不够”异常。当未使用的对象具有不会被释放的引用时，会发生内存泄漏。内存泄漏通常发生在集合类（如 Hashtable）中，这是因为该表总是具有对对象的引用（甚至在删除实际的引用后）。

      高工作负载总会引起应用程序在部署到生产环境后立即崩溃。对泄漏应用程序尤其如此，高工作负载促使泄漏扩大，并发生内存分配故障。

      进行内存泄漏测试的目标是扩大数字。根据无法进行垃圾回收的字节或千字节量评测内存泄漏。此精细任务将区别有用内存和不可用内存预期大小的量。如果扩大数字，使间隔更大、更易于标识不一致性，那么完成此任务会更简便。以下列表包含有关内存泄漏的重要结论：

      • 长期运行测试

        内存泄漏问题可能在一段时间后才会显现，因此，在长期运行测试期间易于找到内存泄漏。短期测试可能导致错误的警报。有时很难知道 Java 语言中正在发生内存泄漏，尤其当在一段给定时间内，内存使用情况表面上突然地或单调地增加时。很难检测到内存泄漏的原因是由于这些种类的增加可能有效或可能是开发者的意图。您可以通过将应用程序运行一段较长的时间，来了解如何区分延迟使用的对象和完全未使用的对象。进行长期运行应用程序测试能帮助您更好地确定是否真的正在发生对象的延迟使用。

      • 重复测试

        在很多情况下，内存泄漏问题通过同一测试用例的连续重复使用而发生。内存泄漏测试的目标是建立不能使用的内存和使用的内存（根据它们的相对大小）之间的大间隔。通过一次又一次地重复同一方案，渐进地增加间隔。如果由执行测试用例引起的泄漏数太小以至于很难在某次运行中明显地显示出来，那么进行此测试会有帮助。

        您可以在系统级别或模块级别上使用重复测试。进行模块化测试的优点是较好控制。当模块设计为保持专用模块而不创建外部副作用（如内存使用情况）时，对内存泄漏进行测试较简便。首先，在运行模块前记录内存使用情况。然后，重复运行一组固定的测试用例。在测试运行结束时，为重大更改记录和检查当前内存使用情况。请记住，当通过将 System.gc() 插入到想要进行垃圾回收的模块中，或通过使用概要分析工具强迫事件发生来记录实际的内存使用情况时，必须建议使用垃圾回收。

      • 并发性测试

        某些内存泄漏问题可能只有当几个线程运行在应用程序中时才会发生。不幸地是，由于程序逻辑中添加了新出现的问题，导致同步点很容易受到内存泄漏的影响。编程粗心可能会导致保留或未释放引用。系统中增加的并发性通常会推动或促进内存泄漏事件。增加并发性最常见的方法就是增加测试驱动程序中的客户机数。

        当选择用于进行内存泄漏测试的测试用例时，考虑以下各点：

        • 好的测试用例会涉及创建对象的应用程序领域。大多数情况下，需要应用程序的知识。方案的描述可以建议创建数据空间，如添加新记录、创建 HTTP 会话、执行事务和搜索记录。
        • 查看使用对象集合的区域。通常，内存泄漏由同一个类中的对象组成。同样，集合类（如 Vector 和 Hashtable）是通过调用相应的插入方法，隐式存储对对象的引用的通用位置。例如，Hashtable 对象的 get 方法不会除去其对已检索对象的引用。

      可以使用 Tivoli Performance Viewer 来帮助查找内存泄漏。

      要获取最佳结果，请用递增的持续时间重复实验，如 1000、2000 和 4000 页请求。使用的内存的 Tivoli Performance Viewer 图应该具有锯齿形状。图上的每个下落对应于垃圾回收。如果发生以下某种情况，那么存在内存泄漏：

      • 每次垃圾回收后立即使用的内存量显著增加。锯齿模式更象楼梯。
      • 锯齿模式具有不规则的形状。

      同样，查看已分配的对象数和已释放的对象数之间的差异。如果两者之间的差异随着时间在增长，那么存在内存泄漏。

      如果堆消耗指示重工作负载（应用程序服务器的 CPU 利用率一直接近 100%）期间可能存在泄漏，但似乎会在接下来的较轻或接近空闲的工作负载期间恢复，那么表示存在堆碎片。当 JVM 可以在垃圾回收循环期间释放足够的对象以满足内存分配请求时会产生堆碎片，但 JVM 没有时间将堆中小的空闲内存区域压缩到较大的邻近空间。

      当释放小对象（小于 512 个字节）时，会产生另一种格式的堆碎片。会释放对象，但不会恢复存储器，导致产生内存碎片直到运行堆压缩为止。

      通过强制执行压缩，可以减少堆碎片，但这样做会降低性能。使用 Java -X 命令来查看内存选项列表。

5. 调整垃圾回收

   检查 Java 垃圾回收可了解应用程序将如何利用内存。垃圾回收是 Java 的特质。通过从应用程序写程序中除去内存管理负担，Java 应用程序比用不提供垃圾回收的语言写的应用程序更可靠。只要应用程序不滥用对象，就可以保持此可靠性。垃圾回收通常占用正常运行的应用程序总执行时间的 5% 到 20%。如果不进行管理，那么垃圾回收会是应用程序的一个最大的瓶颈。

   通过在执行固定工作负载期间监视垃圾回收，您可以了解应用程序是否是过度使用对象。垃圾回收甚至可以检测到是否存在内存泄漏。

   可以使用 JVM 设置来配置垃圾回收的类型和行为。当 JVM 由于连续空间不足而无法从当前堆中分配对象时，将调用垃圾回收器以从不再使用的 Java 对象中回收内存。每个 JVM 供应商都提供了独特的垃圾回收器策略和调整参数。

   可在管理控制台中使用冗余垃圾回收设置来启用垃圾回收监视。此设置的输出包括类垃圾回收统计信息。生成的报告的格式在不同的 JVM 之间或发行级别之间并无一定标准。

   有关监视垃圾回收的更多信息，请参阅：

   • 性能：学习资源 for a description of the IBM verbose:gc output
   • 有关在 Solaris Operating Environment 中的垃圾回收的更多信息，请参阅性能：学习资源 。

   要调整 JVM 垃圾回收设置：

   1. 在管理控制台中，单击服务器 > 应用程序服务器 > server。
   2. 在“服务器基础结构”下，单击 Java 和进程管理 > 进程定义 > Java 虚拟机。
   3. 在“通用 JVM 参数”字段中输入要更改的 X 选项。
   4. 单击确定。
   5. 将更改保存至主配置。
   6. 停止并重新启动应用程序服务器。

   以下列表描述不同 JVM 垃圾回收器的 –X 选项。

   IBM JVM 垃圾回收器。 IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide 提供了 IBM Java 垃圾回收器的完整指南。此文档可以从 developerWorks Web 站点获得。

   使用 Java -X 选项来查看内存选项列表。

   • -Xgcpolicy
     从 Java 5.0 开始，IBM JVM 提供了四种垃圾回收策略。每种策略都有独特的优点。

     • optthruput，这是缺省策略，它提供了高吞吐量，但垃圾回收暂停时间较长。在垃圾回收期间，将停止所有应用程序线程，以便进行标记、清理并根据需要进行压缩。optthruput 适合于大多数应用程序。
     • optavgpause，此策略通过在应用程序执行期间执行垃圾回收的标记和清理阶段来缩短垃圾回收暂停时间。这种并发执行会对整体吞吐量产生轻微影响。
     • gencon 是 IBM JVM 的分代垃圾回收器，这是 IBM Java 5.0 的新增内容。分代模式尝试实现高吞吐量并同时缩短垃圾回收暂停时间。为了实现此目标，将堆分为新区域和旧区域。长生命周期对象将被提升到旧空间，而短生命周期对象将在新空间中被迅速地作为垃圾回收。gencon 策略能使许多应用程序受益匪浅，但并不适用于所有应用程序，并且通常难以调整。
     • subpool，此策略可以提高多处理器系统（通常使用 8 个以上处理器）的性能。此策略仅适用于 IBM pSeries 和 zSeries 处理器。除了将堆划分为子池以提高对象分配可伸缩性以外，subpool 策略与 optthruput 策略类似。

     缺省值：	optthruput
     建议值：	optthruput
     用法：	Xgcpolicy:optthruput 将垃圾回收策略设置为 optthruput。

     将 gcpolicy 设置为 optthruput 会禁用并发标记。除非应用程序响应时间不规律（这表示可能存在暂停时间问题），否则，使用 optthruput 策略能够获得最佳的吞吐量结果。

     将 gcpolicy 设置为 optavgpause 会使用缺省值来启用并发标记。此设置将减少由正常垃圾回收所引起的应用程序响应时间不规律情况。然而，此选项可能会降低整体吞吐量。

   • -Xnoclassgc

     缺省情况下，当一个类没有任何活动实例时，JVM 就会从内存中卸装该类。因此，类卸装会使性能下降。

     可使用 -Xnoclassgc 参数来禁用类垃圾回收，这样应用程序就可以更方便地重复使用类。如果关闭类垃圾回收，就可以消除由于多次装入和卸装同一个类而造成的开销。

     缺省值：	启用类垃圾回收。
     建议值：	禁用类垃圾回收。
     用法：	Xnoclassgc 禁用类垃圾回收。

   Sun JVM 垃圾回收器。

   在 Solaris 平台上，应用程序服务器在 Sun HotSpot JVM 上运行，而不是在 IBM JVM 上运行。对 Sun JVM 使用正确的调整参数以利用其性能优化功能十分重要。

   Sun Hotspot JVM 依靠分代垃圾回收来实现最佳性能。下列命令行参数对于调整垃圾回收来说非常有用。

   • -XX:SurvivorRatio

     将 Java 堆划分为旧对象（长生命周期对象）区域和新对象区域。新对象区域进一步细分为两部分，第一部分用于分配给新对象（称为初始区域），第二部分存放那些经过其前几次垃圾回收之后、但在被提升为旧对象之前仍在使用中的新对象（称为幸存者空间）。幸存者比率是堆的新对象区域中初始区域与幸存者空间的比率。增大此设置将针对需要创建大量对象但仅保留少量对象的应用程序优化 JVM。与其他应用程序服务器相比，WebSphere Application Server 实例会生成更多中等生命周期对象和长生命周期对象，因此，应该将此设置设置为小于缺省值。

     缺省值：	32
     建议值：	16
     用法：	-XX:SurvivorRatio=16

   • -XX:PermSize

     为永久生成对象保留的堆区域存储 JVM 的所有反射数据。对于动态地装入和卸装大量类的应用程序来说，应该增大此大小以优化它们的性能。通过将此参数设置为 128 兆字节，可以消除增大此部分堆所需的开销。

     建议值：	128m
     用法：	XX:PermSize=128m 将 perm 大小设置为 128 兆字节。

   • -Xmn

     此设置控制允许新生成的对象在堆中耗用的空间量。正确调整此参数有助于降低垃圾回收开销，从而缩短服务器响应时间并提高吞吐量。此参数的缺省设置通常过低，这将导致执行大量的小型垃圾回收操作。如果将此参数设置得过高，可能会导致 JVM 仅执行大型（全面）垃圾回收。这些垃圾回收操作通常会耗时几秒钟，这将严重影响服务器的整体性能。您必须保持将此参数设置为小于整个堆大小的一半，以避免这种情况出现。

     缺省值：	2228224 字节
     建议值：	大约整个堆大小的 1/4
     用法：	-Xmn256m 将大小设置为 256 兆字节。

   • -Xnoclassgc

     缺省情况下，当一个类没有任何活动实例时，JVM 就会从内存中卸装该类，但是这样会使性能下降。如果关闭类垃圾回收，就可以消除由于多次装入和卸装同一个类而造成的开销。

     如果不再需要某个类，那么该类在堆中所占用的空间通常将用于创建新对象。但是，如果应用程序通过创建类的新实例来处理请求，并且该应用程序的请求是随机出现的，那么可能会发生以下情况：先前请求者完成后，正常的类垃圾回收将通过释放这个类占用的堆空间来清除这个类，但当下一个请求出现时，又必须将这个类重新实例化。在这种情况下，您可能想使用此选项来禁用类垃圾回收。

     缺省值：	启用类垃圾回收。
     建议值：	禁用类垃圾回收。
     用法：	Xnoclassgc 禁用类垃圾回收。

   有关调整 Sun JVM 的其他信息，请参阅 Java HotSpot VM 的性能文档。

   HP JVM 垃圾回收器。

   HP JVM 依靠分代垃圾回收来实现最佳性能。下列命令行参数对于调整垃圾回收来说非常有用。

   • -XX:+AggressiveHeap

     此设置允许 JVM 自动和主动地调整 Java 堆。如果将多个变量传递给 JVM，那么您应该先指定此变量，这是因为此变量会导致其他某些变量（例如堆大小设置）被覆盖。主动调整算法遵循在 -XX:+AggressiveHeap 参数之后传递给 JVM 的任何参数的约束。

     缺省值：	off
     建议值：	on
     用法：	-XX:+AggressiveHeap 启用对 Java 堆的自动调整

   • -Xoptgc

     此设置针对包含许多短生命周期对象的应用程序优化 JVM。如果未指定此参数，那么 JVM 通常执行大型（全面）垃圾回收。全面垃圾回收会花费几秒钟时间，这将显著影响服务器性能。

     缺省值：	off
     建议值：	on
     用法：	-Xoptgc 启用优化的垃圾回收。

   • -XX:SurvivorRatio

     将 Java 堆划分为旧对象（长生命周期对象）区域和新对象区域。新对象区域进一步细分为两部分，第一部分用于分配给新对象（称为初始区域），第二部分存放那些经过其前几次垃圾回收之后、但在被提升为旧对象之前仍在使用中的新对象（称为幸存者空间）。幸存者比率是堆的新对象区域中初始区域与幸存者空间的比率。增大此设置将针对需要创建大量对象但仅保留少量对象的应用程序优化 JVM。与其他应用程序服务器相比，WebSphere Application Server 实例会生成更多中等生命周期对象和长生命周期对象，因此，应该将此设置设置为小于缺省值。

     缺省值：	32
     建议值：	16
     用法：	-XX:SurvivorRatio=16

   • -XX:MaxTenuring 阈值

     此设置指定对象在被提升至旧一代前可在新一代中保留的集合数。增加对此设置指定的值将强制对象在新一代中保留更长时间。减小对此设置指定的值将导致对象被更快地提升至旧一代。

     缺省值：	31
     建议值：	32
     用法：	-XX:MaxTenuringThreshold=32

   • -XX:+ForceMmapReserved

     此命令禁用惰性交换并允许操作系统使用较大的内存页，从而优化对构成 Java 堆的内存的访问。缺省情况下，将惰性交换空间分配给 Java 堆。因为内存页是根据需要分配的，所以惰性交换功能能够节省交换空间。但是，惰性交换功能强制使用 4KB 页。在大型堆系统中，这种内存分配方式允许堆包含数以十万计的页。

     缺省值：	off
     建议值：	on
     用法：	-XX:+ForceMmapReserved 禁用惰性交换功能。

   • -XX:+UseParallelGC

     此命令对新一代启用并行垃圾回收。对多处理器系统发出此命令将缩短 JVM 完成部分垃圾回收周期所花费的时间。

     缺省值：	off
     建议值：	on
     用法：	-XX:+UseParallelGC 对新一代启用并行垃圾回收。

   • -XX:+UseParallelOldGC

     此命令对旧一代启用并行垃圾回收。对多处理器系统发出此命令将缩短 JVM 完成完整垃圾回收周期所花费的时间。

     缺省值：	off
     建议值：	on
     用法：	-XX:+UseParallelOldGC 对旧一代启用并行垃圾回收。

   • -Xmn

     此设置控制允许新生成的对象在堆中耗用的空间量。正确调整此参数有助于降低垃圾回收开销，从而缩短服务器响应时间并提高吞吐量。此参数的缺省设置通常过低，这将导致执行大量的小型垃圾回收操作。

     缺省值：	没有缺省值
     建议值：	大约整个堆大小的 3/4
     用法：	-Xmn768m 将大小设置为 768 兆字节。

   • 虚拟页大小

     通过将 Java 虚拟机的指令页大小和数据页大小设置为 64MB，可以提高性能。

     缺省值：	4MB
     建议值：	64MB
     用法：	使用以下命令。命令输出提供了进程可执行文件的当前操作系统特征： chatr +pi64M +pd64M /opt/WebSphere/ AppServer/java/bin/PA_RISC2.0/ native_threads/java

   • -Xnoclassgc

     缺省情况下，当一个类没有任何活动实例时，JVM 就会从内存中卸装该类，但是这样会使性能下降。如果关闭类垃圾回收，就可以消除由于多次装入和卸装同一个类而造成的开销。

     如果不再需要某个类，那么该类在堆中所占用的空间通常将用于创建新对象。但是，如果应用程序通过创建类的新实例来处理请求，并且该应用程序的请求是随机出现的，那么可能会发生以下情况：先前请求者完成后，正常的类垃圾回收将通过释放这个类占用的堆空间来清除这个类，但当下一个请求出现时，又必须将这个类重新实例化。在这种情况下，您可能想使用此选项来禁用类垃圾回收。

     缺省值：	启用类垃圾回收。
     建议值：	禁用类垃圾回收。
     用法：	Xnoclassgc 禁用类垃圾回收。

   有关调整 HP 虚拟机的其他信息，请参阅 Java 技术软件 HP-UX 11i。

6. 调整 HP 的 JVM for HP-UX 设置下列选项以提高应用程序性能：-XX:SchedulerPriorityRange=SCHED_NOAGE -XX:-ExtraPollBeforeRead -XX:+UseSpinning -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.DevPollSelectorProvider

   有关调整 HP 虚拟机的其他信息，请参阅 Java 技术软件 HP-UX 11i。

7. 为 Solaris 上的 Sun HotSpot JVM 选择客户机方式或服务器方式。

   在 Solaris 平台上，WebSphere Application Server 使用的 Java 虚拟机以两种方式运行：客户机方式或服务器方式。这两种方式各有优点。

   如果环境符合以下条件，那么最好选择客户机方式：

   • 要求服务器在重新引导或崩溃后快速恢复。客户机方式使虚拟机能够更快地完成预备工作，这使应用程序服务器服务在启动后能够快速处理大量请求。
   • 物理 RAM 有限。与服务器方式相比，客户机方式使用的内存较少。如果整体 JVM 大小由于硬件限制而较小，节省内存的效果就会更为显著。例如，如果在单一硬件上运行多个 JVM，整体 JVM 大小就会较小。

   如果要最大程度地提高很少重新启动的应用程序服务器上的性能，应该以服务器方式运行 HotSpot JVM。当 JVM 以服务器方式运行时，应用程序服务器在能够为大量请求提供服务前经过的时间与客户机方式长数倍。但是，在应用程序服务器进入该状态后，以服务器方式运行 JVM 的性能将明显优于客户机方式。

   以服务器方式运行的 HotSpot JVM 使用高优化级别编译器，该编译器将在初始预备阶段优化并重新优化 Java 代码。所有此类优化工作都需要耗用一些时间，但是，一旦 JVM 完成预备阶段，应用程序服务器的运行速度就会明显高于同一硬件上客户机方式下的运行速度。

   Java 5.0 的 Solaris 实现将检查硬件并尝试选择适合于环境的 JVM 方式。如果 JVM 确定它在服务器级机器上运行，JVM 就会自动启用服务器方式。在 Java 1.4.2 和更高版本中，缺省方式是客户机方式，必须在 JVM 命令行上使用 -server 标志才能启用服务器方式。

   由于 JVM 会在机器至少包含 2 个 CPU 和 2 GB 内存时自动启用服务器方式，所以，JVM 的缺省方式可能已是服务器方式。但是，如果 JVM 选择的方式不适合于您的环境，那么可以在通用 JVM 参数中使用 -client 和 -server 标志来强制虚拟机进入任何一种方式。

8. 在高速缓存中启用类共享。

   IBM Java 2 Runtime Environment（J2RE）V1.5.0 的共享类选项允许在高速缓存中共享类。通过在高速缓存中共享类，可以缩短启动时间并减少内存使用量。进程（例如应用程序服务器、Node Agent 和 Deployment Manager）可以使用共享类选项。

   重要： 当前，IBM J2RE 1.5.0 不可用于：

   • Solaris
   • HP-UX

   如果使用此选项，那么应该在进程不在使用中时清除高速缓存。要清除高速缓存，请调用 app_server_root /bin/clearClassCache.bat/sh 实用程序，也可以先停止该进程，然后重新启动它。

   如果需要对某个进程禁用共享类选项，请对该进程指定通用 JVM 参数 -Xshareclasses:none：

   1. 在管理控制台中，单击服务器 > 应用程序服务器 > server。
   2. 在“服务器基础结构”下，单击 Java 和进程管理 > 进程定义 > Java 虚拟机。
   3. 在“通用 JVM 参数”字段中输入 -Xshareclasses:none。
   4. 单击确定。
   5. 将更改保存至主配置。
   6. 停止并重新启动应用程序服务器。

   缺省值：	启用“在高速缓存中共享类”选项。
   建议值：	保留“在高速缓存中共享类”选项处于启用状态。
   用法：	-Xshareclasses:none 禁用“在高速缓存中共享类”选项。

9. 使内存消耗降至最低。
   Sun Java 5.0 JVM 的缺省调整首选项比先前 JVM 版本的缺省调整首选项使用更多的内存。此附加内存有助于使吞吐量达到最大。但是，如果您正在运行如 JVM 临时空间这样的环境，其中实际内存往往很紧缺，那么会导致问题。如果您需要调整 Sun Java 5.0 JVM 以便将内存消耗降至最低，那么可以对通用 JVM 参数添加下列调整参数：-client -XX:MaxPermSize=256m -XX:-UseLargePages -XX:+UseSerialGC

   设置这些参数会对某些吞吐量产生影响，并可能会导致服务器启动速度稍微缓慢。如果您正在运行非常大的应用程序，那么可以为 MaxPermSize 设置指定一个更大的值。

   HP Java 5 JVM 的缺省调整首选项比先前 JVM 版本的缺省调整首选项使用更多的内存。此附加内存有助于使吞吐量达到最大。但是，如果您正在运行如 JVM 临时空间这样的环境，其中实际内存往往很紧缺，那么会导致问题。如果您需要调整 Sun Java 5.0 JVM 以便将内存消耗降至最低，那么可以对通用 JVM 参数添加下列调整参数：-XX:-UseParallelGC –XX:-UseAdaptiveSizePolicy 设置这些参数可能会导致服务器启动速度稍微缓慢。
10. 调整大型单元配置的配置更新进程。
    在大单元配置中，您可能必须确定是配置更新性能还是配置一致性检查更重要。当配置一致性检查打开时，可能需要大量的时间来保存配置更改或部署大量应用程序。以下因素影响所需的时间：

    • 单元中定义的应用程序服务器或集群越多，那么保存配置更改所需的时间越长。
    • 单元中部署的应用程序服务器越多，那么保存配置更改所需的时间越长。
    如果您对更改配置所需的时间量不满意，那么可以将 config_consistency_check 定制属性添加到 JVM 设置中并将此属性的值设置为 false。

    1. 在管理控制台中，单击系统管理 > Deployment Manager。
    2. 在“服务器基础结构”下，选择“Java 和进程管理”，然后单击进程定义。
    3. 在“其他属性”下，单击 Java 虚拟机 > 定制属性 > 新建。
    4. 在“名称”字段中输入 config_consistency_check，在“值”字段中输入 false。
    5. 单击确定，然后单击保存以将这些更改应用到主配置。
    6. 重新启动服务器。