WAS JVM参数说明

以下摘自IBM信息中心：

每个 JVM 供应商都提供了有关其 JVM 性能和调整的详细信息。请将本主题中提供的信息与系统上运行的 JVM 附带提供的信息结合使用。

Java SE 运行时环境提供用于运行企业应用程序和应用程序服务器的环境。因此，Java 配置在确定应用程序服务器及其运行的应用程序的性能和系统资源使用方式方面扮演着重要的角色。

IBM Java 虚拟机 V6.0 包括 Java Platform Enterprise Edition (Java EE) 规范的最新内容，并且性能和稳定性都有所提高（与 Java 的先前版本相比）。

尽管 JVM 调整依赖于您所使用的 JVM 提供程序，但存在一些适用于所有 JVM 的一般调整概念。这些一般的概念包括：

• 编译器调整。在服务器运行时期间，所有 JVM 都使用即时 (JIT) 编译器来将 Java 字节码编译为本机指令。
• Java 内存或堆调整。调整 JVM 内存管理功能（即垃圾回收）是提高 JVM 性能的良好开端。
• 类装入调整。
• 启动性能优化与运行时性能优化

以下步骤提供了有关如何对每个 JVM 执行下列类型的调整的特定指示信息。您不必按任何具体的顺序来执行这些步骤。

过程

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

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

   Java 即时 (JIT) 编译器会影响是否优化启动性能或运行时性能。编译器使用的初始优化级别影响编译类方法所需的时间以及启动服务器所需的时间。为了提高启动速度，请降低编译器所使用的初始优化级别。但是，如果降低初始优化级别，由于现在使用较低的优化级别来编译类方法，所以应用程序的运行时性能可能会下降。

   • -Xquickstart

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

     可在 Java 虚拟机面板上使用管理控制台设置此属性。有关详细信息，请阅读有关 Java 虚拟机设置的信息。

     信息	值
     缺省值	高初始编译器优化级别
     建议	高初始编译器优化级别
     用法	指定 -Xquickstart 可缩短服务器启动时间。

