自动执行 Java 性能优化

http://www.oracle.com/technology/global/cn/pub/articles/brahms-tuning.html?_template=/ocom/print

作者：Carl Brahms

自动执行负载生成和性能优化过程为什么可以节省大量的时间和精力。

2008 年 9 月发布

优化可能是一项非常艰巨而费时的工作，尤其对于需要最佳性能的环境来说更是如此。优化所带来的好处是使环境更稳定、故障更少、总体性能更佳。也许您 幸运地拥有内部性能优化人员和专门的性能优化环境，如此优越的条件是非常罕见的。如果您像其他人一样，需要在有限的时间内完成性能优化，本文将为您讲述自 动执行调优过程如何比手动调优更轻松、更快捷、更全面。

性能优化的基本原则

Java 性能优化是一个持续不断的、通常历时很长且令人沮丧的过程。调优很少会一次性解决性能问题。有时，不管您添加了多少硬件，或者花了多长时间试图调整晦涩难 懂的内存参数，可能都难以达到理想性能。要获得最佳性能，需要明确的性能目标、深思熟虑的设计、坚实的执行情况，并且最终要执行彻底的性能优化。

首先要制定明确的性能目标

在采取任何步骤优化性能之前，首先要确定性能目标。这是因为预期的行为和用户数、数据量以及请求大小在很大程度上决定着您将作出什么类型的优化决策。每个环境都是唯一的，清楚地了解应用程序和环境的限制以及您希望达到的性能和负载水平，对于您日后深入过程将有所帮助。

优化 WebLogic Server 设置

可以调整的 WebLogic 设置差不多有几百个：池大小、调整连接积压缓冲、缓存、JDBC 和 JMS 设置、使用工作管理器设置优先级、集群等。您可以先从查看 WebLogic Server 的几大优化建议 开始。

查找瓶颈

问题并不总是与 JVM 或 WebLogic 设置有关。请确保正确调整操作系统和网络设置以满足应用程序要求，尤其在使用 UNIX 或 Linux 时。在负载状态下监视服务器的磁盘和网络 I/O 以及 CPU 利用情况。如果数据库性能不佳，还应检查您的数据库块大小、池大小和其他特定于供应商的性能优化设置。任何基础资源限制都可能导致显著的性能下降。

请记住，最终目的只是达到您的性能目标，而不是清除每一个瓶颈。系统中将始终存在一个瓶颈或最慢部分，但最要紧的是达到您的性能目标并使客户满意。

优化应用程序代码

设计应用程序时需要考虑性能因素，这一点是显而易见的。在当前的 SOA 环境中，应用程序很容易变得过于复杂，并存在很多影响性能的问题。设计不良的应用程序可能会引发系统资源、网络或数据库瓶颈。请使用经过验证的性能模式来设计应用程序，并使应用程序尽量简单。

优化堆

无论使用什么应用程序，如果堆不足或花费大量时间进行垃圾收集，您都应该尝试调整整个堆及其新生代的大小。可用堆的大小通常会显著提高或降低应用程序的性能。

为 WebLogic 服务器确定合适的堆大小对于提高性能非常重要。作为确定大小的一般规则，您希望在每次垃圾收集结束时释放大约一半的堆空间。换言之，即堆的大小应至少是其活动对象的两倍。

也许最基本的堆性能优化步骤是将最小堆大小设置成与最大堆大小相同。此建议同样适用于新生代（在 Sun HotSpot 中为 New generation，在 Oracle JRockit 中为 Nursery）大小的设置。默认情况下，经常出现堆扩展和堆收缩时 JVM 会浪费资源。

您尽可以将堆大小设置为系统可以处理的最大值（除去操作系统和其他应用程序所需的内存）。较大的堆会降低垃圾收集的频率，但可能需要花费较长时间来执行较大的垃圾收集。

VM 用于处理本地库和 permGen（如果使用 Sun HotSpot）的内存始终大于堆大小，因此请注意，不要超出物理 RAM 的总大小。操作系统将内存分页到磁盘时将显著降低性能。

试用垃圾收集器

垃圾收集是用于从不再使用的对象中回收堆空间的一种机制。有多种垃圾收集模式（从 JVM 到 JVM），这些模式都以不同方式使用系统资源。您在优化过程中的工作是确定什么类型的垃圾收集模式最适用于您的特定应用程序和性能目标。选择收集器时的目 标就是使垃圾收集暂停时间尽量缩短，从而提高垃圾收集吞吐量。

有关如何使用 JRockit 垃圾收集模式的信息，请参见“选择和优化垃圾收集器”部分。有关 Sun HotSpot VM 可用的垃圾收集模式的详细概述，请参见 Sun 的 Tuning Garbage Collection with the 5.0 Java Virtual Machine （使用 5.0 Java 虚拟机优化垃圾收集）。

其他注意事项

JRockit 和 Hotspot JVM 提供了许多特定的 JVM 性能选项。影响性能的 WebLogic 设置非常多。要进行有效优化，最重要的是使开发人员、架构师、系统工程师、QA 测试网络工程师和 DBA 作为一个团队进行协作。在优化过程中实现跨学科参与可以精简工作，获得更佳结果，从而最终降低优化所需的成本和时间。

