WAS监控调优思路及工具汇总

1、WAS整理侯泰浩一、 WAS是什么IBM WAS的全称是IBM WebSphere Application Server，和Weblogic一样，是当前主流的 App Server （应用服务器）之一1.1 术语WAS: IBM Websphere Aplication Server, 中间件应用服务程序;IHS: IBM HTTP SERVERDM: Deployment Manager, WAS中的集群管理节点;ND: NodeAgent, WAS中的节点监听程序;JVM: Java Virtual Machine, Java虚拟机;GC: Gabage Collection, 自动垃圾回

2、收1.2 WAS ND集群基本概念及体系结构WAS集群由一组应用服务器组成，每个服务器上部署了同样的应用程序。通过集群可以实现可扩展性（服务更多客户，提高吞吐量），负载均衡（平衡负载资源，使资源得以有效利用），高可用性（提供故障恢复和补偿机制，在关键性业务中提供容错功能）。下图是ND分布式环境的体系结构，包括单元、节点、服务器等基本概念。WAS群集是为了实现集中管理和负载均衡同时可以实现故障转移，一个2节点的群集拓扑如下：其中，DeploymentManager通过每个节点上的NodeAgent完成对AppServer的配置修改、应用发布以及启动和停止，实现集中管理。如果安装多个IHS，并实现

3、负载均衡和分发，可以使用防火墙的负载分发功能。每个节点上的AppServer可以是多个的。二、 WAS基本参数配置描述参数缺省值设置原则JVM堆栈服务器>应用程序服务器> server1 >Java虚拟机无最小值为总内存1/8,最大值为总内存1/2至3/4，建议256M-1500M连接池资源> JDBC提供程序> (JDBC提供程序名) >数据源> (数据源名) >连接池属性最小连接数：10最大连接数：50通过TPV监控连接池的大小变化曲线设置语句高速缓存资源> JDBC提供程序> (JDBC提供程序名) >数据源> (数

4、据源名) >WebSphereApplicationServer数据源属性>语句高速缓存大小10比如实际情况下CPU利用率很高，并且表明有瓶颈，performance advisors报警提示prepare statement缓存丢弃率较高，这说明默认的值(10)太小，需要增加该值大小以提高吞吐量。JMS池资源JMS提供程序缺省消息传递JMS激活规范激活规范名最大批次大小：无最大并发端点数：无根据实际情况分析Web容器线程池服务器>应用程序服务器> (服务器名) >线程池> WebContainer最小大小：10最大大小：50通过TPV监控Web容器线程池最

5、大值（在可接受的相应时间范围内），根据此值进行设置。EJB缓存服务器>应用程序服务器> (服务器名) > EJB告诉缓存设置> EJB缓存设置>高速缓存大小高速缓存大小：2053清除时间间隔：3000比如通过TPV监控发现ejbStore()有很高的调用率并且CPU利用率很低，可以基于期望的最大的活动的EJB实例设置该值servlet高速缓存服务器->server1->web容器设置->web容器->启用servlet高速缓存 关闭建议启用servlet高速缓存三、 WAS的调优思路1233.1 基本思路部署在WAS上的应用程序，其性能是由

6、多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的 J2EE应用，一个请求到来时，往往需要经过多次转发：网络 > Web服务器Web容器 > EJB容器 > 数据库。而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。 如果我们把每一次转发的待处理资源都看成一个队列，如下图：待处理资源队列对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。在实践中我们发现，为了达到这个目的，最有效的配置方式 就是使得队列成为一个“漏斗”。也就是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于

7、或等于前面的队列。3.2 WAS主要的调优参数3.2.1 WAS服务器参数Web Server的最大并发用户：这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。 Web Container的最大、最小并发用户：在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer，根据观察的性能情况和应用情况输入合适的最小、最大进程数。对象请求代理（ORB）的线程池大小：在管理控制台中点击应用程序服务器 > server

