websphere
–参考websphere性能学习笔记
1.WAS日志
WebSphere的日志信息：
…/profiles/APPsrv01/logs/server下主要日志：
SystemErr.log : 系统出错日志
SystemOut.log : 系统中所有活动的日志
trace.log : 系统中所有跟踪的事件的日志
startServer.log : 启动服务器事件的日志
stopServer.log : 停止服务器事件的日志
native_stderr.log : GC垃圾收集日志,这表明了内存管理是否正常。通过一些工具，比如：ISA里的 PMAT (IBM Pattern Modeling and Analysis Tool for java Garbage Collector)可以查看GC历史趋势，看有没有内存泄漏的问题。
IBM Http Server(IHS)与Plugin日志信息 ： httpserver/../logs下相关日志如果有相关was抛错等首先查看以上日志文件。
WebSphere的日志对问题定位非常关键，如果用户安装部署、配置资源或者运行应用程序出了问题，都需要看日志才能明白到底是哪里，哪个环节出了问题，才能进一步解决问题。
比如：WAS安装失败，需要看/logs/install/log.txt，甚至如果失败发生在该文件创建之前，需要去 看/waslogs/下的临时日志；server启动不起来，需要看SystemOut.log; 连接数据源失败也需要看SystemOut.log；JNDI name找不到，需要察看SystemOut.log里，它是在哪里找的？为什么找不到？；有时候根据需要，还要看ffdc目录下得log, SystemOut.log里会打印在某个时间点生成了一个ffdc log，文件文是什么。
FFDC log即First Failure Data Capture，即抓一些错误发生第一时间的log。
WebSphere Application Server 日志记录基础结构是基于标准 Java 的日志记录基础结构（即java.util.logging）建立的。在一个典型的 WebSphere Application Server 配置中，日志记录被设置为将普通和严重的日志消息分别写入两个文件，即SystemOut.log 和 SystemErr.log。
System.out 日志用于监视正在运行的应用程序服务器的运行状况。
System.err 日志包含用于执行问题分析的异常堆栈跟踪信息。
WebSphere Application Server 中还有其他两个日志文件：JVM native_stdout 和 native_stderr 文件。与 SystemOut.log 和 SystemErr.log 不同，这两个文件实际上是由 JVM 本身处理的，只包含与该 JVM 的操作有关的消息，而不包含来自 WebSphere Application Server 运行时的消息。
假设在native_stderr.log里有这么一段日志：
<AF[3160]: Allocation Failure. need 2621456 bytes, 195 ms since last AF>
<AF[3160]: managing allocation failure, action=2 (5049520/1073740288)>
<GC(3538): GC cycle started Wed Jul 30 17:41:02 2008
<GC(3538): freed 4619080 bytes, 0% free (9668600/1073740288), in 6135 ms>
<GC(3538): mark: 992 ms, sweep: 28 ms, compact: 5115 ms>
<GC(3538): refs: soft 0 (age >= 32), weak 0, final 7, phantom 3>
<GC(3538): moved 6184798 objects, 298397088 bytes, reason=1, used 101520 more bytes>
<AF[3160]: managing allocation failure, action=3 (9668600/1073740288)>
<AF[3160]: managing allocation failure, action=4 (9668600/1073740288)>
<AF[3160]: managing allocation failure, action=6 (9668600/1073740288)>
JVMDG217: Dump handler is Processing outofmemory - Please Wait.
JVMDG315: JVM requesting Heap dump file
JVMDG318: Heap dump file written to C:\Program Files\IBM\WebSphere\AppServer\profiles\default\heapdump.20080730.174102.3784.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to C:\Program Files\IBM\WebSphere\AppServer\profiles\default\javacore.20080730.174149.3784.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[3160]: Insufficient space in Javaheap to satisfy allocation request>
<AF[3160]: completed in 92673 ms>第一行是说需要2621456 bytes内存，分配失败；
然后第二行告知可用内存只有5049520 bytes；
第三行GC开始回收内存；
第四行回收了4619080 bytes，总的可用内存变为9668600bytes。0% free是指当前可用/总内存大小，9668600/1073740288=0.0090，被约等于0了。
第五行开始不知道在干什么，猜测是移动数据以获取连续空间？
第十一行终于报内存不足了，然后会记录两个日志文件，heapdump、javacore.log。
根据这两个日志的时间，可以到sysetemOut.log中查看当时在做什么操作。
再看一段：
<AF[2]: Allocation Failure. need 524 bytes, 383 ms since last AF>
<AF[2]: managing allocation failure, action=0 (528723272/536869376)>
<GC(2): GC cycle started Sat Apr 05 21:40:31 2008
<GC(2): freed 3529224 bytes, 99% free (532252496/536869376), in 10 ms>
<GC(2): mark: 7 ms, sweep: 3 ms, compact: 0 ms>
<GC(2): refs: soft 0 (age >= 32), weak 0, final 7, phantom 0>
<AF[2]: completed in 11 ms>这段应该说明，可用内存很大，但申请连续内存时可能还是不足。这段日志记录的是gc回收后就正好够了，所以没有了上一段日志中的move.
WebSphere监控方法
方案一、通过perfServletApp进行监控
perfServletApp项目是由WebSphere提供的（在安装目录下可以找到PerfServletApp.ear，默认没有部署），用于简单的端对端检索性能数据，IBM 或第三方供应商提供的任何工具都可以处理此性能数据。通过servlet访问，返回xml格式的信息。
方案二、使用JMX接口开发监控程序
通过使用 PerfMBean 或个别MBean，您可使用AdminClient API 获取性能监控基础结构（PMI）数据
查看JMX通过SOAP连接WebSphere的端口：
应用程序服务器 > serverName > 端口 ==> SOAP_CONNECTOR_ADDRESS
参考：
http://yunzhu.iteye.com/blog/971254
http://yunzhu.iteye.com/blog/953387
http://www.ibm.com/developerworks/cn/websphere/downloads/peformtuning.html
2 常用监控指标分析
2.1 JVM
2.1.1 JVM 级的诊断
参考：
http://www.ibm.com/developerworks/cn/websphere/techjournal/0702_supauth/0702_supauth.html
在其核心中，WebSphere Application Server 首先是一个 JVM 进程。因此，为所有的 JVM 进程提供一系列诊断工具的想法是十分自然的。实际上，在 WebSphere Application Server 的用户们遇到的问题中，有一部分是在 JVM 级首先表现出来的，如内存不足、崩溃等。
• verboseGC 日志大概是最常见的JVM 诊断类型。它显示了 JVM 生存期间，各个垃圾回收周期的顺序。它作为确定问题时的一项初始的辅助工具，常常具有不可估量的价值，它被用来检测和诊断 JVM 中所有类型的内存分配异常问题，如内存泄漏、碎片，以及与 GC 有关的性能问题等等。IBM Support Assistant 中提供的 PMAT 工具，目前是帮助分析 verboseGC 日志文件内容的基本工具。
• 线程转储也是一种极为常见的 JVM 诊断类型。线程转储（也是一个 javacore) 可以根据管理员的请求触发，也能在 JVM 中遇到某种特殊情况时自动触发。线程转储是一个文本文件，包含了 JVM 状态的关键方面的一个相对较短的快照。该快照最常用的部分是 JVM 中当前活动线程的列表，线程转储也因此得名。线程转储最常见的用途是诊断 JVM 中出现挂起、崩溃或 cpu 占用率过高的原因。线程转储是相对较短的文本文件，可以用简单的文本编辑器进行检查。不过，若是使用某种特殊的工具，用来解析和组织其中的内容，自动检测并突出关键信息和异常，常常会更有效。现在用于此用途的工具主要有两种：IBM Support Assistant 中提供的ThreadAnalyzer 和AlphaWorks 上提供的 Thread and monitor Dump Analyzer。
• 堆转储是由 JVM 生成的另一种形式的转储，可以按需生成，也可以在满足特殊条件时自动生成。通常，堆转储通常是一个很大的文件，它包含当前 JVM 堆中所有对象的一个列表。它用于在出现内存不足的情况下执行深入分析。例如，分析者可以找出哪些对象在堆中占用了最多的空间，哪些对象正在增殖，等等。由于堆存储是一个很大的文件，手动检查是不切实际的。Memory Dump Diagnostic for Java 工具 (MDD4J) 可以在 IBM Support Assistant 中找到，目前它是执行此类分析的主要工具。
• 第三类 JVM 转储是系统转储，或是简单的核心文件。这是开销最大、但也是最完整的转储方式。它是一个巨大的二进制文件，反映了 JVM 的全部内容：每一个 Java 对象及其字段、每一个线程、每个内存区域，等等。系统转储的最初用途是在其他类型的转储不够用或无法生成时，帮助诊断崩溃、挂起或复杂的内存分配问题。不过，由于系统转储非常完整，它也能用来获取 WebSphere Application Server 运行时当前状态的多方面信息，甚至运行时期间应用程序的执行信息。预计将来系统转储在这方面还会有更多的用途。在IBM 之外可获得的WebSphere Application Server JVM 系统转储内容检查工具相对较少。因此，一般情况下，系统转储应发送给IBM Support 做深入分析。不过 IBM 最近引入了一项被称为 Diagnostic Tooling Framework for Java (DTFJ) 的新技术，将使系统转储检查工具的开发变得容易起来。预计基于 DTFJ 技术的工具在未来将得到广泛使用。
• 最后，JVM 还提供了自己的 JVM 跟踪工具，与 WebSphere 跟踪工具不同，它在单个 Java 方法调用级、以及 JVM 实现操作的内部事件级提供了跟踪工具。这种类型的跟踪最常用于内部 JVM 问题的诊断，偶尔也用来诊断 WebSphere Application Server 级的问题。不过，方法级别的跟踪对于 WebSphere 跟踪而言是很有用的辅助手段。我们计划在不久的将来扩展它的用途并编写相关文档。
Java Diagnostics Guide 是一个主要的信息来源，提供与各种类型的 JVM 级诊断工具和相应的转储生成方法相关的信息。这些工具中的每一个都具有各自格式的文档。
2.1.2 HeapSize
可监控FreeMemory、ProcessCpuUsage、UsedMemory
调整JVM堆大小
JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。
默认设置
VU：100
HeapSize：200
FreeMemory：28~8
TRT：5.8
调整Initial Heap Size和Maximum Heap Size为512M
VU：100
HeapSize：524
FreeMemory：380~179
TRT：8.1
调整Initial Heap Size和Maximum Heap Size为64M
在WebSphere的控制台查看TPV，提示：
错误 500
处理请求时发生一个错误： /ibm/console/secure/layouts/contentLayout.jsp
消息： java.lang.OutOfMemoryERROR
2.1.3 GC日志分析
在WAS中打开详细GC日志输出
方法1、在管理控制台中点击服务器 > 应用服务器 > server1（或者是您自己定义服务器名） > JAVA和进程管理 > 进程定义 > java虚拟机 > 选中详细垃圾回收选项，重启应用服务器，即可生效。打开垃圾回收开关后，关于内存的使用情况的日志会存储到相应的日志目录中的native_stdout.log文件中，并且可以通过分析该文件中的信息快速的找到产生问题的根源。
方法2、在通用JVM参数输入框中添加：-Xverbosegclog:gc.log
用PMAT（IBM Pattern Modeling and Analysis Tool for Java Garbage Collector）分析GC日志：
java -Xmx512m -jar ga414.jar
在负载测试过程中收集垃圾回收统计数据是很有帮助的，但大大小小的每次回收都会被记录下来，所以请记住在运行最终的基准之前要禁用详细垃圾回收。
2.1.4 策略
参考：
http://www.webspherechina.net/home/space.php?uid=275&do=blog&id=52178
https://blog.csdn.net/suifeng3051/article/details/48292193
https://blog.csdn.net/antony9118/article/details/51375662
https://blog.csdn.net/shen_guo/article/details/50343135
在IBM SDK 5.0提供了四种不同的GC策略优化配置(IBM 在WebSphere 6.1版本开始，IBM JDK 升级到IBM SDK5.0，也就是常说的JDK1.5)，详细如下：
| 序号 | 策略 | 选项 | 描述 | 备注 |
|---|---|---|---|---|
| 1 | 针对吞吐量进行优化 | -Xgcpolicy:optthruput | WAS默认策略。对于吞吐量比短暂的 GC 停顿更重要的应用程序，通常使用这种策略。每当进行垃圾收集时，应用程序都会停顿。 | |
| 1 | 针对停顿时间进行优化 | -Xgcpolicy:optavgpause | 通过并发地执行一部分垃圾收集，在高吞吐量和短 GC 停顿之间进行折中。应用程序停顿的时间更短。 | |
| 1 | 分代并发 | -Xgcpolicy:gencon | 以不同方式处理短期存活的对象和长期存活的对象。采用这种策略时，具有许多短期存活对象的应用程序会表现出更短的停顿时间，同时仍然产生很好的吞吐量。 | 推荐 |
| 1 | 子池 | -Xgcpolicy:subpool | 采用与默认策略相似的算法，但是采用一种比较适合多处理器计算机的分配策略。建议对于有 16 个或更多处理器的 SMP 计算机使用这种策略。这种策略只能在 IBM pSeries® 和 zSeries® 平台上使用。需要扩展到大型计算机上的应用程序可以从这种策略中受益。 |
在Sun Jvm也有自己特色的GC策略，如：
可参考: java垃圾回收精粹
http://www.importnew.com/8335.html
| 序号 | 策略 | 选项 | 描述 | 备注 |
|---|---|---|---|---|
| 1 | 并发收集器(并发标记清理收集器,CMS) | -XX:+UseConcMarkSweepGC | 并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时），一般都不得不停止其他操作，以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。 | |
| 2 | 并行收集器 | -XX:+UseparallelGC | 并行收集器使用某种传统的算法，并使用多线程并行地执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序区性的可扩展性。 | |
| 3 | 串行收集器 | -XX:+UseSerialGC | 用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高,对于单处理器系统真是绝佳上选.但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。 |
并行GC
-XX:+UseParallelGC
-XX:ParallelGCThreads= either equal to number of cpu or on multi core systems set it to somewhere between .5-1xNumber of cores.
配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。
2.1.5 HeapDump
参考：
http://www.webspherechina.net/?viewnews-6051.html
http://guotufu.iteye.com/blog/1123890
2.2 线程
http://www.oschina.net/question/129540_21818
Web 容器线程池
一般来说，每个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量。另外我们也可以利用 WAS 自带的 TPV 来帮助我们设置 Web 容器线程池。对系统做一个压力测试，保持一定的负载，观测 TPV 中的 PercentMaxed 和 ActiveCount的值，PercentMaxed 表示所有线程被使用的平均百分比，如果该值较大，那么就应该增大线程池的值；ActiveCount 表示被激活的线程个数，如果该值远小于当前线程池的大小，那么可以考虑减小线程池的值。可以 使用 WAS 管理控制台进行 Web 容器线程池的配置，位于 Application servers > AppServer name > Thread pools > Webcontainer
http://space.itpub.net/11605445/viewspace-600491
Web容器线程池
要点就是：“通常，对于每个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量”（现在的一个cpu可以用核来代替）。比如你的Pc Server有2块CPU，每块CPU都是4核，那么你一个Application Server可以设置的最小值和最大值可以分别为40、80。但是一般考虑到能充分利用CPU和Memory，或者为不同的应用启用不同的application server，一台Pc Server上并不仅有这么一个appserver，而且还有别的进程在占用着CPU，所以默认的10到50（linux 系统上 25 个）是一个比较合适的值，当然更准确的值需要通过性能测试来确定。
在进行性能测试的时候，如果吞吐率不是很满意，或者在TPV中看到线程池占用一直是最大值，不要立刻就调大线程池的设置——往往吞吐率会更一步下降。这时候要注意CPU占用率的情况、vmstat的r列值，特别是System状态占用率的情况，如果接近10%，甚至超过10%，那么可以肯定系统在进程切换上面消耗的资源太多了。下调线程池的大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。
这篇文章也许会使你对线程池大小对性能的影响有个感性的认识：
http://www.ibm.com/developerworks/cn/java/l-threadPool/
调整线程池:
服务器 > 应用程序服务器 > server_name > 线程池 > WebContainer
默认线程池设置：
50
50
60000
VU:10
TRT:0.401
TP:4473169
监控到PoolSize：8
VU：30
TRT：0.911
TP：5392938
监控到PoolSize：12
VU：50
TRT：1.492
TP：4916714
监控到PoolSize：12
VU:100
TRT:3.203
TP:4178110
监控到PoolSize：4
修改线程池设置：
5
5
60000
VU：50
TRT：1.525
TP：4820978
监控到
ActiveCount：2
PoolSize：3
PercentMaxed：0
VU：100
TRT：2.458
TP：5390173
监控到
ActiveCount：2
PoolSize：3
PercentMaxed：0
修改线程池设置：
2
2
60000
VU：100
TRT：3.092
TP：4265748
监控到
ActiveCount：1
PoolSize：2
PercentMaxed：0
修改线程池设置：
1
1
60000
启动不了控制台！只能找到server.xml文件修改回去！
2.3 Web应用程序
重点关注servlet、jsp的请求数、服务时间：
2.4 session
主要关注ActiveCount、LiveCount
Session timeout:
The default value of Session Timeout is 30 minutes. Reducing this value to a lower number can help reduce memory consumption requirements, allowing a higher user load to be sustained for longer periods of time. Reducing the value too low can interfere with the user experience.
How To Set:
In the WebSphere AdMinistrative Console: Servers > Application Servers > WebSphere Portal > Container settings: Web Container Settings > Session Management > Session Timeout -> Set Timeout
内存中最大会话量：100
Timeout：2分钟
VU：100
提示错误：
Action.c(31): Error -26612: HTTP Status-Code=500 (Internal Server Error) for “http://192.168.1.101:9080/PlantsByWebSphere/servlet/AccountServlet?action=login&updating=false”
内存中最大会话量：1000、允许溢出
Timeout：2分钟
VU：100
不提示错误
内存使用：518M
TRT：7.9
内存中最大会话量：1000、允许溢出
Timeout：30分钟
VU：100
内存使用：497M->513M（LiveCount和ActiveCount持续增加）
TRT：8.5
2.5 JDBC
主要关注：
WaitingThreadCount
FaultCount
PercentUsed
FreePoolSize
应用程序读取数据库有2种方式，一种是直接连接数据库，一种是调用连接池。
1) 直连是程序直接创建物理连接，调用数据库进行数据读取。直连的创建会带来很大的系统开销，若程序中多处频繁使用直连，会造成应用服务器资源消耗过多，影响程序的性能。
2) 连接池是创建和管理一个物理连接的缓冲池，其中会保留一定数量创建的物理连接不关闭，当有客户端请求时，调用连接池，可以有效减少物理连接的创建次数，降低直连所带来的系统开销，缓解应用服务器压力，提高程序性能。
调整设置连接池属性：
资源 > JDBC > 数据源> 连接池属性 > 常规属性
包括：
-连接超时时间
-最大连接数
-最小连接数
-收集时间
-未使用的超时时间
-时效超时
-清除策略（一般选择整个池）
连接超时值确保小于事务超时
连接超时
概述：
连接超时是指，当对指定连接池进行请求时，池中没有可用连接（连接全部被使用，或者数据库请求超时），当请求时间到达指定之间时未响应，那麽这个时候就会产生超时异常，通过日志可以发现。
意义：
连接超时的设置，是对我们应用响应速度的一种把关，客户往往要求我们的产品在多长时间必须有响应，所以连接超时的设置，可以让我们发现哪些程序点有响应速度问题，可能是数据库查询语句问题，也有可能是程序逻辑死循环，再有可能就是数据库表结构需要优化，还有可能是最大连接数到达最大值。
最大连接数
概述：
最大连接数是指当前连接池中允许创建的最大物理连接数，当到达指定值后，将不允许创建物理连接。和连接超时相对应，当达到最大值后，连接请求将等待，直到池中有空闲连接为止，否则报连接超时错误。当使用集群机制时，会同时存在多个相同连接池，这个时候需要考虑最大数量的设置。
意义：
最大连接数可以有效控制创建物理连接的数量，连接池的大小影响着服务器资源的占用情况，若连接池过大，则会长期占用服务器可利用资源，若连接池过小，无法满足现场环境应用高负载使用压力。最大连接数的设置应根据TPV观测数据进行合理配置。
最小连接数
概述：
最小连接数是指当前连接池要保留的最小物理连接，其决定未使用超时维护机制的下限，连接池的创建不是根据最小连接数而特意创建，而是根据用户请求而创建，系统会一直维护最小的连接数目。
意义：
最小连接数使应用服务器保持一定数量的物理连接，利用应用服务器维护机制，合理分配服务器资源。当应用程序访问频繁，但访问人数少的情况下，最小连接数的合理配置，可以将有效的资源进行充分利用，满足特定应用需求。
收集时间
概述：
收集时间是连接池维护机制的核心，是指每次维护连接池的时间间隔。其有两个维护指标，分别为未使用超时和时效超时，其值应该小于两个指标中的任何一个。每一次维护周期中，连接池都会将连接池中超时的物理连接关闭，以减少系统占用资源。
意义：
合理的收集时间设置，是帮助我们关闭不必要的连接，节省系统资源占用的有效途径。收集时间设置不易过大，因为时间间隔过长，会使很多未被使用的物理连接持续占用资源。若收集时间过小，则频繁的维护会带来很多系统开销，连接池的主要精力都放到了维护上。
未使用的超时
概述：
未使用的超时指池中的物理连接空闲未使用的时间间隔，每隔指定时间，系统会为连接标记，帮助收集时间在维护过程中进行关闭。未使用的超时应该小于实效超时时间，并且其以最小连接数为标准，当连接数超过最小连接数时，其才起作用。
意义：
未使用超时的设置，帮助我们关闭不必要的空闲连接，释放系统资源，并且减少数据库开销。根据现场环境使用情况，我们可以根据系统访问频繁程序，来定制合理的未使用超时，如果过小，当访问频繁程度大时，总需要重新创建，如果过大，当访问频繁程度不大时，连接池又空闲占用过多。
时效超时
概述：
实效超时指关闭物理连接的时间间隔，这个值是指到达指定的时间后，关闭满足时间条件的物理连接，若这个物理连接未使用，则直接关闭，若这个连接正在使用，则当前事务结束后，关闭此连接。这个值不受最小连接数的影响，若没有新创建的连接，此机制会关闭连接直到为0。
意义：
时效超时的设置，是为了方式应用程序或者数据库造成的数据库连接持续占用，可能导致的原因包括程序逻辑错误，数据库宕机导致的错误等。还有一种情况为人为导致，就是若某个用户持续占用一个资源不放，会导致其他用户无法访问。所以时效超时的设置，是对不合理使用应用，或者链接错误等进行强行关闭，保证程序的稳定性和持久性。
3 性能监控工具
3.1 IBM Support Assistant (ISA) Workbench
下载：
http://www-01.ibm.com/software/support/isa/
IBM Monitoring and Diagnostic Tools for Java - Health Center
简介：
http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/
The IBM Monitoring and Diagnostic Tools for Java - Health Center (Health Center) enables you to assess the current status of a running Java application. Health Center continuous monitoring provides information to identify and help resolve problems with your application:
• Identify if native or heap memory is leaking
• Discover which methods are taking most time to run
• Pin down I/O bottlenecks
• Visualize and tune garbage collection
• View any lock contentions
• Analyse unusual WebSphere® Real Time events
• Monitor your applications Thread activity
Use Health Center to help you:
• Optimize application performance
• Improve application stability and uptime
• Reduce system resource usage
• Reduce the time to resolve problems
• Drive down development and maintenance costs
• Trigger System dumps for analysis in IBM Monitoring and Diagnostics Tools for Java Memory Analyser
• Turn on verbosegc collection for analysis in IBM Monitoring and Diagnostics Tools for Java Garbage Collection and Memory Visualizer
安装使用：
http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/getting_started.html
1、下载安装IBM Support Assistant Workbench.
2、在Workbench中安装Health Center：
IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer …
IBM Monitoring and Diagnostic Tools for Java™ - Garbage Collection and Memory Visualizer 是详细的 GC 数据可视化器。GC and Memory Visualizer 解析并绘制各种日志类型，包括详细的 GC 日志、-Xtgc 输出、本机内存日志（来自于 ps、svmon 和 perfmon 的输出）。
它提供：
- 各种详细的 GC 数据值的图形显示
- 调优推荐和问题检测（如内存泄漏）
- 报告、原始日志、表格化数据和图视图
- 将数据另存为 HTML 报告、jpeg 图像或 .csv 文件（导出到电子表格）
- 查看和对比多条记录
- optthruput、optavgpause 和 gencon GC 方式的分析
参考：
WebSphere troubshooting-用工具分析GC Log
http://hi.baidu.com/onroading/item/5f26139619641ab983d2959d
IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)
IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) parses IBM verbose GC trace, analyzes Java heap usage, and recommends key configurations based on pattern modeling of Java heap usage. Only verbose GC traces generated from IBM JDKs are supported. (PMAT is a Technology Preview and is in English only.)
参考：
http://www-01.ibm.com/support/docview.wss?uid=swg27007240&aid=1
IBM Thread and Monitor Dump Analyzer for Java
参考：
http://guotufu.iteye.com/blog/1123890
What is IBM Thread and Monitor Dump Analyzer for Java?During the run time of a Java™ process, some Java virtual Machiness (JVMs) may not respond predictably and oftentimes seem to hang up for a long time or until JVM shutdown occurs. It is not easy to determine the root cause of these sorts of problems.
By triggering a javacore when a Java process does not respond, it is possible to collect diagnostic information related to the JVM and a Java application captured at a particular point during execution. For example, the information can be about the operating system, the application environment, threads, native stack, locks, and memory. The exact contents are dependent on the platform on which the application is running.
On some platforms, and in some cases, javacore is known as “javadump.” The code that creates javacore is part of the JVM. One can control it by using environment variables and run-time switches. By default, a javacore occurs when the JVM terminates unexpectedly. A javacore can also be triggered by sending specific signals to the JVM. Although javacore or javadump is present in Sun Solaris JVMs, much of the content of the javacore is added by IBM and, therefore, is present only in IBM JVMs.
IBM Thread and Monitor Dump Analyzer for Java analyzes javacore and diagnoses monitor locks and thread activities in order to identify the root cause of hangs, deadlocks, and resource contention or monitor bottlenecks.
How does it work?This technology analyzes each thread information and provides diagnostic information, such as current thread information, the signal that caused the javacore, Java heap information (maximum Java heap size, initial Java heap size, garbage collector counter, allocation failure counter, free Java heap size, and allocated Java heap size), number of runnable threads, total number of threads, number of monitors locked, and deadlock information.
In addition, IBM Thread and Monitor Dump Analyzer for Java provides the recommended size of the Java heap cluster (applicable only to IBM SDK 1.4.2 and 1.3.1 SR7 or above) based on the heuristic analysis engine.
IBM Thread and Monitor Dump Analyzer for Java compares each javacore and provides process ID information for threads, time stamp of the first javacore, time stamp of the last javacore, number of garbage collections per minute, number of allocation failures per minute, time between the first javacore and the last javacore, number of hang suspects, and list of hang suspects.
This technology also compares all monitor information in javacore and detects deadlock and resource contention or monitor bottlenecks, if there are any.
Database Connection Pool Analyzer for IBM WebSphere Application Server
参考：
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21254645#
http://yishueitian326.blog.163.com/blog/static/28586375201010935436260/
http://www-01.ibm.com/support/docview.wss?uid=swg21392440
简介：
IBM Database Connection Pool Analyzer helps you to resolve JDBC connection pool related problems through its heuristic analysis engine. This tool is a tech preview and is available in English only.
IBM Trace and Request Analyzer for WebSphere Application Server
A tool that detects delays and hangs in WebSphere(R) trace and HTTP plug-in trace. This tool is a tech preview and is available in English only.
WebSphere Application Server Performance Tuning Toolkit
参考：
http://www.ibm.com/developerworks/cn/websphere/downloads/peformtuning.html
3.2 NagiOS WAS
https://www.oschina.net/p/nagios-was/similar_projects?lang=21&sort=view&p=3
Nagios WAS 是个用来监控 IBM 的 WebSphere 应用服务器的 Nagios 插件。监控的内容包括：
MonitorJvmHeapsize
MonitorJdbcConnectionPools
MonitorThreadPools
MonitorLiveSessions
3.3 LoadRunner监视WebSphere (略)