自动化的优点

我们已经了解了 WebLogic 性能优化的几个基本原则，现在来看一下自动执行这些任务如何真正使性能优化更容易、更省时、更有效。

快速更改，频繁优化

我曾多次看到，自动执行性能优化过程所产生的结果比专家独自执行优化所产生的结果更好。这主要是因为，自动过程可以快速执行更改并确定和衡量更改对 性能的影响，比神经最兴奋的人还要快，还要周到。另外，由于调优变成一个省力的过程，您还可以针对每次代码发布进行优化，从而与应用程序更改取得同步。对 应用程序功能的细微更改都会导致很多预料不到的性能问题。

另外，很多人错误地认为调优是可做可不做的事情，因为他们当前的响应时间很充裕。人们很容易忽略这样一个事实，即正确的调整可以提高服务器的稳定性和持久性。不调整或错误调整可能会导致故障，而经过正确调整的环境运行起来更具可预测性且更稳定。

节省时间，挖掘性能潜力

我们在优化服务器上通常做得不够频繁或不够彻底，仅仅因为这一过程非常费时。当您自动执行此过程时，手动执行需要几天时间的工作现在在无人干预的情况下一晚上即可完成。以前花无数个小时进行调优的人员现在可以节省这些时间做更有意义的事情。

随着故障减少、性能提高、正确利用硬件、“繁重工作”减少以及可以利用节省的时间做更多工作，自动执行 Java 优化所带来的财务结余将会快速增长。在当今苛刻的环境中，性能上的细小收益通常都会带来显著的资源节省。

边看边学

了解代码更改和不同调优变量如何影响性能非常具有启发作用。自动执行优化和分析允许您尝试更多不同的设置组合，并且通过适当的监视，您可以同时看到结果。这就像站在性能专家团队的肩膀上；您开始了解为何作出某些优化决策，在这个过程中您能够学到很多知识。

您还能够针对每次代码发布轻松地优化服务器，这也算是一个很不错的意外收获吧。由于知道将不会有惊喜，因此在部署生产时，您会拥有一个比较平和的心态。

逐步执行自动优化

在本部分中，您将了解使用 Arcturus Applicare 优化向导查找最佳 JVM 设置的过程。为了节省时间，我将演示测试各种垃圾收集设置的过程。

简单来讲，优化向导将启动负载测试、监视服务器、分析行为、基于嵌入式智能作出决策、优化配置并回弹服务器。此过程将重复执行，自动优化各种 JVM、操作系统和 WebLogic 设置，直至找到最佳组合。以下是每个步骤的分解内容。

由于自动执行时优化变得非常容易，因此您可能很快就希望进行微调和试验。在优化向导中，有很多可用于控制资源利用的高级选项，我将在后面进行详细介绍。与 在任何性能优化过程中一样，您需要对应用程序行为有所了解。如果应用程序有预热时间或初始缓存时间段，必须确保运行足够时间的负载才能获取精确结果。

选择负载测试设置

优化向导与 Apache JMeter、HP Load Runner 和 The Grinder 负载生成工具进行了集成，它还能够触发您自己的自定义 Java 应用程序和 shell 脚本所生成的负载。我还没有生成负载工具设置或任何负载脚本，因此我使用 JMeter（系统自带）并遵循以下指令来记录测试脚本。

启动优化向导时，我指定了负载脚本，它允许自定义要模拟的用户数。在本次测试中我选择了 70 个用户，因为根据以前的测试我知道，当用户数达到此数值时我的应用程序性能开始下降。

第一次优化服务器时，您可能不了解您的应用程序处理多少用户才会导致性能下降。如果我不清楚我的环境可以处理多少用户，我可能会使用一个称为“容量 确定”的简洁功能（图 2），而不必进行猜测和购买更多服务器。容量确定的目的是找到良好吞吐量的最佳平衡，而不超出您的资源利用限制。容量确定允许您设置初始用户数和将要尝试 的最大用户数，在优化时它将增加负载，直至在吞吐量和资源利用之间找到平衡点。

选择测试条件

接下来，您需要选择每个优化会话要采用的监视样例数，以及这些会话之间的时间间隔。正如我在前面提到的，如果您的应用程序有预热时间或初始缓存时间 段，则此时您可以通过优化设置来确保测试时间足够长，以便得到精确的基准值。我选择每个会话采用 20 个样例，时间间隔为 60 秒。

开始“执行”

现在您可以坐下来放松一下。您还可以安排在任意时间开始优化，这样，如果您要在以后的非高峰时间进行优化，则不必亲临现场。优化向导将尝试其中每个设置，当优化结束后，优化向导会生成报表，给出有关哪些设置提供最佳性能的建议。

当服务器处于负载状态下时，优化向导将监视服务器的性能和运行情况。向导通过查看吞吐量、堆信息、CPU 利用情况、线程、等待者、队列（基本上包括了您所观察的全部内容 — 如果您亲自运行负载测试的话）完成此任务。在启动优化会话时可以设置和自定义样例之间的频率和时间间隔。

