使用 ITCAM for WebSphere 进行性能诊断

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

王 锋 (wfenggz@cn.ibm.com)IBM全球服务（中国）有限公司

2008 年 12 月 18 日

本文以 ITCAM for WebSphere 在 WebSphere Application Server （简称 WAS）自带样本应用中的性能诊断为例，介绍了借助于此类专业工具快速定位性能瓶颈的思路。

背景介绍

随着基于 Java EE 多层架构的应用在企业级范围内的广泛部署，来源于此类架构的性能问题日益引起人们的关注。架构的多层性使得性能问题出现时，需要花费大量的时间和精力逐步排查，以定位性能瓶颈，这往往是一个费力不讨好的过程，更为重要的是，面对关键业务系统，性能问题对业务运营的冲击是直接而明显的。

WAS 是目前业界使用最为广泛的应用服务器之一，为金融、电信、制造等行业的关键业务系统提供基础支撑，Tivoli 是出众的 IT 基础架构及应用管理软件，如何将 IT 管理软件有效的应用到基础架构软件中，提高日常管理工作的有效性和精确性，ITCAM for WebSphere 或许能给出部分答案。

ITCAM 简单介绍

ITCAM 即 IBM Tivoli Composite Application Management，是 IBM 五大品牌软件系列中 Tivoli 的一个组成部分，它主要专注于多层架构下的应用的管理，术语 Composite，即合成的，意指应用是多层合成的。

ITCAM 本身由一系列产品组成，有专门针对 SOA 管理的 ITCAM for SOA，也有专门针对其他 J2EE 应用服务器管理的 ITCAM for J2EE，而 ITCAM for WebSphere 则是作为单独的一个产品系列存在。

ITCAM for WebSphere 在功能上提供了性能分析、线程死锁分析、内存泄露分析等一系列高级的功能，通过使用一个单一的管理控制台即可对企业范围内的 WAS 进行高级诊断。

ITCAM 自身的架构分为两个层次：数据收集层和管理服务层，如图 1：

数据收集层的主要部件就是 Data Collector，即数据收集器，它位于被管理的服务器上，主要工作是收集必需的采样数据，这些数据随后被发送到 ITCAM 的管理服务层。

管理服务层的关键部件是 Managing Server，即管理服务器，它包含了若干个服务，这些服务接收发送自数据收集器的数据，经过统计、分析和整理，向使用者提供性能分析报告。

管理服务器后端是一个数据库，用于存放历史数据。

样本应用 Plants by WebSphere 简单介绍

这是 WAS V6.1 自带的一个样本应用，该应用是一个网上店面，专门销售植物和园艺工具。

登录网上店面后，简单的做一些查询，购买商品操作，然后准备提交订单，下图 2 是提交订单前的确认信息的界面：

在使用中发现，提交订单的操作异常的消耗时间，一般需要经历 15 到 20 秒不等的时间才能出现如图 3 提交成功的页面：

为了彻底了解提交订单后是哪个环节导致了耗时的操作，我们将借助于 ITCAM for WebSphere 这一强大的管理工具进行问题的诊断定位。

回页首

ITCAM for WebSphere 的配置

ITCAM for WebSphere 的主要配置工作都是针对数据收集器的，这些工作有的可在 ITCAM for WebSphere 的控制台完成，有的则需要在数据收集器端直接修改配置文件。其配置的过程如下：

配置类过滤配置

类过滤配置简称配置，配置是给数据收集器使用的，用来指导数据收集器在工作时哪些类需要进行数据收集，而哪些类不必进行数据收集。ITCAM for WebSphere 中可以存在多个不同的配置，这些配置保存在配置库当中。

登录 ITCAM for WebSphere 管理控制台，选择菜单管理 > Server Management > Data Collector Configuration（图 4），以进入 CONFIGURED DATA COLLECTOR OVERVIEW 界面（图 5）。

在 CONFIGURED DATA COLLECTOR OVERVIEW 界面（图 5）中点击 Configuration Library 链接，即配置库。

来到 DATA COLLECTOR CONFIGURATION LIST 界面，屏幕右侧即为配置列表，可以看到内置了多个缺省的配置，选择名为 J2EE Default 的配置（图 6），点击其对应的 Duplicate 按钮，我们要在此配置的基础上复制一份，然后略作修改。

在 DUPLICATE CONFIGURATION 界面（图 7）中，将新配置的名称命名为 WebSphere，然后点击 Save 按钮。

回到更新的 DATA COLLECTOR CONFIGURATION LIST 界面，新增加的 WebSphere 配置已经在列表当中（图 8），点击其对应的 Modify 按钮，进行定制。

