调整 IBM Java 虚拟机(转载)

pqwsa

调整 IBM Java 虚拟机
　　http://www-01.ibm.com/support/knowledgecenter/#!/SSEQTP_7.0.0/com.ibm.websphere.base.doc/info/aes/ae/tprf_tunejvm_v61.html
　　-----------------------------------------------------------------------------------------------------------------------------------------------


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



在您开始之前

• 确定运行应用程序服务器的 JVM 的类型。　　从应用程序服务器的 app_server_root/java/bin 目录中发出java –fullversion 命令。
  　　作为对此命令的响应，Java 会将关于 JVM 的信息（包括 JVM 提供程序信息）写入 SystemOut.log文件中。
  　　如果您的应用程序服务器正在 Sun HotSpot JVM 上运行，请参阅主题“调整Sun HotSpot Java 虚拟机（Solaris 和 HP-UX）”。
  
  
• 请验证：
  
  
  • 系统上安装了最新版本的受支持 JVM。
    
  • 系统上安装了最新的服务更新。几乎每个新的服务级别都包括 JVM 性能改进。
    
  
  

关于本任务
　　每个 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 执行下列类型的调整的特定指示信息。您不必按任何具体的顺序来执行这些步骤。

过程

• 限制特定情况下执行的转储数。　　在特定错误情况下，多个应用程序服务器线程可能会失败，而 JVM 将为其中的各个线程请求 TDUMP。如果大量线程同时失败，那么所产生的同时执行的TDUMP 数可能会导致其他系统问题，例如缺乏辅助存储器。可使用 JAVA_DUMP_OPTS 环境变量来指定您希望 JVM 在特定情况下生成的转储数。为此变量指定的值不会影响生成的 TDUMP 数，这是因为com.ibm.jvm.Dump.SystemDump() 调用是从在应用程序服务器上运行的应用程序执行的。
  
  
  例如，如果您要配置JVM，使得它：
  
  
  
  • 将执行的 TDUMP 数限制为 1
    
  • 将执行的 JAVADUMP 数限制为最大值 3
    
  • 如果发生 INTERRUPT，那么不捕获任何记录
    
  
  
  然后，将 JAVA_DUMP_OPTS 变量设置为以下值：
  JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE)
  
• 优化启动和运行时性能。　　在某些环境（例如开发环境）中，提高应用程序服务器的启动性能比提高运行时性能更重要。在另一些环境中，优化运行时性能更为重要。缺省情况下，IBM Java 虚拟机针对运行时性能进行优化，而基于 HotSpot 的 JVM 针对启动性能进行优化。
  　　Java 即时 (JIT) 编译器影响是否优化启动性能或运行时性能。编译器使用的初始优化级别影响编译类方法所需的时间以及启动服务器所需的时间。为了提高启动速度，请降低编译器所使用的初始优化级别。但是，如果降低初始优化级别，由于现在使用较低的优化级别来编译类方法，所以应用程序的运行时性能可能会下降。
  
  
  
  
  • -Xquickstart　　此设置影响 IBM Java 虚拟机使用较低优化级别来编译类方法的方式。较低的优化级别将提高服务器启动速度，但会使运行时性能下降。缺省情况下，如果未指定此参数，IBM Java 虚拟机最初将使用较高的初始优化级别来执行编译，这将提高运行时性能，但会减慢服务器启动速度。
    
    

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

    
    
  
  
