使用 ITCAM for Application Diagnostics 诊断J2EE应用

使用 ITCAM for Application
Diagnostics 诊断J2EE应用
第 1 页共 39 页
文档修订历史
版本号修订日期注释修订者
1.0 2009-9-29 创建文档聂卜阳
1.1 2010-05-13 增加了产品架构介绍部分聂卜阳
说明：
从2009年底开始ITCAM for WebSphere/J2EE重命名为ITCAM for Application Diagnostic, 与之前不同主要是将MS集成到ITM的eWAS内，而以前的MS，DC架构依然保留，本文所含盖的范围只在传统的ITCAM for WebSphere领域，不涉及到与ITM的集成。

文中的截图一部分来自对WAS的监控，一部分来自Weblogic，原理类似。

第 2 页共 39 页
1 产品架构简介
ITCAM for AD 主要对基于J2EE的应用程序进行实时监控和历史数据分析，它能够发现并且报告J2EE应用的健康度。

它的监控贯穿整个应用流程，如应用程序服务器、中间件适配器、传输协议、数据库、并且能够监控后台如CICS、IMS等主机系统。

ITCAM for AD 可以收集应用程序请求周期的数据，然后存储到监控数据库，数据包括请求开始，结束的时间，所用的中央处理器时间等等，并且能够通过一层层的递进跟踪找到每个类，每个方法的响应时间，中央处理器时间，从而定位发生交易失败、响应恶化的请求，并找到应用程序需要改进优化的地方。

ITCAM for AD不需要用户更改任何J2EE和Mainframe的代码，收集到的数据能够用来帮助应用维护人员和应用开发人员分析系统和应用程序的健康度。

除了应用级别的数据被收集外，系统级别的数据，例如，应用服务器的状态、中央处理器的使用、内存的使用、数据库连接池、JVM线程池、EJB的使用等等，也会被收集，用来辅助用户去分析问题，解决问题。

ITCAM for AD对于这些数据提供了实时的图形化的监控界面。

对于当前环境中基于WebSphere的标准J2EE应用，可以通过部署ITCAM for AD监控来快速实现监控。

对于当前首要的报警需求，可以根据业务特征进行定义，例如对某些系统的特定重要交易的性能进行监控，并在它们发生异常时进行报警。

同时，对于资源层面和应用服务器整体的状态，也可以设置对应的报警。

1.1 ITCAM for Application Diagnostics产品架构
ITCAM for Application Diagnostics 采用集中管理模式，一台管理服务器（Manage Server/MS），若干台数据采集器（Data Collector/DC）。

Managing Server：是ITCAM for AD的核心，它接受，显示和分析各种被监控的应用服务器的性能信息。

Data Collector：是
第 3 页共 39 页
第 4 页共 39 页
ITCAM for AD的感应器，它和被监控的应用服务器一起运行，收集应用服务器的信息并传送到Managing Server上。

目标应用服务器包括Websphere应用服务器，和基于主机的CICS 和IMS后台系统。

DC部署在被管节点上，通过以下四种方式采集数据：
•BCM（Bytes Code Modification）动态字节码生成，采集请求的响应时间。

•JMX（在WAS中通过PMI）采取部分统计数据
•通过JVMPI采集JAVA虚拟机性能数据
•通过WAS Log采集日志信息
1.2 ITCAM for Application Diagnostics 产品特征
1. 覆盖所有Websphere所能运行的平台
•WAS 5.x / WAS 6.x / WAS 7.X
•WAS / Portal / Process Server / MQ / CICS
•AIX / Windows / HP Ux / Solaris / Linux / Mainframe
2. 通过单一界面同时管理环境内的WebSphere应用
•BS架构，通过浏览器访问
•支持中文
•提供可视化的管理界面
3. 无需修改代码，可对应用进行分层次监控
•L1 性能开销基本不可见（CPU 3%~6%）
•L2 在应用压力较大时请求处理消耗的CPU增加（CPU < 15%）
•L2 在应用响应上的影响很小
•L3 对应用响应时间和整体性能有比较明显的影响，不建议使用于生产模式。

