JRockit JVM优化清单/调优指南摘要
验证当前的JRockit环境
首先需要确定您的运行时应用程序服务器所使用的JRockit的版本。为此，可以查看相应应用程序服务器的日志文件。也可以使用适当的脚本设置系统环境，然后执行java –version命令来确定JRockit的版本。
接着，收集当前JVM标志，开发和/或生产阶段需要用到它们： -server -Xms1024m -Xmx1536m -Xverboselog:gc.log -Xverbose:memory
-Xgcprio:throughput这将告诉您当前JRockit实例的配置情况。
确定应用程序的目标
确定应用程序的目标是什么。是“响应快”还是“性能高”？根据目标的不同，需要设置不同的垃圾收集算法。
例如，如果应用程序的目标是实现高性能，则确保设置了Dynamic Garbage Collector “-Xgcprio:throughput” 选项。如果目标是响应时间短，那么需要将-Xgcprio:pausetime -Xpausetarget=XXX’中的pausetarget设置为最佳值。有关更多细节，请查看JRockit 调优文档。
收集故障诊断数据
如果JVM性能有问题，那么最好是先收集一些分析数据。该工作可以由团队中有相关经验的人员来完成，您也可以将这些信息发送给BEA Support做进一步分析。
首先，出现问题时需要收集大约10分钟的运行时JRockit Recording（JRA)数据。可以使用jrcmd.sh实用工具或 JRockit Mission Control（JRMC）完成此操作。请阅读“性能测试期间的JRCMD/JRA”和“JRockit Mission Control”两节的内容。有关详细信息，请参阅 JRockit Mission Control文档。Latency Analysis一节提供许多有价值的内容，我们可以从中了解任何潜在的延迟问题（在JRockit中需要一个许可证就可以使用它）。
然后，需要收集问题发生时的一些详细日志。方法是在启动服务器实例的时候在JVM命令行输入以下参数： -Xverboselog:perTestGC.log

