调整 IBM Java 虚拟机

应用程序服务器是基于 Java™ 的服务器，需要 Java 虚拟机 (JVM) 环境来运行并支持在其上运行的企业应用程序。 在配置应用程序服务器的过程中，可以配置 Java SE 运行时环境以调整性能和系统资源使用情况。 本主题适用于 IBM® Java 虚拟机。

1. 限制在特定情况下执行的转储数。

   在特定错误情况下，多个应用程序服务器线程可能会失败，而 JVM 将为其中的各个线程请求 TDUMP。 如果大量线程同时发生故障，那么生成的并发 TDUMP 数可能会导致其他系统问题，例如。 作为辅助存储器的短缺。 可使用 JAVA_DUMP_OPTS 环境变量来指定您希望 JVM 在特定情况下生成的转储数。 为该变量指定的值不会影响因应用程序服务器上运行的应用程序调用com.ibm.jvm.Dump.SystemDump() 而生成的 TDUMPS 数量。

   例如，如果您要配置 JVM，使得它：

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

   然后，将 JAVA_DUMP_OPTS 变量设置为以下值：

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

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

   在某些环境（例如，开发环境）中，提高应用程序服务器的启动性能比提高运行时性能更重要。 在另一些环境中，优化运行时性能更为重要。 默认情况下，IBMJava 虚拟机针对运行时性能进行了优化，而HotSpot-basedJVM 则针对启动性能进行了优化。

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

   • -Xquickstart

     此设置会影响 IBM Java 虚拟机如何对类方法编译使用降低的优化级别。 低优化级别可提供更快的服务器启动，但会降低运行时性能。 如果未指定此参数，那么 IBM Java 虚拟机缺省为从高初始优化级别开始进行编译，这将导致运行时性能更快，但服务器启动速度更慢。

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

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

   要加快 JVM 初始化速度并缩短服务器启动时间，请在 "配置" 选项卡的 "常规属性" 部分的 常规 JVM 参数 字段中指定以下命令行参数。

   -Xquickstart
   -Xverify:none
   

3. 配置堆大小。
   注: 除非更改或更新 heapsize 值，否则缺省最大堆大小不会显示在集成解决方案控制台中。

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

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

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

   Java 堆信息包含在 SMF 记录中，可以使用 DISPLAY,JVMHEAP 控制台命令动态查看。

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

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

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

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

      “初始堆大小”设置指定 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 的试验。 在每次实验期间，监视全部内存使用情况。 如果您对堆扩展太多，那么可能发生页面调度。

      如果发生页面调度，那么减少堆大小或将更多的内存添加到系统。

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

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

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

      如果堆可用空间设置为 85% 或更多，请考虑减小最大堆大小值，因为应用程序服务器和应用程序未充分利用为堆分配的内存。

      如果您有配置为以 64 位方式运行的服务器，那么可以为这些服务器指定远远大于缺省设置的 JVM 最大堆大小。 例如，如果服务器配置为以 64 位方式运行，那么可对控制器和服务方指定 1844 MB 初始最大堆大小。

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

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

   • -Xms

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

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

   • -Xmx

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

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

     避免麻烦: 为 -Xmx 参数指定值以减少可能的内存不足问题。
4. 调整 Java 内存。
   以 Java 语言编写的企业应用程序涉及复杂的对象关系，并使用大量对象。 虽然 Java 语言会自动管理与对象生命周期相关联的内存，但了解对象的应用程序使用模式很重要。 特别要验证以下条件是否存在：

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

      您可以通过观察 JVM 运行时的计数器，检查应用程序是否是过度使用的对象。 您必须指定 -XrunpmiJvmtiProfiler 命令行选项以及 JVM 模块最大级别，以便启用 Java 虚拟机概要分析程序接口， JVMTI 和计数器。 垃圾回收之间的最佳平均时间至少是单次垃圾回收的平均持续时间的 5 到 6 倍。 如果没有达到此数字，那么应用程序将多用 15% 的时间用于垃圾回收。

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

   2. 测试内存泄漏。

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

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

      进行内存泄漏测试的目标是扩大数字。 根据无法进行垃圾回收的字节或千字节量评测内存泄漏。 此精细任务将区别有用内存和不可用内存预期大小的量。 如果数字被放大，这一任务就更容易实现，从而产生更大的差距，更容易识别不一致之处。 以下列表可让您了解如何解释内存泄漏测试结果：

      • 长期运行测试

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

      • 重复测试

        在很多情况下，内存泄漏问题通过同一测试用例的连续重复使用而发生。 内存泄漏测试的目标是在不可用内存和已用内存的相对大小之间建立一个很大的差距。 通过反复重复同一场景，以渐进的方式倍增差距。 如果由于执行测试用例而导致的泄漏的数量非常少，以至于在一次运行中几乎不明显，那么此测试将提供帮助。

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

      • 并发性测试

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

        选择要用于内存泄漏测试的测试用例时，请考虑以下几点:

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

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

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

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