在 MODIFY CONFIGURATION 界面（图 9）中对 WebSphere 配置的类过滤进行定义。定义由两部分组成，Exclude和 Exclude Override。

Exclude 中定义了那些不需要进行数据收集的类；而Exclude Override 中则定义了需要进行数据收集的类。Exclude 和 Exclude Override 中的类名都可以使用通配符来表示。

为了便于理解，我们通过一个简单的例子加以说明。请考虑以下情况，我们在 Exclude 中使用了通配符 com.ibm.*，则所有 com.ibm 包中的类都被排除在外，但我们同时又希望可以有少量 com.ibm 包中的类不被排除在外，如 com.ibm.websphere.samples，这个时候只需要在 Exclude Override 中加入 com.ibm.websphere.samples.* 就可以了。

针对本例中的情况，在 Exclude(Classname) 编辑框中追加 ibm.console.* ，以避免对 WAS 控制台所使用的类进行数据收集；在 Exclude Override (Classname) 编辑框中追加 com.ibm.websphere.samples.*，因为在 Exclude 中有 com.ibm.*，为了能对 Plants by Websphere 中所使用到的类进行数据收集，所以要在 Exclude Override 中又将 Plants by Websphere 使用到的类挑出来。

完成后点击 Save 按钮。

由 Exclude 和 Exclude Override 组合而成的类过滤设置，其粒度与将来产生的性能报告的详细程度息息相关：过滤设置得太细，很多类方法的调用可能会漏掉，这当中就可能包括那些耗时的方法调用；反之，又会将那些无关紧要的方法调用也统计出来，并加重了服务器的负担

一般地，基础软件类都是在 Exclude 中的，比如JDK核心类、J2EE核心类、WebSphere核心类等，而业务系统中所使用到自开发类则不应该处于 Exclude 列表中。

将类过滤配置应用到数据收集器

数据收集器在运行期间能正常收集数据，必须有一个具体的配置应用到数据收集器上。一个数据收集器，如果没有应用配置，我们称之为未配置的数据收集器，反之，则称为配置的数据收集器。

在 CONFIGURED DATA COLLECTOR OVERVIEW 界面（图 10）中点击 Unconfigurated Data Collector 链接，即未配置的数据收集器。

在 UNCONFIGURED DATA COLLECTOR OVERVIEW 界面中，鼠标勾选相应的数据收集器（图 11），并在 Apply a Configuration 下拉列表中选择 WebSphere 配置，然后点击 Apply 按钮。

页面自动跳转到 CONFIGURED DATA COLLECTOR OVERVIEW 界面，可以看到之前未配置的数据收集器现在已经变为配置的数据收集器（图 12）。

设置数据收集器监控级和采样频率

在 ITCAM for WebSphere 管理控制台，选择菜单管理 > Managing Server > System Properties（图 13），进入 SYSTEM PROPERTIES 界面。

在 SYSTEM PROPERTIES 界面中，设置对所有的数据收集器均有效。

监控级别分为三级：

针对每个级别，缺省的采样频率都是 2%，这是相当保守的设置，目的是使得对目标服务器的影响尽可能降到最低，这对于生产环境是合适的。

在测试环境中的取样，可以采取比较激进的设置，如 100% 的采样，这里我们将使用最高监控级 L3，并且设为 100% 采样，如图 14 所示：

打开数据收集器对方法调用的时间统计

缺省的，在 L3 监控级别，数据收集器只会对 EJB, JNDI, RMI, Servlet 等类型的调用作时间统计，为了获得更加详细的统计数据，在某些情况下需要对所有的方法调用进行时间统计，这需要手工修改数据收集器的配置文件。

打开 DC_HOME/runtime/app_server_version.node_name.server_name/custom/toolkit_custom.properties 文件，将

com.ibm.tivoli.itcam.toolkit.ai.methodentryexittrace=false

中的 false 改为 true。这将打开 L3 监控级别下对方法调用的时间统计。

将

#am.camtoolkit.gpe.customxml.L3=C:/IBM/itcam/WEBSPH~1/DC/itcamdc/etc/method_entry_exit.xml

前的 # 号去除，表示对所有的方法调用作时间统计。

重启数据收集器所在的 WAS

在本章节中，我们分别通过 ITCAM for WebSphere 的管理控制台和修改数据收集器物理配置文件的方式，对 ITCAM for WebSphere 的工作环境做了适当的配置。

为使配置生效，需要重新启动数据收集器所在的 WAS 进程。

回页首