-Xverbosetimestamp -Xgcreport这样会将有价值的分析数据收集到刚才配置的perTestGC.log文件中。团队成员和/或BEA Support可以对这些数据进行分析。
最后一点：通常，应用程序不会请求执行垃圾收集（也就是在应用程序代码中调用System.gc()）。但如果您怀疑它有问题，那么可以在启动服务器实例的时候，在Java命令行使用-XXnoSystemGC参数来禁用它。
现在，我将介绍如何通过迭代性能测试方法解决这些问题。
迭代性能测试方案及其方法
完成初始数据的收集和分析后，我们可以通过迭代方法来调优JVM。此处介绍的测试方案是在JRockit JVM层执行迭代调优的通用方法，可以找到哪些设置可能有益于特定应用程序。假定您有测量性能结果的方法；然后，可以将它们与“基准”（您应该已经有了）进行比较。
测试1：线程本地区域大小和大对象大小
在本测试中，我们将查看线程本地区域大小。这很重要，因为如果这些标志的默认设置对于应用程序不是最佳的（多数情况下是这样），那么就会造成堆锁定，这将对性能产生影响。将大部分对象限制在一定范围内对整体性能有益。
* 分析收集的JRA Recording数据
* 分析结果，查看-XXtlasize和-XXlargeobjectlimit是否需要调优（请记住，对于多数应用程序，根据eDocs，线程本地区域大小应该至少是大对象大小的两倍）。这些内容位于JRA Recording首页的右上方。请查看下面关于 tlaSize 和 largeObjectLimit 的信息。在JRockit R27.3之前的��数情况下，这些都不必调优。
注意：为了确保在稳定状态下获取配置文件和���量，应用程序需要有足够的热启动时间。要在性能分析过程中检查是否符要求，可以查看JRA Recording中的优化标签，其中性能分析前后的优化数量和优化时间应该大致（理论上应该是准确地）相等。
测试2：锁性能分析
现在让我们看一下锁性能分析，它会显示在应用程序中是否有过多的锁定。如果确实如此的话，那么将对整体性能造成影响。
* 运行测试（启用-Djrockit.lockprofiling），分析这些结果。确定没有通过JVM启用的日志。该标志大概会占用5%到10%的系统开销，一个单独的测试将收集该数据，此时性能被忽略，唯一做完的分析是锁定分析。 -server -Xms1536m -Xmx1536m -Djrockit.lockprofiling    * 在相同测试中，使用jrcmd.sh实用工具或JRockit Mission Control（JRMC）热启动应用程序后，运行10分钟的JRA Recording。有关如何使用该工具的信息，请参见电子文档。
* 使用top和iostat选项监控操作系统，如果需要的话还可使用ctrhandler.act文件指定的信息执行线程转储。
* 分析结果。
测试3：调优tlaSize和largeObjectLimit
在这个测试中，我们将根据前面测试的结果调优线程本地区域大小和大对象限制。
* 确定JVM未启用日志。将 –XxtlaSize和-XXlargeObjectLimit的值设置较高一点可能会有所帮助。但是，要验证和比较这点则需要需要长时间运行测试。对于 R27.2，将preferredSize设置为16k可能有所帮助。您可以查看关于这一问题的 详细信息。为此要，更改TLA设置并使用与测试1相同的Java命令行选项重新运行测试；增加-XXtlaSize和-XXlargeobjectlimit的TLA值设置。相关信息，请参见 tlaSize。注意：在R27.3之前，提高性能通常不需要调优这些标志。事实上，过度调优这些标志很可能带来负面���响。
* 在相同测试中，使用jrcmd.sh实用工具或JRockit Mission Control（JRMC）热启动应用程序后，运行10分钟的JRA Recording。关于如何使用该工具的信息，请参见电子文档。
* 使用top和iostat选项监控操作系统，如果需要的话还可使用ctrhandler.act文件指定的信息执行线程转储。
* 分析结果。
测试4：调优垃圾收集算法
本节测试的目的是运行各种不���的垃圾收集算法设置，并查看哪种设置对于应用程序最佳。关于 -XXsetGC标志 的详细令牌，请阅读以下内容。JRockit将以调优的nursery大小运行并移除-Xgcprio:throughput标志。该 throughput选项将在这些双版本的垃圾收集器之间自动切换，但进行直接的选择可能带来一些额外的性能上的好处。Nursery调优的目的是使被提升的对象保持较少的数量，因为这是nursery收集中代价高的部分。通过增加和减小nursery的大小对其调优。nursery的大小主要依赖于对象生存的时间，因为如果它们生存着，则在YC期间会得到提升。运行jrcmd <ID>版本查看哪个当前垃圾收集器策略是活动的。
* a. 测试4-1：     *   o 使用–XxsetGC垃圾收集算法设置运行测试。该测试将设置垃圾收集选项为单倍行距加上并行标记算法和并行扫描算法；还要手动调优nursery大小： -server -Xms1536m -Xmx1536m -Xns:384m-Xverboselog:perTestGC.log

    *   o 在相同测试中，使用jrcmd.sh实用工具或JRockit Mission Control（JRMC）热启动应用程序后，运行10分钟的JRA Recording。关于如何使用该工具的信息，请参见电子文档。
o 使用top和iostat选项监控操作系统，如果需要的话还可使用ctrhandler.act文件指定的信息执行线程转储。
o 分析结果。
* b. 测试4-2：     *   o 用 –XxsetGC运行一个使用垃圾收集算法集的测试。该测试将设置垃圾收集选项为分代的（双倍行距）加上并行标记算法和并行扫描算法；还要手动调优nursery大小： -server -Xms1536m -Xmx1536m -Xns:384m-Xverboselog:perTestGC.log

    *   o 在做这个测试的时候，使用jrcmd.sh实用工具或JRockit Mission Control (JRMC)收集应用程序热启动并运行后10分钟的JRA Recording。关于如何使用该工具，请参见eDocs。