8、1 > ORB 服务 > 线程池，根据观察的性能情况和应用情况输入合适的最小、最大进程数。设置数据库的连接池属性：JDBC 提供者 >数据库JDBC驱动名称 > 数据源 > 数据源名称> 连接池 ，根据观察的性能情况和应用情况输入合适的最小、最大连接数。JVM堆参数设置的性能调优：应用程序服务器 > server1 > 进程定义 > Java 虚拟机，根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。ORB参数调用方式的性能调优：应用程序服务器 > server1 > ORB 服务>选中按引用传递。关闭动态加载开

9、关：企业应用程序 > 应用名称 > 关闭启动类重新装入开关。关闭会话序列化，应用程序服务器 > server1 > 会话管理 > 分布式环境设置 > 分布式会话选择无即可。3.2.2 JVM的参数WAS 在HP和 Solaris 上使用的是 Sun提供的JVM,在其他平台使用的是IBM自己的JVM，建议使用WAS自带的JVM，因为在产品支持等方面会获得更多地优势Heapsize（-Xms 和-Xmx）：heapsize的大小依赖于系统平台和具体的应用等多种因素。最大 heapsize需要小于机器的物理内存，一般来说，设置最大 heapsize 为 512m

10、是一个常见的起点。同时，在生产环境中，最好将 Xms 设置为小于 Xmx的值。GC（Garbage Collection，自动垃圾回收）：一般来说，良好的 GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少 5-6倍。GC的调优是通过在模拟压力的情况下不断调整最大最小 heapsize 来实现的。Heap Fragmentation (heap碎片)：heap 碎片的问题在 JVM 中存在大对象的情况下尤为突出。减少碎片的方法包括调整 pCluster（-Xp）和 kCluster（-Xk）参数。3.2.3 Web Container （Web容器）对 Web Co

11、ntainer 的调优是通过对 Web Container 传输链中各个通道（TCP、HTTP、WebContainer）的参数调整进行的。这些参数包括诸如 ThreadPool 的最大最小值，buffer大小， timeout 时间的大小， keep-alive 的值等等。Web容器线程池要点就是：“通常，对于每个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量”（现在的一个cpu可以用核来代替）。比如你的Pc Server有2块CPU，每块CPU都是4核，那么你一个Application Server可以设置的最小值和最大值可以分别为40、80。但是一般考虑到能充分利用CPU和Mem

12、ory，或者为不同的应用启用不同的 application server，一台Pc Server上并不仅有这么一个appserver，而且还有别的进程在占用着CPU，所以默认的10到50（Linux 系统上 25 个）是一个比较合适的值，当然更准确的值需要通过性能测试来确定。在 进行性能测试的时候，如果吞吐率不是很满意，或者在TPV中看到线程池占用一直是最大值，不要立刻就调大线程池的设置往往吞吐率会更一步下降。这时候 要注意CPU占用率的情况、vmstat的r列值，特别是System状态占用率的情况，如果接近10%，甚至超过10%，那么可以肯定系统在进程切换上 面消耗的资源太多了。下调线程池的

13、大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。3.2.4 Data Source对 Data Source的优化包括两个方面。一是 JDBC Driver 的选取，尽可能应使用 Type 4 的JDBC driver，这种 driver 是纯 java 的，适用于 client/server 模式，并提供比 type2 和legacy/CLI 的 driver 更好的性能。另一方面是 Database 连接池的参数设置，主要包括最大和最小连接以及 timeout的设置。具体的设置于应用程序的特性和并发用户量相关，一般来说，可设置最小连接为 1 且最大连接为 30，作为一个继

14、续调优的起点。Application Server 将在使用该数据源的每个应用程序服务器中创建连接池的单独实例。例如：如果运行包含三个服务器的集群，这三个服务器都使用 myDataSource，并且 myDataSource的“最大连接数”设置为 10，那么可生成多达 30 个连接（3 个服务器乘以 10 个连接）。3.2.5 其他 除了 JVM，Web Container 和 Data Source之外，WAS 的性能调优还包括很多其他方面的内容，如 JMS、EJB、Session、Dynamic Cache等等。四、 监控工具4.1 WAS自带的TPVWAS中免费提供的