使用 ITCAM for WebSphere 进行分析

执行两次Plants by WebSphere 网上店面中的采购流程，该流程包含了登录、查询、提交订单等操作，目的是使得数据收集器能完成采样的任务，这些采样的数据是我们进行统计分析的依据。

产生性能分析报告

在 ITCAM for WebSphere 管理控制台，选择菜单性能分析 > Create Application Reports > Request/Transaction，如图 15 所示：

在 SERVER SELECTION 界面（图 16）中的 Server 下拉列表中，选择对应数据收集器所在的 WAS 实例，然后点击 Next 按钮。

在 REPORT FILTERING OPTIONS 界面（图 17）中的 Metric 下拉列表中，选择 Response Time 作为度量，然后点击 Next 按钮。

在 DATE RANGE SETTINGS 界面（图 18）的 Preset 下拉列表中，选择时间段为 Last 60 Minutes，然后点击 View Report 按钮。

察看性能分析报告

分析报告产生后，页面自动跳转到 TREND REPORT 界面（图 19），我们可以看到在 Last 60 Minutes 时间段，所有请求的平均响应时间是 1632 毫秒。因为在产生报告的设置过程中，选择的度量是响应时间，所以这里的给出的统计就是以响应时间计。

在 TREND REPORT 界面（图 19）中，点击红色柱状图，将进入 URL 请求分布图。

来到 DECOMPOSTION REPORT 界面（图 20），这里展示的是 URL 请求的分布情况，处理提交订单请求的 URL 是 /PlantsByWebSphere/servlet/ShoppingServlet，点击以获得进一步详细的统计。

在URL 请求统计的 Detail 属性页（图 21），仔细观察该 URL 请求的详细采样统计分析，发现有 2 次请求的响应时间异常的高，分别是 29 秒和 21 秒！

点击两个当中的任何一个感兴趣的采样进入。

来到 TRACE REPORT 界面，选择 Flow View 属性页，这将把该次请求的层层调用堆栈展示出来，如图 22 所示：

我们需要观察的是 ΔElapsed Time 时间，确认在哪个方法调用中，所消耗的时间最长。依次下翻，如图 23 所示，可以发现一个名为 MailerBean 的 EJB 当中的 createAndSendMail 方法占用时间长达 29031 毫秒，基本上为该次请求响应时间的 99% 以上，因此可以确认问题出在这里！

在大部分应用中，通常与数据库的交互是性能瓶颈所在，而在该例中，一个发送邮件的操作占用如此之多的时间，实属不太正常。

通过 ITCAM for WebSphere 产生的性能分析报告，我们很快的定位出了导致了性能问题的环节。

分析 MailerBean 代码

在 MailerBean.java 中，我们定位到 createAndSendMail 方法，发现在 JNDI 代码调用之后，到 createAndSendMail 方法结束之前，有若干个方法调用：

public void createAndSendMail(CustomerInfo customerInfo, String orderKey) 
throws MailerAppException {
   try {
      EMailMessage eMessage = 
      new EMailMessage(createSubjectLine(orderKey), 
      createMessage(orderKey),customerInfo.getCustomerID());
      Util.debug("Sending message" +
                   "\nTo: " + eMessage.getEmailReceiver() +
                   "\nSubject: " + eMessage.getSubject() +
                   "\nContents: " + eMessage.getHtmlContents());

      Session session = 
      (Session) Util.getInitialContext().lookup(MAIL_SESSION); 

      MimeMessage msg = new MimeMessage(session); 
      msg.setFrom();

      msg.setRecipients(Message.RecipientType.TO, 
        InternetAddress.parse(eMessage.getEmailReceiver(), false)); 

      msg.setSubject(eMessage.getSubject());
      MimeBodyPart mbp = new MimeBodyPart();
      mbp.setText(eMessage.getHtmlContents(), "us-ascii");
      msg.setHeader("X-Mailer", "JavaMailer");
      Multipart mp = new MimeMultipart();
      mp.addBodyPart(mbp); 
      msg.setContent(mp); 
      msg.setSentDate(new Date());

      Transport.send(msg); 

      Util.debug("\nMail sent successfully."); 

   }
   catch (javax.naming.NamingException e) {
      Util.debug("javax.naming.NamingException, Has mail session been created?"); 
   }
   catch (Exception e) {
      Util.debug("createAndSendMail exception : " + e); 
      throw new MailerAppException("Failure while sending mail");
   }
}

而这些方法由于属于 javax.mail 包的类所提供的方法，而 javax 包在类过滤配置中被排除在外，即任何属于 javax 包的类提供的方法，都不会被统计分析，而这些遗漏的方法则恰恰可能是引起性能问题的方法！