o 使用top、iostat，需要的话，还可用带有ctrhandler.act文件给定的信息的线程转储来监控正在运行的系统。
o 分析结果。
* c. 测试4-3：根据前面的-XXsetGC:genparpar测试向上或向下调优nursery大小。
* d. 测试4-4：用-Xgc:gencon -Xns50m（和设为收集规格的日志）试试。
* e. 测试4-5：用-Xgc:parallel -XXcompactratio:1（和设为收集规格的日志）试试。
测试5：调优垃圾收集线程
本测试的目的是查看gcthreads标志设置对整体性能的影响。
* 根据前面的结果，调优-XXgcthreads标志为实际物理CPU的数量并重新运行测试(由于这些值默认是基于机器上核心和硬件线程的数量，所以这应该是自动调优的)。您可以查看在“收集故障诊断数据”一节收集的详细输出日志来对其验证。更多细节请参见 gcThreads flag。
测试6：调优锁争用
如果在胖锁（fat lock）上存在锁争用，则可以用-XXdisableFatSpin禁止它们，或者用 -Djrockit.useAdaptiveFatSpin=true让JRockit自适应地禁止它们。当测试2启用 -Djrockit.lockprofiling时，可以通过在JRA中查看那个标签来确定这一点。更��细节，请参见locking in JRockit。
测试7：调优Xeon硬件
如果运行在Xeon硬件之上，那么可以添加-XXallocPrefetch和-XXallocRedoPrefetch，它们与TLA和LargeObjectLimit一起将有助于减少内存分配的开销。有关详细信息，请参见 allocPrefetch标志。为了得到最佳的结果，您可能会在BIOS中禁用硬件预取指令。虽然操作方式取决于BIOS的牌子，但参数的名称通常都为“Hardware Prefetcher”、“Adjacent Sector Prefetcher”、“Adjacent Cache Line Prefetcher”等。更多信息请参见 Intel on this subject。
测试8：将堆放入largePage
这会将堆锁入内存，使操作系统不能将其交换出来。更多信息请参见 largePages标志，有关Linux操作系统端配置的更多信息还可以参考 在Linux上配置-XXlargePages 一节。在JRockit R27版中，该选项的名称为-XlargePages。根据前面的结果，调优-XlargePages标志可能有所帮助，但可能也没有。使用该标志运行测试，查看结果否对整体性能有帮助。
测试9：用-XXaggressive标志测试
本节中的这些配置将使JVM高速运行并尽快达到稳定状态。为了实现此目标，JVM在启动时需要更多内部资源；但当目标一旦达成，��所需要的自适应优化将更少。我们推荐您为了那些单独工作的、运行时间长的、内存敏感的应用程序使用这个选项。更多细节请参见 aggressive标志。使用-XXaggressive标志运行测试，查看结果否对整体性能有帮助。
测试10：用-XX:+UseNewHashFunction标志测试
这个选项支持一个新的、更快的HashMap散列函数，它在Java 5.0 Update 8中引入，从R27.1.0开始也是BEA JRockit的一部分。这个散列函数能够通过改进的散列扩展提高性能而不改变HashMap中元素存放的顺序。更多细节请参见 UseNewHashFunction标志。使用这个新的-XX:+UseNewHashFunction运行测试，，查看结果否对整体性能有帮助。
测试11：将暗物质减到最少
“暗物质”指被浪费的堆内存，它使堆成为许多碎片。了解如何最大程序地减少暗物质，以便当堆需要压缩时，整体吞吐量不受影响。请看以下选项：
* 使用分代的垃圾收集器 (-Xgc:gencon or -Xgc:genpar)。在初始收集（nursery垃圾收集）期间，在nursery中被发现生存的对象被迁移到旧的一代。这样有好的副作用，当迁移对象时可以压缩它们。
* 提高压缩比（-XXcompactionRatio=nn）。通过将对象迁移到压缩块中、消除它们之间的暗物质，压缩减少了暗物质。
* 通过-XXminBlockSize:<memSize>选项修改规范（将什么视为暗物质？）。堆上小于最小块大小的块视为暗物质。因此，通过减小最小块大小，您最终减少了暗物质。但请注意，因为JRockit为了释放堆空间必须做更细密的搜索，所以垃圾收集的时间会更长。最小块大小默认为2 KB。
进一步测试：调优应用程序服务器层
最后，查看上述调优建议，调优WebLogic Server实例层。
该贴被zhou编辑于2012-11-30 13:48:13