1.3 ITCAM for Application Diagnostics 产品功能
1. 查看系统的基本资源配置
2. 查看实时和近期的资源使用状况，包含
•JVM CPU 使用
• JVM 内存使用
• DB 连接池使用
•事务失败统计
•线程池使用
• EJB 活动
第 5 页共 39 页
第 6 页共 39 页
• Servlet/JSP 活动
• EJB 覆盖
• Servlet/JSP 覆盖
• JNDI 状况
3. 对异常状况告警
•通过JAVA Mail
•通过 SNMP Trap
4. 通过在异常发生时设定主动数据收集来为应用诊断提供帮助
•Heap Dump/ Stack Trace/ Thread Dump (L1)
•Component Trace (L2)
•Method Trace (L3)
5. 丰富的报表
•对主机上的CICS调用进行跟踪
•跨越JVM边界的请求被自动串连监控
•通过比较同一时间段内相关指标的方式来分析问题
第 7 页共 39 页
2 性能分析以及问题诊断
通常对应用性能影响最大的环节包含三个部分：
•系统资源的使用，主要是操作系统层面的
•WAS应用服务器，J2EE容器层面
•应用程序本身，客户应用本身
本文的将阐述如何从这三个方面对WAS应用进行性能优化和问题诊断。

2.1 系统性能诊断
在系统层面上，我们可以通过最基本的操作系统命令，获得CPU，内存，IO，等性能数据，确保这些最基础的资源，比如AIX中topas或者nmon：
第 8 页共 39 页
第 9 页共 39 页
对于繁多的信息，我们首要关注的是CPU和内存，当CPU使用率高于80%整体性能将受到影响，而内存使用率则关系较多的方面，这是由于不同的操作系统对虚拟存储的算法不同导致，比如Paging Fault是一个对性能影响较大的指标，Paging Fault值较大，意味着物理内存和磁盘频繁交换，对性能影响较大；但并不一定物理内存耗尽，才出现大量Page Fault，这取决于操作系统的策略，在物理内存使用到何种状况时，需要调整。

在ITCAM for WAS中，并没有详细的OS层面的性能数据，因为它并不是一个针对OS的软件，但也包含了某些敏感的数据，比如System Paging Rate，可以从Recent Activity Display
第 10 页共 39 页
获得：
第 11 页共 39 页
2.2 J2EE容器性能诊断
2.2.1 JVM基本信息诊断
从System Resource中可以获取JVM基本信息，确保虚拟机层面没有性能瓶颈：
2.2.2 容器队列诊断
首先我们先大致了解一下WAS应用于性能相关的一些基础知识。

部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。

例如网络、数据库、内存分配、WAS服务器
的配置以及应用程序的设计。

对于一个标准的J2EE应用，一个请求到来时，往往需要经过多次转发：网络 >Web服务器Web容器 > EJB容器 > 数据库。

而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。

如果我们把每一次转发的待处理资源都看成一个队列，如下图所示：
对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。

在实
践中我们发现，为了达到这个目的，最有效的配置方式就是使得队列成为一个“漏斗”。

也就是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。

与之相关的参数和基本的性能优化参数如下：
•设置的是We b S e r v e r的最大并发用户：
o这个设置是在c o n f/h t t p d.c o n f这个文件里面配置的。

在U n i x系统中，对应的属性是Ma x C l i e n t；在Wi n d o w s系统中，对应的属性是
T h r e a d s P e r C h i l d。

•设置We b C o n t a i n e r的最大、最小并发用户：
o在管理控制台中点击应用程序服务器 >s e r v e r1>线程池 >We b C o n t a i n e r，根据观察的性能情况和应用情况输入合适的最小、最大进程数。

•对象请求代理（O R B）的线程池大小：
o在管理控制台中点击应用程序服务器 >s e r v e r1>O R B服务 >线程池，根据观察的性能情况和应用情况输入合适的最小、最大进程数。

•设置数据库的连接池属性：
o J D B C提供者 >数据库J D B C驱动名称 >数据源 >数据源名称>连接池 ，根据观察的性能情况和应用情况输入合适的最小、最大连接数。