• 配置堆大小。　　Java 堆参数会影响垃圾回收的行为。增加堆大小会支持更多对象创建。由于大的堆要用较长时间进行填充，所以在垃圾回收发生前应用程序会运行较长时间。但是，较大的堆也会用较长时间进行压缩，导致垃圾回收的时间也较长。
  
  
  JVM 使用定义的阈值来管理分配给它的存储器。当达到阈值时，将会调用垃圾回收器以释放未使用的存储器。因此，垃圾回收会导致 Java 性能显著下降。在更改初始堆大小和最大堆大小之前，应考虑下列信息：
  
  
  
  • 在大多数情况下，您应将最大 JVM 堆大小设置为比初始 JVM 堆大小更大的值。此设置允许 JVM 在正常的稳定状态期间能够在初始堆大小范围内高效地运行。此设置还允许 JVM 在事务高峰期也能够高效地运行，因为 JVM 可以将堆大小最多扩大至最大 JVM 堆大小指定的值。在某些需要绝佳性能的罕见情况下，您可能要对初始堆大小和最大堆大小指定相同的值。此设置消除了某些当JVM 扩大或减小 JVM 堆大小时出现的开销。在更改任何 JVM 堆大小之前，请验证 JVM 存储器分配足够大，可以容纳新的堆大小。
    
  • 不要使初始堆的大小太大，使得初次通过延迟垃圾回收来提高性能时，在垃圾回收进行期间，回收进程影响响应时间，因为该进程必须运行更长的时间。
    
  　　要使用管理控制台来配置堆大小：
  
  
  
  
  • 在管理控制台中，单击服务器 > 服务器类型 > WebSphere Application Server > server_name。
    
  • 在“服务器基础结构”部分中，单击Java 和进程管理 > 进程定义 > Java 虚拟机。
    
  • 在初始堆大小或最大堆大小字段中指定新值。　　如果需要同时调整这两项设置，也可以对这两个字段都指定值。
    　　为进行性能分析，初始堆大小和最大堆大小应该相等。
    　　“初始堆大小”设置指定 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% 或更多，那么考虑降低堆大小的最大值，这是因为应用程序服务器和应用程序未充分利用为堆分配的内存。
    　　
    
    
  • 单击应用。
    
  • 单击保存以保存您对主配置所作的更改。
    
  • 停止然后重新启动应用程序服务器。
    
  　　还可使用下列命令行参数来调整这些设置。这些参数适用于所有受支持的JVM，用于调整每个应用程序服务器或应用程序服务器实例的最小堆大小和最大堆大小。
  
  
  
  
  • -Xms　　此参数控制 Java 堆的初始大小。调整此参数有助于降低垃圾回收开销，从而缩短服务器响应时间并提高吞吐量。对于某些应用程序，此选项的缺省设置可能会太低，这将导致发生大量小型垃圾回收。
    
    
    
    

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

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

    缺省值	256 MB
    建议	随工作负载的不同而有所变化，但高于缺省值，并取决于可用物理内存量。
    用法	指定 -Xmx512m 会将最大堆大小设置为 512 MB。

    
    
  •   -Xlp 　　将此参数与IBM Java 虚拟机配合使用以在使用大页（例如 16 MB 页）时分配堆。在指定此参数之前，请验证操作系统是否配置为支持大页。使用大页可以降低 CPU 跟踪堆内存时的开销，并且还允许创建较大的堆。
    
    
  • –Xlp64k 　　可使用此参数来使用中等大小页（例如 64 KB）分配堆。由于硬件效率与页大小相关，因此，对应用程序所需的内存使用此虚拟内存页大小可以提高该应用程序的性能和吞吐量。
    i5/OS 和 AIX® 提供了约64 KB 页的丰富支持，因为 64 KB 页意向为通用页。64 KB 页启用容易，并且当使用 64 KB 页而不是4 KB 页（此为缺省设置）时，应用程序可以获得性能优点。您可以更改此设置，而不必更改操作系统配置。但是，如果您启用64KB 页，那么建议您在独立的存储池中运行应用程序服务器。
    要支持64 KB 页大小，请在管理控制台中，单击服务器> 应用程序服务器 > server_name > 进程定义 > 环境条目 > 新建，然后在名称字段中指定LDR_CNTRL，在值字段中指定 DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K。
    
    

    缺省值	4 KB
    建议	-Xlp64k 会启用 64 KB 页大小支持。 POWER5+™ 系统和具有 5300-04 建议维护包的AIX 5L™ V5.3 在运行 64 位内核时支持 64 KB 页大小。

    
    
  
  
• 调整 Java 内存。
  
  用 Java 语言编写的企业应用程序涉及复杂对象关系，并使用大量对象。虽然 Java 语言会自动管理与对象生命周期关联的内存，但是了解对象的应用程序使用模式仍然重要。特别要验证以下条件是否存在：
  
  
  
  • 应用程序不是过度使用的对象
    
  • 应用程序不是泄漏对象
    
  • 已正确设置 Java 堆参数以处理给定的对象使用模式
    
  
  
  
  
  • 检查是否过度使用对象。　　可以查看包括在 Tivoli Performance Viewer 报告中的 JVM 运行时的计数器，以确定应用程序是否越载使用对象。必须指定-XrunpmiJvmtiProfiler 命令行选项和 JVM 模块最大级别才能启用Java 虚拟机概要分析程序接口 JVMTI 计数器。
    　　垃圾回收之间的最佳平均时间至少是单次垃圾回收的平均持续时间的 5 到 6 倍。如果没有达到此数字，那么应用程序将多用 15% 的时间用于垃圾回收。
    　　如果信息表明产生了垃圾回收瓶颈，那么有两种方法清除瓶颈。最划算的方法是优化应用程序以实现对象高速缓存和池。使用 Java 概要分析程序确定目标对象。如果您无法优化应用程序，请尝试添加内存、处理器和克隆。添加的内存允许每个克隆保持合理的堆大小。添加的处理器允许克隆并行运行。
    
    
  • 测试内存泄漏。　　内存泄漏在 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 命令来查看内存选项列表。
    
    
  
  