2. 配置堆大小。

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

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

   • 在大多数情况下，您应将最大 JVM 堆大小设置为比初始 JVM 堆大小更大的值。此设置允许 JVM 在正常的稳定状态期间能够在初始堆大小范围内高效地运行。此设置还允许 JVM 在事务高峰期也能够高效地运行，因为 JVM 可以将堆大小最多扩大至最大 JVM 堆大小指定的值。在某些需要绝佳性能的罕见情况下，您可能要对初始堆大小和最大堆大小指定相同的值。此设置消除了某些当 JVM 扩大或减小 JVM 堆大小时出现的开销。在更改任何 JVM 堆大小之前，请验证 JVM 存储器分配足够大，可以容纳新的堆大小。
   • 不要使初始堆的大小太大，使得初次通过延迟垃圾回收来提高性能时，在垃圾回收进行期间，回收进程影响响应时间，因为该进程必须运行更长的时间。

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

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

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

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

      “初始堆大小”设置指定 JVM 启动时分配给 JVM 堆的存储量（以兆字节为单位）。“最大堆大小”设置指定 JVM 启动时可分配给 JVM 堆的最大存储量（以兆字节为单位）。两种设置都对性能产生重大影响。

      如果要调整某个生产系统但不知道在该系统上运行的企业应用程序工作集大小，那么初始堆大小的适宜启动值是最大堆大小的 25%。然后，JVM 尝试使堆大小适应应用程序的工作集大小。

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

      
      

      

      
      

      运行一系列使用不同 Java 堆设置的测试。例如，运行使用 128 MB、192 MB、256 MB 和 320 MB 的试验。在每次实验期间，监视全部内存使用情况。如果您对堆扩展太多，那么可能发生页面调度。

      使用 vmstat 命令或 Windows 性能监视器检查页面调度。如果发生页面调度，那么减少堆大小或将更多的内存添加到系统。

      当所有运行都完成时，比较以下各统计信息：

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

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

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

   4. 单击应用。
   5. 单击保存以保存您对主配置所作的更改。
   6. 停止然后重新启动应用程序服务器。

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

   • -Xms

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

     信息	值
     缺省值	50 MB
     建议	随工作负载的不同而有所变化，但高于缺省值。
     用法	指定 -Xms256m 会将初始堆大小设置为 256 MB。

   • -Xmx

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

     信息	值
     缺省值	缺省情况下，JVM 会根据系统中的可用内存动态计算 Java 堆大小。
     建议	随工作负载的不同而有所变化，但高于缺省值，并取决于可用物理内存量。
     用法	指定 -Xmx512m 会将最大堆大小设置为 512 MB。

      避免故障： 对 -Xmx 参数指定值以减少可能的内存不足问题。
   •  -Xlp

     将此参数与 IBM Java 虚拟机配合使用以在使用大页（例如，16 MB 页）时分配该堆。在指定此参数之前，请验证操作系统是否配置为支持大页。使用大页可以降低 CPU 跟踪堆内存时的开销，并且还允许创建较大的堆。

     缺省值

     64 KB，如果您在使用 Java 6 SR 7 或更高版本

     4 KB，如果您在使用 Java 6 SR 6 或更低版本

   •  –Xlp64k

     可使用此参数来使用中等大小页（例如，64 KB）分配堆。由于硬件效率与页大小相关，因此，对应用程序所需的内存使用此虚拟内存页大小可以提高该应用程序的性能和吞吐量。

      i5/OS? 和 AIX? 提供了对 64 KB 页的强大支持，因为 64 KB 页旨在成为通用页。64 KB 页易于启用，并且应用程序在使用 64 KB 页时的性能也会有所提高。从 Java 6 SR 7 开始，缺省情况下 Java 堆是以 64K 页为单位分配的。对于 Java 6 SR 6 或之前版本，缺省设置为 4K 页。可更改此设置而不更改操作系统配置。但是，如果您使用 64KB 页，那么建议您在另一存储池中运行应用程序服务器。

      如果正在使用 Java 6 SR 6 或之前版本，要支持 64 KB 页大小，请在管理控制台中，单击服务器 > 应用程序服务器 >server_name > 进程定义 > 环境条目 > 新建，然后在名称字段中指定 LDR_CNTRL，在值字段中指定DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K。

     建议

     请尽可能地使用 64 KB 页。

      POWER5+ 系统和具有 5300-04 建议维护包的 AIX 5L? V5.3 在运行 64 位内核时支持 64 KB 页大小。

   •  –Xlp4k

     可通过此参数来使用 4 KB 页分配堆。对应用程序所需的内存使用此虚拟内存页大小（而不是 64 KB）可能会降低性能应用程序的性能和吞吐量，因为页大小较小会导致硬件的低效率。

      从 Java 6 SR 7 开始，缺省情况下 Java 堆是以 64K 页为单位分配的。对于 Java 6 SR 6 或之前版本，缺省设置为 4K 页。可更改此设置而不更改操作系统配置。但是，如果您使用 64KB 页，那么建议您在另一存储池中运行应用程序服务器。

      如果正在使用 Java 6 SR 7 或更高版本，要支持 4 KB 页大小，请在管理控制台中，单击服务器 > 应用程序服务器 >server_name > 进程定义 > 环境条目 > 新建，然后在名称字段中指定 LDR_CNTRL，在值字段中指定DATAPSIZE=4K@TEXTPSIZE=4K@STACKPSIZE=4K。

     建议

     请尽可能地使用 -Xlp64k 而不是 -Xlp4k。

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

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

      可以查看包括在 Tivoli? Performance Viewer 报告中的 JVM 运行时的计数器，以确定应用程序是否越载使用对象。必须指定 -XrunpmiJvmtiProfiler 命令行选项和 JVM 模块最大级别才能启用 Java 虚拟机概要分析程序接口 JVMTI 计数器。

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

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

   2. 测试内存泄漏。

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

      高工作负载总会引起应用程序在部署到生产环境后立即崩溃。如果应用程序有内存泄漏，那么高工作负载会加速放大此泄漏并导致发生内存分配故障。

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

      • 长期运行测试

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

      • 重复测试

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

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

      • 并发性测试

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

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

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

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

      为了取佳结果，请用递增的持续时间重复实验，如 1,000、2,000 和 4,000 页请求。已用内存的 Tivoli Performance Viewer 图应该具有锯齿形状。图上的每个下落对应于垃圾回收。如果图形中发生以下某种情况，那么存在内存泄漏：

      • 每次垃圾回收后立即使用的内存量显著增加。当发生此情况时，锯齿模式更象楼梯。
      • 锯齿模式具有不规则的形状。
      • 已分配的对象数与已释放的对象数之间的豁口随着时间的推移而增大。

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

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

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