•J V M堆参数设置的性能调优：
o应用程序服务器 >s e r v e r1>进程定义 >J a v a虚拟机，根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。

•O R B参数调用方式的性能调优：
o应用程序服务器 >s e r v e r1>O R B服务>选中按引用传递。

•关闭动态加载开关：
o企业应用程序 >应用名称 >关闭启动类重新装入开关。

o关闭会话序列化，应用程序服务器 >s e r v e r1>会话管理 >分布式环境设置 >分布式会话选择无即可。

这些信息可以通过System Resource视图获取方便的获取：
第 12 页共 39 页
第 13 页共 39 页
点击Thread Pools可查看Web容器和EJB容器的执行队列的深度，如果空闲队队列为0，那么请求必然需要排队执行，在这种情况下需要相应的增加最大队列数目，各容器队列的最大值，依然遵循漏洞策略。

第 14 页共 39 页
2.2.2.1WEB容器性能概要
依然从同样的视图System Resource，可以看到WEB容器中的WEB应用，以及性能最坏的T op5：
点击ShoppingServlet，可直接钻取更详细的统计信息：
第 15 页共 39 页
2.2.2.2EJB容器概要
EJB容器的性能，涉及到两个部分，一部分是EJB对象本身的运行性能，这部分是由应用代码决定，通过EJB视图可以看到：
第 16 页共 39 页
另一部分是ORB（Object Request Broker）性能，因为应用不能直接获取EJB，而是将请求发给ORB，由ORB负责将EJB传递出来。

通常ORB所占用的时间非常短：
2.2.2.3数据源性能
点击DB connection Pools查看数据库端池使用状况：
第 17 页共 39 页
2.3应用诊断
应用诊断包含两个部分：
•应用可用性
•运行时问题分析
2.3.1 可用性
应用的可用性是通过请求的响应是否正常，以及是否及时来判定的，从Avability视图可查看各项可用性指标：
这里能看到的是最高层面的可用性，服务器组的可用性。

服务器组是WAS服务器的逻辑群组，可以按照地域，功能，等各种方式划分。

第 18 页共 39 页
点进群组链接，可以查看该群组内所有服务器的可用性：
点进单个服务，可以查看此服务器的可用性详细信息：
第 19 页共 39 页
2.3.2 问题诊断与分析
从菜单Problem Determination可以找到各种问题诊断的方法：
第 20 页共 39 页
2.3.2.1挂起的请求
从In-flight菜单可以查看正在进行请求，对于长时间没有响应的请求，我们可以由此诊断，程序在哪里被挂起了：
点击相应的线程ID，可以进入此挂起请求的详细信息：
第 21 页共 39 页
基于以上信息，可以做一些相应的操作，如改变优先级，直接取消请求等等。

还可以从左侧菜单查看相关更多：
Stack Trace可以看到挂在哪个函数调用上了：
Method/Component Trace可以查看方法调用资源消耗，以此判定瓶颈点：
第 22 页共 39 页
2.3.2.2服务器活动状况
此视图能查看服务器，目前处于活动状况的请求，最近的请求，以及死锁状况：正在活动的请求：
第 23 页共 39 页
点击请求可以查看详细的信息，点击锁竞争，可以查看是否存在死锁
2.3.2.3WEB会话检查
查看目前链接到服务器上的会话，由此可以了解客户使用服务的状况
第 24 页共 39 页
2.3.2.4内存分析
2.3.2.4.1Heap Dump导出分析
堆栈导出，通过专业的分析工具分析，这里ITCAM和WAS的堆栈分析工具集成，导出的数据可直接用于MDD4J诊断，堆栈导出：
第 25 页 共 39 页
通过ISA 获取
MDD4J
通过MDD4J 分析：
第 26 页共 39 页
2.3.2.4.2内存使用分析
第 27 页共 39 页
通常我们将内存的使用，和请求，CPU，活动的会话，响应时间，GC回收，等结合分析推动内存使用是否合理，比如：
请求数维持较为稳定的水平，而堆栈却不断增加，这里有潜在的内存泄漏。

2.3.2.4.3通过Heap Dump比诊断内存泄漏
结合堆栈比较查找内存泄漏的对象类型。