5. 调整垃圾回收

   在大多数垃圾回收循环期间，JVM 使用并行垃圾回收器以最大程度地利用 SMP。

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

   在运行固定工作负载时监视垃圾回收，为您提供有关应用程序是否过度使用对象的洞察。 垃圾回收甚至可以检测到是否存在内存泄漏。

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

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

   要调整 JVM 垃圾回收设置：

   1. 在管理控制台中，单击 服务器> 服务器类型> WebSphere 应用程序服务器> server_name。
   2. 在 "服务器基础结构" 部分中，单击 Java 和进程管理> 进程定义> 服务方。
   3. 在 "其他属性" 下，单击 环境条目。
   4. 添加或更新 IBM_JAVA_OPTIONS 的环境条目，如下所示。
      1. 如果您看到名为 IBM_JAVA_OPTIONS 的现有环境条目，请对其进行编辑，以将要添加的 -X Java 选项附加到现有值。
      2. 否则，单击新建以创建新的环境条目。 在表单的各个相应字段中填写以下值：

         信息	值
         名称：	IBM_JAVA_OPTIONS
         值：	要添加的 -X Java 选项
         描述：	该选项的描述

      此过程更新 "WebSphereApplication服务器配置目录中的 "was.env文件。 此更改将设置应用于所有服务方区域，控制区域和助手区域。

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

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

   用于 Java 垃圾收集器的 IBM 虚拟机。

   在 IBM SDK Java Technology Edition V 8 User Guide中提供了 Java 垃圾收集器的 IBM 实现的完整指南。

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

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

     注: 虽然每个策略都提供了独特的优点，但对于 WebSphere Application Server V 8.0 和更高版本， gencon 是缺省垃圾回收策略。 应用程序服务器的先前版本指定 optthruput 作为缺省垃圾回收策略。

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

6. 启用本地主机名高速缓存
   缺省情况下，在 IBM SDK for Java 中，静态方法 java/net/InetAddress.getLocalHost 不会高速缓存其结果。 此方法在整个 WebSphere Application Server中使用，但尤其在诸如 Deployment Manager 和 Node Agent 之类的管理代理程序中使用。 如果进程的本地主机地址在进程运行期间不会更改，那么建议通过将 com.ibm.cacheLocalHost 系统属性的值设置为 true 以使用内置高速缓存查找本地主机。 请参阅文档中的 "Java 虚拟机定制属性" 主题，以获取有关在各种类型的进程上设置 JVM 定制属性的指示信息。

   避免麻烦: 使用 DHCP 配置的服务器的地址随时间变化。 除非为服务器使用静态分配的 IP 地址，否则请勿设置此属性。

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

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

   通过在高速缓存中共享类，可以缩短启动时间并减少内存使用量。 进程（例如应用程序服务器、节点代理程序和 Deployment Manager）可以使用共享类选项。

   缺省情况下，此选项在应用程序服务器中处于启用状态。

   如果使用此选项，请在服务器进程未在使用时清除高速缓存。 要清除高速缓存，请停止所有服务器进程，然后调用 app_server_root/bin/clearClassCache.sh 脚本，或者通过停止应用程序服务器来清除高速缓存，然后重新启动应用程序服务器。

   注: 使用 clearClassCache 来清除整个高速缓存时，必须停止所有连接的 JVM。

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

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

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

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

   您可以在 64 位环境 (例如 AIX® 64 ， Linux® PPC 64 ， zLinux 64 和 Microsoft Windows AMD64， Linux AMD64) 上启用压缩引用。

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

   在以下 JVM 上不支持压缩引用功能：

   • HP-UX 64 位 JVM
   • iSeries 经典 64 位 JVM

   To enable a 64-bit JVM to run in the compressed references mode, you need to specify a new environment variable in WebSphereApplication Server configuration. 在管理控制台中：

   1. 单击: 服务器> 服务器类型> WebSphere Application Server> server_name。
   2. 单击“配置”选项卡。 在 "服务器基础结构" 下，单击 Java 和进程管理> ProcessDefinition > 服务方。
   3. 在“其他属性”下，单击环境条目。
      为 IBM_JAVA_OPTIONS 添加或更新环境条目，如下所示：

      1. 如果您看到名为 IBM_JAVA_OPTIONS 的现有环境条目，请对其进行编辑，以将 Java 选项 -Xcompressedrefs 附加到现有值。
      2. 否则，单击新建以创建新的环境条目。 在表单的各个相应字段中填写以下值：

         信息	值
         名称：	IBM_JAVA_OPTIONS
         值：	-Xcompressedrefs
         描述：	启用 64 位压缩引用方式

   此过程更新 "WebSphereApplication服务器配置目录中的 "was.env文件。 此更改将设置应用于所有服务方区域，控制区域和助手区域。

   避免麻烦：提供 "Xcompressedrefs作为通用 JVM 参数时，WebSphereApplicationServer 会因为不支持 Java 选项错误而无法启动。 如果应用程序需要超过 30 GB 的 Java 堆，那么应使用 64 位缺省方式

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

   注: WebSphere Application Server for z/OS 不会自动启用指针压缩。 系统会建议用户使用命令行选项手动启用指针压缩。

   注: 对于 Java 8 SR2 FP10，或者对于 z/OS Java 8 SR3，缺省情况下已启用 -Xcompressedrefs 选项，最多可以使用 57GB 与更高的值配合使用，具体取决于平台。

   以下命令行选项控制压缩引用功能：

   -Xcompressedrefs

   此命令行选项启用压缩引用功能。 使用此命令行选项启动 JVM 时，它将使用 32 位宽的内存引用来寻址堆。 此功能最多可以使用特定堆大小（约 29GB，具体视平台而定），由 -Xmx 参数控制。

   -Xnocompressedrefs

   这些命令行选项显式禁用压缩引用功能。 当 JVM 使用此命令行选项启动时，它将使用完整的 64 位宽内存引用来寻址堆。 如果需要，用户可使用此选项来覆盖指针压缩的缺省启用。

9. 调整大型单元配置的配置更新进程。
   在大单元配置中，您可能必须确定是配置更新性能还是配置一致性检查更重要。 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 文件中，您可能会看到一个表示禁用了一致性检查的注释。 对于这些非部署管理器进程，可以忽略此消息。

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