这是优化向导和 Applicare 其他功能最具吸引力、最有价值的一个方面。它随制定智能化性能优化决策的人工智能引擎一起提供。根据性能优化顾问的综合经验、经过验证的优化方法和最佳实 践构建了知识库。可以查看负载测试过程中生成的数据，并对下一步将要优化的内容作出明智的决策。优化向导在达到最佳可能组合后，将结束优化过程。

我可以在 Applicare 控制台中实时查看进度表，也可以等到测试结束后查看报表。如果您要查看数据以便得出自己的结论，可以参考大量的报表和图表，它们针对每个优化设置的行为提供了完整的详细信息。

结果

在这里，我简要讨论优化结果，显示 Applicare 创建的一些有关优化会话的图表，并讨论 Applicare 给出的一些其他建议。这不是详尽的优化练习，但它显示了优化向导在少量负载状态下可以在短时间内完成的任务。优化过程历时 4 小时完成，它尝试了 9 个不同的设置组合，并优化了 JVM 设置和其他设置，包括线程、JDBC 设置等。优化向导查找过小或过大的配置区域并进行适当设置。根据我为优化向导提供尝试的参数，最佳设置如下：

    -Xms512m -Xmx512m -XX:CompileThreshold=8000 -XX:PermSize=48m 
-XX:MaxPermSize=128m  -Xverify:none -XX:NewRatio=3 
-XX:SurvivorRatio=6 -XX:+UseParallelGC 

  

Applicare 提供一组显示优化结果的图表，为了节省空间，我给出了显示优化前后变化的吞吐量和堆图表。您可以看到堆的利用率较低，并且主要垃圾收集的暂停时间较短。您 还可以看到，在主要垃圾收集发生时吞吐量下降，这表明优化前的初始设置在主要垃圾收集期间会导致很长的暂停时间。

其他建议

Applicare 还检测到应用程序运行时行为和服务器配置方面的问题。它检测出 EJB 缓存配置不当，并建议增加缓存大小。

另外，Applicare 的诊断结果还指出，在优化过程中打开的会话数太多以致于影响了性能（有时超出 17,000 个会话）。它指出了一些实例，在这些实例中对我的应用程序的某些 Web 应用程序的会话失效间隔秒数设置过高，并建议进行重新评估，以免非活动会话打开时间过长。

幸运的是，我不必猜测或查找这些瓶颈，因为工具已将这些瓶颈清晰地显示出来。

高级选项

优化向导提供了一些预定义的选项，供每个 WebLogic 支持的 JVM 试用，以便找到适用于您的环境的最佳垃圾收集器，但它也为高级用户提供了尝试任意所需选项的灵活性。在此次测试中，我尝试了一些我自己的设置，向导仅用几 个小时就找到了最佳设置，为我节省了很多精力。

    applicare.jvmparams.param6= -Xmn256m -Xss128k -XX\:+UseConcMarkSweepGC 
-XX\:+UseParNewGC -XX\:SurvivorRatio\=8 -XX\:TargetSurvivorRatio\=90 
-XX\:MaxTenuringThreshold\=3 -Xms512m -Xmx512m -XX:CompileThreshold=8000 
-XX:PermSize=48m  -XX:MaxPermSize=128m  -Xverify:none 
applicare.jvmparams.param5= -Xmn256m -Xss128k -XX\:+UseParallelGC 
-XX\:+UseParallelOldGC -XX\:+UseBiasedLocking -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param4= -Xmn256m -Xss128k 
-XX\:+UseParallelGC -XX\:+UseParallelOldGC -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param3= -XX\:NewRatio\=3 
-XX\:SurvivorRatio\=6 -XX\:+UseConcMarkSweepGC -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param2=-XX\:NewRatio\=3 
-XX\:SurvivorRatio\=6 -XX\:+UseParallelGC -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param1=-XX\:+UseParallelGC 
-XX\:MaxGCPauseMillis\=3 -Xms512m -Xmx512m -XX:CompileThreshold=8000 
-XX:PermSize=48m  -XX:MaxPermSize=128m  -Xverify:none

  

您还可以配置在容量确定优化运行期间要利用的 CPU 数量。通常情况下，多个受管理服务器共处同一环境中，因此您自然希望限制负载状态下每个过程所占用的硬件空间。通过对可接受的队列长度、等待者数量和其他可配置选项进行限制，可以使工具满足您环境的独特优化需求。

结论

优化 WebLogic 的过程保持不变，只是运行负载、分析性能、适当更改和重新启动 WebLogic Server 这些繁琐的工作全部无缝地自动完成。优化向导是一个自动执行负载生成和性能优化的省时工具。

我已经在本文中介绍了 JVM 自动优化功能，但 Applicare 还会自动进行配置分析、问题检测、根本原因检测，并提供一系列旨在提高性能和可用性的其他功能。

参考资料

• BEA 的 JVM 优化指南 — 介绍 JRockit 和 HotSpot 优化注意事项
• EJB 优化 — WebLogic Server EJB 优化指南
• 优化向导 — 有关 Arcturus 优化向导的更多信息
• 请求演示 — 您可以请求 Applicare 演示并试用它

自动执行 Java 性能优化