15、 Tivoli® Performance Viewer（TPV）允许客户对关键资源（如 JVM、Web 容器和 EJB 容器以及远程连接池）进行监视。显示从本地或远程应用服务器收集的PMI (Performance Monitoring Infrastructure )数据 摘要报告:表格方式查看性能模块:图形方式查看性能模块:但是TPV有一些明显缺点：4.2 Java性能监测工具Jprofiler/Jprobe:JProfiler是一个全功能的Java剖析工具（profiler），专用于分析J2SE和J2EE应用程序。JProfiler直觉式的GUI让你可以找到效能瓶颈、抓出内存漏

16、失(memory leaks)、并解决执行绪的问题。它让你得以对heap walker作资源回收器的root analysis，可以轻易找出内存漏失；heap快照（snapshot）模式让未被参照（reference）的对象、稍微被参照的对象、或在终结（finalization）队列的对象都会被移除；整合精灵以便剖析浏览器的Java外挂功能。JProbe是一个完全为Java设计的解析器，为servlet、JSP和EJB应用代码提供了强大的Java性能分析、内存纠错、代码覆盖及线程分析功能。主要用于识别内存泄漏、智能化内存分析、垃圾回收分析等用于JVM 生成的信息的工具还包括有:用于 Verbo

17、seGC 分析： IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (GCMV) :一个详细的 GC 数据可视化器，用于分析并绘制所有 IBM 详细 GC 日志Xtgc 输出（并且可扩展到分析和绘制其他形式的输入）。它提供了广泛的详细 GC 数据值的图形显示，并处理 optthruput、optavgpause 和 gencon GC 模式。它具有原始日志、表格式数据和图表视图，并且可以将数据保存到 jpeg 或 .csv 文件（用于导出到电子表格）。请参阅 IBM S

18、upport Assistant 中的完整描述。 输入：verbosegc 日志 输出：图形表示形式、html、jpeg 或 csv 文件 支持：此工具由 IBM 提供支持，目前是用于其所在领域的主要工具。IBM Pattern Modeling and Analysis Tool (PMAT) for Java Garbage Collector :分析 IBM 详细 GC 跟踪，分析 Java 堆使用情况，并基于 Java 堆使用情况的模式建模提供重要配置建议。此工具先于上面的 IBM Monitoring and Diagnostic Tools for Java - Garbage C

19、ollection and Memory Visualizer (1)，并提供了一个可能相当有用的不同透视图。请参阅 IBM Support Assistant 或 alphaWorks 中的完整描述。 输入：verbosegc 日志 输出：verbosegc 日志的图形或表格表示形式 其他功能：关于 JVM 参数的一般建议 支持：技术预览版，按原样提供。Diagnostic Tool for Java Garbage Collector 通过读取详细垃圾回收的输出，并产生文本和图形可视化表示形式及相关统计信息，从而帮助检查运行在 JVM 下的应用程序的垃圾回收特征。 请参阅 alphaWor

20、ks 中的完整描述。 输入：verbosegc 输出：文本和图形可视化表示形式 支持：按原样提供的工具。用于 Java 转储/javacore： IBM Thread and Monitor Dump Analyzer (TMDA) 分析一个或多个 Java 线程转储或 javacore，并诊断监视器锁和线程活动，以便确定挂起、死锁和资源争用或监视器瓶颈的根源。请参阅 IBM Support Assistant 或 alphaWorks 中的完整描述。 输入：用于显示相关线程历史记录的单个或多个 javacore 输出：基于 GUI 的视图 其他信息：关于 Analysis of hangs,

