WebSphere 反向投资者

调节 WebSphere 应用服务器时应适可而止

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: WebSphere 反向投资者

敬请期待该系列的后续内容。

此内容是该系列的一部分:WebSphere 反向投资者

敬请期待该系列的后续内容。

在每篇专栏文章中,“WebSphere® 反向投资者” 将回答问题、提供指导和讨论与 WebSphere 产品相关的基础主题,经常会给出与流行的看法相悖的经过实践验证的建议。

为什么一些以前的技巧无法用于新版本

在多个 IBM® WebSphere Application Server V7 研讨会上,我在过去几个月一直在为客户做演讲,性能总是一个流行的话题;具体来说,很多人都想知道如何调试获得最优性能。鉴于在这些研讨会中该话题的很热门以及对如何调试和调试什么大家普遍存在一定误解,我认为有必要简单介绍一下应用服务器调试中有哪些准则

别调台!

即使您没用过这个短语,也一定听说过它。几年前,电视和广播上广告开始时经常出现这个短语。有了数码接收器之后,我们就不再使用调节旋钮来调电视或广播了(除非您的电视或收音机很老),但是在调试 WebSphere 应用服务器时这个短语却是个很好的指导。原因是经过一段时间,随着 WebSphere 应用服务器运行时不断改进,各种线程和连接池的默认大小变小了,因为与之前的运行时实现相比,执行相同(或更多)工作量需要的这些共享资源变少了。

WebSphere 应用服务器运行时中这种改进的一个例子就是 Web 容器线程池。在 WebSphere Application Server V6.x 之前,在并发客户端连接数和 Web 容器线程池中的线程数之间存在一对一的映射。换句话说,如果 50 个客户端在访问一个应用程序,那么需要 50 个线程来服务这些请求。在 WebSphere Application Server V6.0 中由于引入了 NIO(本机 IO)和 AIO(异步 IO),这种情况有了变化,它使连接管理能够由少数线程来处理而实际工作也能够由较少的线程来处理。

在最近的一个客户互动中,我发现公司误认为 “池大小越大,性能就越好” 并将池的大小改得比默认值大。在测试运行中,通过 IBM Tivoli® Performance Viewer 观察了实际线程使用和连接池使用情况之后,我能够通过实际降低 Web 容器线程池和 JDBC 连接池的大小将性能提高了 30%。降低池大小意味着 WebSphere Application Server 在管理运行时资源方面的开销也会减少;在这种情况下,不需要线程和连接对象,因此可以释放 CPU 和内存用于处理应用程序请求。

一定要调试 JVM!

这不是电视和广播中的常用语,但是这可能是您通过 WebSphere 应用服务器可以进行的最重要的调节了。正确调节 JVM(最常见的只是根据工作负载正确调整 JVM 大小)通常会在 WebSphere 应用服务器中带来单一调试所能获得的最大性能改进。

WebSphere 应用服务器中的默认堆大小是初始堆大小 50 MB,最大堆大小 256 MB。这些值对于您的环境而言可能不是最佳的,但是它们是保守值,选择它们可以避免 过度使用内存 的问题。结果是您很可能会增加 JVM 大小(假设您有足够的物理内存用于 JVM)。

正确调整对大小需要启用 verbosegc(verbose garbage collection statistics,详细垃圾回收数据统计),运行测试,然后分析 verbosegc 输出结果来确定如何调整堆大小。您可以使用 IBM Pattern Modeling and Analysis Tool for Java™ Garbage Collector (PMAT) 来分析 verbosegc 输出结果或使用 IBM Support Assistant 附带的 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer 来分析。

就堆大小而言:

  • Java 堆大小应该调整为平均内存使用的 40-70%。
  • 垃圾回收应该间隔超过 10 秒。如果垃圾回收每 10 秒发生超过一次,或者堆利用率超过堆的 70%,那么可以考虑增加堆大小。
  • 垃圾回收持续时间应不超过 1-2 秒。如果发现垃圾回收持续时间超过了 1-2 秒,那么这是堆过大的信号,或者说明 “nursery” 太大了(如果在使用分代式垃圾回收)。同样,内存使用少于 40% 则说明堆太大了。
  • 垃圾回收占用的总时间应该不超过测试持续时间的 15%。在测试中花费超过 15% 的时间进行垃圾回收通常是各种因素造成的。

说到测试,您的测试长度应该最少为 10-15 分钟以便 JVM 能够优化字节码和运行时达到稳定状态。测试时间短于此,结果的准确性可能会受到容器启动和线程优化的影响。

关于 JVM 调节的最后一点建议是不要忘记调节节点代理和部署管理器的 JVM。因为这两个 WebSphere 应用服务器网络部署组件都是 JVM,上述针对应用服务器根据工作负载和垃圾回收调整堆大小的建议也适用于这里。能够影响这些 JVM 工作负载的因素包括应用服务器的数量、单元的大小、配置变更的频率以及这些配置变更的大小(特别是应用程序部署)。

底线:要评估节点代理(或部署管理器)所需的内存,需要分析堆使用情况和代表时间段内的垃圾回收周期,对于这两个组件来说,这还应该包括至少一个应用程序部署。应用程序部署,尤其是大的 EAR 文件,可能导致 在部署管理器和节点代理 JVM 中创建大量对象,这也提供了一些方法来减少对象创建,从而加速应用程序部署。

未经测试不要放松 WebSphere 队列

WebSphere 应用服务器部署是 一系列队列,最好只允许能力范围内的工作量进入队列。这会避免任何组件的超载导致性能下降,我上面介绍的将 Web 容器线程池和连接池大小提高到超过 WebSphere 应用服务器处理请求所需值的客户就存在这种情况。

另外要遵守以下原则:运行测试来确定吞度量曲线并仔细监控所有组件的资源使用情况:网络、所有服务器上的 CPU、磁盘等等,以便确定瓶颈在哪里。

改进各种组件的 WebSphere 应用服务器运行时实现的一个负面作用就是过去 WebSphere 应用服务器可能在队列网络中出现瓶颈,更多新的运行时改进可能导致其他资源受限;例如,数据库服务器中的 CPU,因为现在 WebSphere 应用服务器可以更快速地向数据库服务器提供请求。

这里最重要的信息是如果调整了以前版本的 WebSphere 应用服务器,改变了默认池大小,您可能要重新查看这些变更并确保以前有助于性能提升的变更在新版本的 WebSphere 应用服务器中不要降低性能。

结束语

WebSphere 应用服务器信息中心会不断向您提供关于调节 WebSphere 应用服务器各个方面(JVM、线程、连接池和缓存等)以及操作系统的最新信息。可以花些时间研究信息中心中关于您所使用的 WebSphere 应用服务器版本的建议。也可以用一点时间温习一下性能调优方法,这不仅在信息中心中提供介绍,在 Java 网站的性能分析 中也提供详细介绍,这是我所知道的关于调优方法的最为全面的参考资料。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=449598
ArticleTitle=WebSphere 反向投资者: 调节 WebSphere 应用服务器时应适可而止
publish-date=11252009