4. 调整垃圾回收

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

   如果在固定工作负载正在运行时监视垃圾回收，那么可让您了解应用程序是否越载使用对象。垃圾回收甚至可以检测到是否存在内存泄漏。

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

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

   要调整 JVM 垃圾回收设置：

   1. 在管理控制台中，请单击服务器 > 服务器类型 > WebSphere 应用程序服务器 > server_name。
   2. 在“服务器基础结构”部分中，单击Java 和进程管理 > 进程定义 > Java 虚拟机
   3. 在通用 JVM 参数字段中输入要更改的 –X 选项。
   4. 单击应用。
   5. 单击保存以保存您对主配置所作的更改。
   6. 停止然后重新启动应用程序服务器。

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

   用于 Java 垃圾回收程序的 IBM 虚拟机。 IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide 中提供了 Java 垃圾回收器的 IBM 实现的完整指南。此文档可以从 developerWorks? Web 站点获得。

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

   • -Xgcpolicy
     IBM Java 虚拟机提供了四种垃圾回收策略。每种策略都有独特的优点。

     注： 虽然每个策略都有独特优点，但对于 WebSphere Application Server V8.0 及更高版本，gencon 是缺省垃圾回收策略。应用程序服务器的先前版本指定 optthruput 作为缺省垃圾回收策略。

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

     信息	值
     缺省值	gencon
     建议	gencon
     用法	指定 Xgcpolicy:gencon 会将垃圾回收策略设置为 gencon。

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

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

   • -Xnoclassgc

     缺省情况下，当一个类没有任何活动实例时，JVM 就会从内存中卸装该类。多次装入和卸装同一个类的开销会降低性能。

      避免故障： 可以使用 -Xnoclassgc 参数来禁用类垃圾回收。但是，类垃圾回收的性能影响通常很小，在基于 Java Platform, Enterprise Edition (Java EE) 的系统（该系统大量使用应用程序类装入器）中关闭类垃圾回收可能会在事实上造成类数据的内存泄漏并导致 JVM 抛出内存不足异常。

     如果使用此选项，那么每当重新部署应用程序时，都必须重新启动应用程序服务器，以清除来自应用程序的先前版本的类和静态数据。

     信息	值
     缺省值	启用类垃圾回收。
     建议	不要禁用类垃圾回收。
     用法	指定 Xnoclassgc 以禁用类垃圾回收。

5. 启用本地主机名称高速缓存
   缺省情况下，在 IBM SDK for Java 中，静态方法 java/net/InetAddress.getLocalHost 不会高速缓存其结果。系统在整个 WebSphere Application Server 中使用此方法，但尤其会在 Deployment Manager 和 Node Agent 之类的管理代理程序中使用。如果进程的本地主机地址在进程运行期间不会更改，那么建议通过将 com.ibm.cacheLocalHost 系统属性的值设置为 true 以使用内置高速缓存查找本地主机。有关在各种类型的进程上设置 JVM 定制属性的指示信息，请参阅信息中心中的“Java 虚拟机定制属性”主题。
    避免故障： 使用 DHCP 配置的服务器地址随时间推移而更改。除非为服务器使用静态分配的 IP 地址，否则请勿设置此属性。

   信息	值
   缺省值	com.ibm.cacheLocalHost = false
   建议	com.ibm.cacheLocalHost = true（请参阅描述）
   用法	指定 -Dcom.ibm.cacheLocalHost=true 会启用 getLocalHost 高速缓存

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

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

     避免故障： 在下列平台上，当前不支持 J2RE V1.5.0 的 IBM 实现：

   •  Solaris
   •  HP-UX

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

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

   1. 在管理控制台中，请单击服务器 > 服务器类型 > WebSphere 应用程序服务器 > server_name。
   2. 在“服务器基础结构”部分中，单击Java 和进程管理 > 进程定义 > Java 虚拟机
   3. 在通用 JVM 参数字段中输入 -Xshareclasses:none。
   4. 单击确定。
   5. 单击保存以保存您对主配置所作的更改。
   6. 停止然后重新启动应用程序服务器。

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