• 调整垃圾回收　　检查 Java 垃圾回收可了解应用程序将如何利用内存。垃圾回收是 Java 的特质。通过从应用程序写程序中除去内存管理负担，Java 应用程序比使用不提供垃圾回收的语言编写的应用程序更可靠。只要应用程序不滥用对象，就可以保持此可靠性。垃圾回收通常占用正常运行的应用程序总运行时间的5% 到 20%。如果不进行管理，那么垃圾回收会是应用程序的一个最大的瓶颈。
  　　如果在固定工作负载正在运行时监视垃圾回收，那么可让您了解应用程序是否越载使用对象。垃圾回收甚至可以检测到是否存在内存泄漏。
  　　可以使用 JVM 设置来配置垃圾回收的类型和行为。当JVM 由于连续空间不足而无法从当前堆中分配对象时，将调用垃圾回收器从不再使用的Java 对象中回收内存。每个 JVM 供应商都提供了独特的垃圾回收器策略和调整参数。
  　　可在管理控制台中使用冗余垃圾回收设置来启用垃圾回收监视。此设置的输出包括类垃圾回收统计信息。生成的报告的格式在不同的 JVM 之间或发行级别之间并无一定标准。
  　　要调整 JVM 垃圾回收设置：
  
  
  
  
  • 在管理控制台中，单击服务器 > 服务器类型 > WebSphere Application Server > server_name。
    
  • 在“服务器基础结构”部分中，单击Java 和进程管理 > 进程定义 > Java 虚拟机。
    
  • 在通用 JVM 参数字段中输入要更改的 –X 选项。
    
  • 单击应用。
    
  • 单击保存以保存您对主配置所作的更改。
    
  • 停止然后重新启动应用程序服务器。
    
  　　以下列表描述不同 JVM 垃圾回收器的 –X 选项。
  
  IBM Java 虚拟机垃圾回收器。IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide 中提供了 Java 垃圾回收器的 IBM 实现的完整指南。此文档可以从developerWorks® Web 站点获得。　　使用Java -X 选项来查看内存选项列表。
  
  
  
  
  • -Xgcpolicy
    
    IBM Java 虚拟机提供了四种垃圾回收策略。每种策略都有独特的优点。
    
    
    
    • optthruput 是缺省策略，它可提供高吞吐量，但垃圾回收暂停时间较长。在垃圾回收期间，将停止所有应用程序线程，以便进行标记、清理并根据需要进行压缩。optthruput 策略适合大多数应用程序。
      
    • optavgpause 策略通过在应用程序运行期间执行垃圾回收的标记和清理阶段来缩短垃圾回收暂停时间。此策略会对整体吞吐量产生轻微的性能影响。
      
    • gencon 是与分代垃圾回收器配合使用的策略。分代模式尝试实现高吞吐量并同时缩短垃圾回收暂停时间。为了实现此目标，将堆分为新区域和旧区域。长生命周期对象将被提升到旧空间，而短生命周期对象将在新空间中被迅速地作为垃圾回收。gencon 策略能使许多应用程序受益匪浅。但是，它并不适合所有应用程序，并且通常难以调整。
      
    • subpool 策略可以提高多处理器系统（通常使用 8 个以上处理器）的性能。此策略仅适用于IBM System i™ System p™ 和 System z™ 处理器。除了将堆划分为子池以提高对象分配可伸缩性以外，subpool 策略与optthruput 策略类似。
      
    
    

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

    　　将 gcpolicy 设置为 optthruput 会禁用并发标记。除非应用程序响应时间不规律（这表示可能存在暂停时间问题），否则，使用optthruput 策略应可获得最佳的吞吐量结果。
    　　将 gcpolicy 设置为 optavgpause 会使用缺省值来启用并发标记。此设置将减少由正常垃圾回收所引起的应用程序响应时间不规律情况。但是，此选项可能会降低整体吞吐量。
    
    
  • -Xnoclassgc　　缺省情况下，当一个类没有任何活动实例时，JVM 就会从内存中卸装该类。多次装入和卸装同一个类的开销会降低性能。
    
    
    避免故障： 可以使用-Xnoclassgc 参数来禁用类垃圾回收。但是，类垃圾回收对性能的影响通常都相当小，在基于 Java Platform, Enterprise Edition (Java EE) 的系统中，关闭大量使用应用程序类装入器的类垃圾回收可能会高效导致类数据的内存泄漏，并导致 JVM 抛出“内导不足”异常。　　如果使用此选项，那么每当重新部署应用程序时，都必须重新启动应用程序服务器，以清除来自应用程序的先前版本的类和静态数据。
    
    gotcha
    
    
    

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

    
    
  
  
  
• 在高速缓存中启用类共享。　　Java 2 Runtime Environment (J2RE) V1.5.0 的IBM 实现的共享类选项允许在高速缓存中共享类。通过在高速缓存中共享类，可以缩短启动时间并减少内存使用量。进程（例如应用程序服务器、Node Agent 和 Deployment Manager）可以使用共享类选项。
  
  
    避免故障： 在下列平台上，当前不支持 J2RE V1.5.0 的 IBM 实现：
  
  
  
  • Solaris
    
  • HP-UX
    
  
  gotcha　　如果使用此选项，那么应该在进程不在使用中时清除高速缓存。要清除高速缓存，请调用app_server_root/bin/clearClassCache.bat/sh实用程序，也可以先停止该进程，然后重新启动它。
  　　如果需要对某个进程禁用共享类选项，请对该进程指定通用 JVM 参数 -Xshareclasses:none：
  
  
  
  
  • 在管理控制台中，单击服务器 > 服务器类型 > WebSphere Application Server > server_name。
    
  • 在“服务器基础结构”部分中，单击Java 和进程管理 > 进程定义 > Java 虚拟机。
    
  • 在通用 JVM 参数字段中输入 -Xshareclasses:none。
    
  • 单击确定。
    
  • 单击保存以保存您对主配置所作的更改。
    
  • 停止然后重新启动应用程序服务器。
    
  
  
  
  

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

  
  