从这里我们可以看到，类过滤配置中，对 Exclude 和 Exclude Override 的定义将直接影响性能分析报告的详细度。

在活动的请求视图中进一步分析

重新对 Plants by WebSphere 网上店面中的采购流程执行一次，在提交订单尚未返回应答之前，在 ITCAM for WebSphere 管理控制台，选择菜单问题确定 > Server Activity Display（图 24）。

在SERVER ACTIVITY DISPLAY 界面（图 25）中的 Server 下拉列表中，选择对应数据收集器所在的 WAS 实例。

页面自动跳转到 SERVER ACTIVITY DISPLAY 界面中的 Active Requests 属性页，这里可以看到正在处理中的提交订单的请求（图 26），点击 ACTIVE REQUESTS 表格中的 /PlantsByWebSphere/servlet/ShoppingServlet 链接以获取进一步详细的数据。

在随后出现的界面中，点击 Stack Trace 链接，这将把当前请求的调用堆栈打印出来，图 27 展示了这个调用堆栈的顶部。

可以发现，在 MailerBean 这个 EJB 的 createAndSendMail 方法中，所包含的后续方法调用，属于一系列的 javax 包中的接口和对应的实现类，这与我们在 MailerBean.java 代码中分析的结果是一致的。

将页面继续往下翻，展示调用堆栈的中部，让 createAndSendMail 方法出现在页面中能观察到的位置（图 28），然后以 createAndSendMail 方法为起始，自下而上观察。

上图所揭示的问题根源就相当直观了，由于 java.net.SocketInputStream 类当中 socketRead 这个阻塞方法的调用挂起，直接导致 MailerBean 的 createAndSendMail 方法占用了大量的时间这一表面现象。

回页首

结论

ITCAM for WebSphere 有效的帮助我们定位出了导致性能问题的环节，接下来的工作就是有的放矢，对相应环节进行调整优化，比如操作系统、网络、WAS 本身的配置、代码等。

在很多情况下，响应时间超长或线程挂起，通常都是因为某些关键资源无法获取，比如请求数据库连接、等待 SQL 返回结果、等待网络套接字可读等。

在本例中，影响性能的环节似乎与网络通讯相关。我们把重点放在网络配置的检查上，发现 Windows 机器在对 WAS 中缺省的邮件传输主机 yourcompany.ComOrNet 进行名字解析时，内部域名服务器意外的将这个本不存在的邮件传输主机解析为 IP 地址 59.37.71.87，尽管该地址的 SMTP 端口处于监听状态，但对于任何未经授权的连接都不予以响应。而 javax.mail.Transport 接口的 send 方法在执行后，会一直等待响应直到连接被重置，这个过程耗时 15 ~ 25 秒不等，这就是导致整个提交订单的操作消耗大量时间的直接原因。

参考资料

• Tivoli Composite Application Manager for WebSphere 文档:提供了 TCAM 相关信息。
  
  
• WAS ND 信息中心:提供了 WAS ND V6.1 的相关信息。
  
  
• 使用 ITCAM for WebSphere 对 WebSphere 进行监控管理和问题诊断:着重介绍了与 ITM 的集成并在 ITM 中对 WebSphere 进行监控，问题诊断中包含了内存泄露分析的案例。
  
  
• IBM developerWorks 中国 Tivoli 专栏:提供了 Tivoli 方面的文章等资源。
  
  
• IBM developerWorks 中国 WAS 专栏:汇集了有关 WAS 管理工具，部署与安全，性能与集群，以及最新版本特性等多方面的资源。
  
  
• ITCAM for Websphere v6.0 与 ITM v6.1 集成的快速指南:本文简单清晰的介绍了 ITCAM Websphere 的工作原理、安装配置和集成后的功能与效果，是一个良好的 ITCAM for Websphere v6.0 与 ITM v6.1 集成的快速指南。
  
  
• 深入剖析 ITCAM for SOA 与 WebSphere Service Registry and Repository的集成:本文从体系结构的角度系统地介绍了 IBM Tivoli Composite Application Manager for SOA（ITCAM for SOA） 和 IBM WebSphere Service Registry and Repository （WSRR） 的集成架构，详细说明了集成模块 ITCAM for SOA Event Handler 的技术细节，以及动态地在 IBM WebSphere Service Registry and Repository 中记录和存储服务性能元数据的方法。

关于作者

		王锋是 IBM 软件部 WebSphere 高级信息工程师，关注的领域是企业级应用架构。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？