7. 在 64 位环境上启用压缩引用。

   可在 64 位环境（例如，AIX 64、Linux PPC 64、zLinux 64、Microsoft Windows AMD64 和 Linux AMD64）上启用压缩引用。

   64 位 Java SE 运行时环境 (JRE) V6.0 的 IBM 实现的压缩引用选项可让您将所有内存引用限制为 32 位大小。与 32 位 JVM 相比，64 位 JVM 通常使用更多堆空间，因为它们使用 64 位内存引用来对内存进行寻址。可通过 64 位引用寻址的堆比 32 位的堆大几个数量级，但在现实生活中，通常不需要使用必须所有 64 位来进行寻址的堆。压缩引用可减少地址的大小并提高堆的使用效率。压缩这些引用还可以提高处理器高速缓存和总线利用率，从而提高性能。

    避免故障： 
   在以下 JVM 上不支持压缩引用功能：

   • HP-UX 64 位 JVM
   • iSeries? 传统 64 位 JVM

   缺省情况下，如果堆大小（由 -Xmx 参数控制）设置为在特定堆大小之下（约为 25 GB，具体视平台而定），那么在受支持的平台上产品会自动启用指针压缩，否则会缺省为非压缩引用。用户可以使用下面的命令行选项来覆盖这些缺省值。

   以下命令行选项控制压缩引用功能： -Xcompressedrefs 此命令行选项启用压缩引用功能。使用此命令行选项启动 JVM 时，它将使用 32 位宽内存引用来对堆进行寻址。此功能最多可以使用特定堆大小（约 29GB，具体视平台而定），由 -Xmx 参数控制。 -Xnocompressedrefs 此命令行选项显式禁用压缩引用功能。使用此命令行选项启动 JVM 时，它将使用 64 位宽内存引用来对堆进行寻址。如果需要，用户可使用此选项来覆盖指针压缩的缺省启用。
8. 调整大型单元配置的配置更新进程。
   在大单元配置中，您可能必须确定是配置更新性能还是配置一致性检查更重要。Deployment Manager 为整个单元维护一个主配置存储库。缺省情况下，当该配置更改时，产品会将工作空间中的配置与主存储库进行比较以保持工作空间的一致性。然而，一致性验证过程会导致增加保存配置更改或部署大量应用程序所需的时间。以下因素影响所需的时间：

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

   1. 在管理控制台中，单击系统管理 > Deployment manager。
   2. 在“服务器基础结构”下，选择“Java 和进程管理”，然后单击进程定义。
   3. 在“其他属性”下，单击 Java 虚拟机 > 定制属性 > 新建。
   4. 在“名称”字段中输入 config_consistency_check，在“值”字段中输入 false。
   5. 单击确定，然后将这些更改保存到主配置。
   6. 重新启动服务器。
    支持的配置： config_consistency_check 定制属性仅影响 Deployment Manager 进程。它不会影响其他进程，包括 Node Agent 进程和应用程序服务器进程。不会对这些进程执行一致性检查。然而，在这些进程的 SystemOut.log 文件中，您可能会看到一个表示禁用了一致性检查的注释。对于非 Deployment Manager 的进程，您可以忽略此消息。

   如果要以本地方式使用 wsadmin 命令 wsadmin -conntype none，那么在发出此命令之前，必须将 config_consistency_check 属性设置为false。