• 在 64 位环境（例如 AIX 64、Linux PPC 64、zLinux 64、Microsoft Windows AMD64 和 Linux AMD64）上启用压缩引用。　　64 位Java SE Runtime Environment (JRE) V6.0 的 IBM 实现的压缩引用选项可让您将所有内存引用限制为32 位大小。与 32 位 JVM 相比，64 位 JVM 通常使用更多堆空间，因为它们使用 64 位内存引用来对内存进行寻址。可通过64 位引用寻址的堆比 32 位的堆大几个数量级，但在现实生活中，通常不需要使用必须所有 64 位来进行寻址的堆。压缩引用可减少地址的大小并提高堆的使用效率。压缩这些引用还可以提高处理器高速缓存和总线利用率，从而提高性能。
  
  
  避免故障： gotcha
  
  在以下 JVM 上不支持压缩引用功能：
  
  
  
  • Solaris 64 位 JVM
    
  • HP-UX 64 位 JVM
    
  • iSeries 传统 64 位 JVM
    
  　　缺省情况下，如果堆大小（由 -Xmx 参数控制）设置为在特定堆大小之下（约为 25 GB，具体视平台而定），那么在受支持的平台上产品会自动启用指针压缩，否则会缺省为非压缩引用。用户可以使用下面的命令行选项来覆盖这些缺省值。
  
  
  以下命令行选项控制压缩引用功能：-Xcompressedrefs此命令行选项启用压缩引用功能。使用此命令行选项启动 JVM 时，它将使用32 位宽内存引用来对堆进行寻址。此功能最多可以使用特定堆大小（约 29GB，具体视平台而定），由 -Xmx 参数控制。-Xnocompressedrefs此命令行选项显式禁用压缩引用功能。使用此命令行选项启动 JVM 时，它将使用64 位宽内存引用来对堆进行寻址。如果需要，用户可使用此选项来覆盖指针压缩的缺省启用。
  
• 调整大型单元配置的配置更新进程。
  
  在大单元配置中，您可能必须确定是配置更新性能还是配置一致性检查更重要。当配置一致性检查打开时，可能需要一定量的时间来保存配置更改或部署若干应用程序。以下因素影响所需的时间：
  
  
  
  • 单元中定义的应用程序服务器或集群越多，保存配置更改所需的时间越长。
    
  • 单元中部署的应用程序服务器越多，保存配置更改所需的时间越长。
    
  
  
  如果您对更改配置所需的时间量不满意，那么可以将config_consistency_check 定制属性添加到JVM 设置中并将此属性的值设置为 false。
  
  
  • 在管理控制台中，单击服务器 > 服务器类型 > WebSphere Application Server > server_name。
    
  • 在“服务器基础结构”部分中，单击 Java 和进程管理 > 进程定义。
    
  • 在“其他属性”部分中，单击 Java 虚拟机 > 定制属性 > 新建。
    
  • 在名称字段中输入 config_consistency_check，在值字段中输入 false。
    
  • 单击应用。
    
  • 单击保存以保存您对主配置所作的更改。
    
  • 重新启动服务器。
    
  　　如果要以本地方式使用 wsadmin 命令 wsadmin-conntype none，那么在发出此命令之前，必须将 config_consistency_check 属性设置为 false。
  
  

下一步做什么？

在进行调整更改时继续收集和分析数据，直到对 JVM 的执行效果满意为止。