方法是通过创建堆栈快照，然后对比快照中快速增加
第 28 页 共 39 页
可疑的JAVA 类，诊断泄漏点：
在一定时间间隔内创建两个
Heap Dump
完成之后，我们比较两个
Heap dump
比较对象的数目的变化：
第 29 页共 39 页
2.3.2.4.4智能判定潜在的内存泄漏
ITCAM能根据一段时间内，内存增长，请求数目，综合判定是否存在潜在的内存泄漏，作为参考：
潜在泄漏的对象：
第 30 页共 39 页
出现在代码行数：
2.3.2.5基于Trap的监控
ITCAM对于WAS的监控分为L1，L2，L3三级，监控的粒度依次增强，所消耗的资源也相应增加，为了在资源消耗和监控采集粒度之间取得较好的平衡，ITCAM在监控级别之间可以根据问题的发生动态的调整。

当问题发生时，跳转到L3，采集更为全面的信息，供问题诊断，当问题不在出现时，跳回到L1级别。

具体的实现流程如下：
第 31 页共 39 页
1. 设定相应的阀值条件，作为问题“发生”的依据
2. 当此条件触发第一次时，ITCAM将监控级别设为L3
3. 当此条件第二次触发时，ITCAM将根据需求采集对应的信息
在此，当阀值偶尔触发一次，之后连续若干次正常范围之内，这样的情况ITCAM将自动将级别设为L1，多次正常范围内就跳回，可以自定制。

上图的例子中，定义了请求超过15秒，则搜集Component/Method Trace，相应的我可以选择上，发送SNMP TRAP和邮件，对于某些的类型，我们还可以收集调用堆栈，如下图所示：
第 32 页共 39 页
一旦事件触发，我们可以从TRAP历史记录查看问题发生时，为我们收集的各种信息，比如调用堆栈，组件函数资源占用列表，等等。

第 33 页共 39 页
Misbehavour Transaction是我们常用的，只有这项能动态调整监控级别，并且收集到的Component/Method Trace能非常准确的定位到时间消耗的瓶颈。

第 34 页共 39 页
3性能分析报告
性能分析报告分为两大类，一类是基于系统资源的的：
另一类是基于应用的：
根据报表产生向导，可以产生各中性能和可用性的报表，官方的文档有详细的描述，在此不再重复。

第 35 页共 39 页
4对应用生命周期的管理
ITCAM针对单个问题的诊断的优化在第一个章节已经描述，此章节将阐述在整个应用管理生命周期中如何使用ITCAM for WAS。

4.1 运维管理模式
第 36 页共 39 页
4.2 运维管理优化流程
第 37 页共 39 页
4.3 应用完整的生命周期的管理
5实际应用案例
l以下是ITCAM for Application Diagnostics在某客户实施并有效长时间运行的实践参考。

通过ITCAM for Application Diagnostics的实施：
1. 监控运行对生产没有不良影响
2. 帮助预见多次应用宕机的发生
3. 管理员通过主动介入提升了应用的整体可用性
4. 管理员能够对应用异常趋势有更为精确的了解并积累知识
l客户的应用状况：
1. 对访问最频繁、响应最缓慢以及最消耗CPU的请求进行定位。

2. 对应用表现出的内存泄漏倾向进行定量评估。

3. 对应用整体可用性进行定量统计（99.93%）。

4. 精确定位宕机的时间点（7月15日10:20~10:52 ）。

5. 对应用平均吞吐量进行定量统计（4175.02笔/小时）。

6. 定量确认业务高峰（8:00 ~ 17:00）。

7. 定量统计业务高峰应用平均吞吐量（11420笔/小时）。

第 38 页共 39 页
8. 定量统计工作日平均并发用户（30个会话）。

9. 定量统计业务高峰平均并发用户（50个会话）。

10. 定量统计应用内存平均使用量(上半月)：110MB。

11.定量统计应用内存平均使用量(下半月)：95MB。

l运行状况（某个月）
1.定位发生最为频繁的请求
2.定位最消耗CPU的请求
3.定位响应最缓慢的请求
l切实的提高了客户的运维水平
第 39 页共 39 页。