21、 deadlocks, and resource contention or monitor bottlenecks using IBM Thread and Monitor Dump Analyzer for Java Technology 的网络广播 支持：技术预览版，按原样提供，但是是该领域的主要工具。ThreadAnalyzer 提供 Java 线程转储或 javacore 的分析，例如来自 WebSphere Application Server 的转储或 javacore。可以在不同的级别分析线程使用情况，从高级图形视图开始，然后深入到各个线程的详细记录。如果线程转储中存在任何死锁

22、，ThreadAnalyzer 将检测并报告它们。此工具先于上面的 IBM Thread and Monitor Dump Analyzer 工具 (4)，但是其功能已集成到后者之中，后者正在成为该领域的主要工具。 请参阅 IBM Support Assistant 中的完整描述。 输入：Java 线程转储/javacore 输出：线程的图形视图、加载多个线程转储以显示线程历史记录的能力 支持：技术预览版，按原样提供，但是是该领域的主要工具。此工具可能会逐步淘汰；请尽可能使用 IBM Thread and Monitor Dump Analyzer。用于线程：IBM Lock Analyzer

23、 for Java 旨在对动态应用程序执行锁分析，以便突出具有可能影响性能的锁争用的线程。此工具由两个包组成： 1. 第一个包与平台相关，并提供到 JVM 的连接，以便收集有关正在运行的应用程序的锁统计信息。这个包在运行时随同要监视的应用程序一起进行加载。 2. 第二个包与平台无关，并提供了图形用户界面。该图形用户界面连接到平台包，并提供所需的控制和分析以确定性能糟糕的锁。 请参阅 alphaWorks 中的完整描述。 输入：从 JVM 收集的统计信息 输出：锁的图形视图 支持：按原样提供的工具。用于堆转储： Memory Dump Diagnostic for Java (MDD4J) 分析

24、正在运行 WebSphere Application Server 或任何其他独立 Java 应用程序的 JVM 中常见格式的内存转储（堆转储）。内存转储分析旨在确定 Java 堆中可能是内存泄露根源的数据结构。该分析还确定应用程序的 Java 堆占用空间的主要肇事者和它们的所属关系。此工具能够分析从遇到 OutOfMemoryError 问题的生产环境应用程序服务器中获得的非常大的内存转储（将需要 2 GB 或更多的 RAM）。MDD4J 扩展了下面较旧的 IBM HeapAnalyzer (8) 的功能，尽管两个工具的用户界面完全不同。请参阅 IBM Support Assistant 中

25、的完整描述。 输入：来自虚拟机 (JVM) 的内存转储（堆转储） 输出：交互式报告，其中显示主要的内存泄露可疑之处，以及有关这些泄露的详细信息。 其他功能：操作单个转储。有些版本提供了多个转储的比较分析。 支持：此工具由 IBM 提供支持，目前是用于其所在领域的主要工具。在本文编写之际，IBM Support Assistant 中的最新版本为 Beta 版。HeapAnalyzer HeapAnalyzer 读取单个 Java 内存转储（堆转储），并使您能够浏览转储以查看其内容。此工具是上面的 Memory Dump Diagnostic for Java (MDD4J) 工具(7) 的前身

26、，后者现在包含前者的大多数功能。当时，HeapAnalyzer 中的原始树浏览功能比在 MDD4J 中更加灵活。另一方面，HeapAnalyzer 缺乏 MDD4J 中的某些更完善的泄露嫌疑检测算法，并且不支持多个转储的比较分析。请参阅 alphaWorks 中的完整描述。 输入：单个 java 堆转储 输出：可疑对象的图形视图和堆浏览器 支持：按原样提供的工具。HeapRoots HeapRoots 读取 Java 堆转储文件并提供用于分析数据的命令。这些命令对数据运行算法，或查询有关该数据的信息。HeapRoots 提供了命令行交互式界面，您可以在其中输入命令并获取结果。 请参阅 alphaWorks 中的完整描述。 输入：堆转储文件 输出：可疑对象的图形视图和堆浏览器 支持：按原样提供的工具。用于系统/核心转储： IBM Monitoring and Diagnostic Tools for Jav