CA Wily 最佳实践如何诊断应用系统中的问题

摘要

诊断复杂的J2EE应用程序中的性能问题是一项艰巨任务。IT部门人员的责任是确保应用程序具备优越的性能且持续可用。出现性能问题时能够准确判断应归咎于特定应用程序组件，还是某个应用程序连接的后台或前端系统。本文着重讨论J2EE应用程序中常见的性能问题；分析引起这些性能问题的根本原因；提出如何准确诊断并迅速排除性能问题的可行性建议，以供参考。

目 录

1. 前言 ................................................................................................................................................ - 3 -

2. 故障征兆 ....................................................................................................................................... - 3 -

3. 性能问题的诊断为何如此困难 ............................................................................................... - 3 -

4. 故障现象 ....................................................................................................................................... - 4 -

5. 关键统计指标的测量 ................................................................................................................. - 6 -

6. 实验工作 ....................................................................................................................................... - 7 -

7. 诊断：测试您的推断 ................................................................................................................. - 7 -

8. 诊断示例 ....................................................................................................................................... - 9 -

9. 案例分析 ....................................................................................................................................... - 10 -

10. 结束语 ........................................................................................................................................... - 13 -

故障征兆

概述

性能问题的诊断为何如此困难

特定使用模式下应用程序的性能优劣并无现成规则可循。（就严格意义上的实时工程而言，借助速率单调分析

等方法的确可以完成这项工作，但已超出本文研究的范畴，在此不做讨论）。网络中是否存在另一个系统正在

密集使用共享的后台服务，必将极大地影响系统的实际性能。系统性能或许还取决于JDBC驱动程序与数据库

版本是否严格匹配。也可能出现这样的情况：开发人员三年前编写的代码，恰巧在这个时候出现特定类型的异

常，而您急需的用以解决问题的回馈信息偏偏包含在那些异常当中。

典型业务系统的性能呈现整体涌现性（emergent property）特征，是成千上万个变量（交互式）和决策共同作

用的结果。就如同人的身体，是一个由众多联锁的组成部分和过程构成的整体。在文中我们采用统摄性模式以

简化问题。

前言

如果需要您来诊断J2EE应用程

序中的性能问题，Java系统的复

杂性俨然将问题变为难以诊治

的疑难杂症。为了准确查明问

题所在，您需要对系统的故障

征兆有一个全面的了解，还需

要做大量的调研工作，提出适

当的补救措施。本文着重讨论

J2EE应用程序中常见的性能问

题，分析引起这些性能问题的

根本原因，提出如何准确诊断

并迅速排除性能问题的可行性

建议，以供参考。

应用程序出现性能问题的征兆是什么？您所观察到的故障征兆诱导你

对所有可能出现问题进行全面检索。拿起笔记本开始向人们收集数

据。努力从假定推断中抽身出来，以确凿的证据认定系统的实际行

为，查找引起性能问题的根本原因。系统中常见的故障征兆列表如下

■ 持续运行缓慢。时常发现应用程序运行缓慢。通过改变环境因子

（如负载量、线程池大小、数据库连接数等）也无法有效提升整体

响应时间。

■ 系统性能随时间的增加逐渐下降。在负载稳定的情况下，系统运行

时间越长速度越慢。可能是由于超出某个阈值范围，系统运行频繁

出错从而导致系统死锁或崩溃。

■ 系统性能随负载的增加逐渐下降。随着用户数目的增多，应用程序

的运行越发缓慢。若干个用户退出系统后，应用程序便能够恢复正

常运行状态。

■ 间发性的系统挂起或异常错误。有时候可能受负载或其它因素影

响，页面不能完全显示，又或者是追踪到异常和堆栈的错误页，用

户此时会看到系统挂起的情况。系统挂起的次数可能会稍有不同，

然而即便是经过预烧（“burn in”）试验也无法完全消除。

■ 可预见的死锁。系统挂起或系统出错发生的频率随着时间的推移明

显增多，直到系统完全死锁。通常借助自动重启的故障管理模式解

决上述问题。

■ 系统突然出现混乱。系统正常运行，且在或多或少的一段时间内

（譬如，可以是1小时也可以是3天）拥有一致优越的运行性能，却

突然毫无征兆地出错甚至死锁。

故障现象

您所观察到的“疾病”征兆的根本原因是什么？是普通流感还是肺炎初期？是应用程序内

部潜在的性能问题还是JVM外部进程出现了问题？表一是应用程序性能下降的常见原因列

表，具体如下

“疾病”

内存泄漏呈线性增长

内存泄漏呈指数级增长

导致无限循环的编码缺陷

资源泄漏

外部瓶颈

外部系统的过度使用

频繁调用CPU密集型组件的

编码缺陷

桥接层本身存在的问题

内部资源瓶颈：资源的过度

使用或分配不足

不断重试

线程阻塞点

线程的死锁或活锁

网络饱和

描述

各单元（如每个事务或每个用户等）的内存泄

漏，导致内存使用率随时间或负载的增加呈线

性增长。系统性能随时间或负载的增加大幅下

降，重启后系统可恢复正常

内存泄漏呈双倍增长，导致系统内存消耗随时

间呈指数曲线变化

线程在while语句返回值为真的情况下发生阻

塞，将最终演变成为CPU密集型和等待密集型

或螺旋等待变量

JDBC语句、CICS事务网关连接等出现资源泄漏，

引发Java桥接层和后台系统出现严重性能问题

后台或其它外部系统（如用户验证）运行缓

慢，大大影响J2EE应用服务器及应用程序的运

行速度

J2EE应用程序发送的请求过大过多，滥用后台

系统资源

J2EE领域的通病是：些许编码缺陷或少量编码

的交互失败，都会令CPU挂起，从而将数据流

量速度降至蜗行

桥接层（如JDBC驱动、CORBA到遗留系统的连

接等）存在执行缺陷。需要不断对数据和请求

作编组和取消编组操作，导致该层的数据流量

速度降至蜗行。这种故障现象在早期阶段与外

部瓶颈极为相似

内部资源（如线程、放入存储池的对象等）匮

乏，却无法判断是正常情况下随负载增加而引

起的资源过度使用，还是由于资源泄漏引起

失败请求的频繁重试（某些极端情况下将无休

止重试）

线程退回到无法完成的同步点，造成通信阻塞

通常只是“获取顺序”问题

等待时间长或基本无法将任何请求打包，导致

系统异常停运、系统挂起或活锁等情况的出现

征兆

系统性能随负载的增加逐渐下降

系统性能随时间的增加逐渐下降

系统性能随负载的增加逐渐下降

系统性能随时间的增加逐渐下降

可预见的死锁

系统性能随时间的增加逐渐下降

系统突然出现混乱

系统持续缓慢运行

系统性能随负载的增加逐渐下降

系统持续缓慢运行

系统性能随负载的增加逐渐下降

系统持续缓慢运行

系统性能随负载的增加逐渐下降

系统持续缓慢运行 系统性能随负载的增加逐渐下降

系统性能随负载的增加逐渐下降

间发性的系统挂起或异常错误

可预见的死锁

系统突然出现混乱

系统性能随负载的增加逐渐下降

间发性的系统挂起或异常错误

可预见的死锁

系统突然出现混乱

系统突然出现混乱

系统持续缓慢运行

系统性能随负载的增加逐渐下降

间发性的系统挂起或异常错误

原因或解决方法

虽然有许多外在因素存在（如各单元数据的

链表存储、尚未回收的缓冲中的回收或增长

操作等），但最为常见的原因还是资源泄漏

通常是由于不断向集合中添加新元素（如向

量、HashMap类等），却从不对其进行删减

需要进行侵入式循环切除

通常是由于遗漏了Finally模块，或者只是没

有用close函数关闭代表外部资源的对象

向专家（包括可靠的第三方或系统管理员

等）咨询特定外部瓶颈问题的有效解决方法

消除冗余的工作请求，分批处理同类工作请

求，把大请求细分为若干个小请求，调整工

作请求或后台系统（例如为公共查询的关键

字建立索引）等

最好的解决方法是将数据存储在本地缓存

中，或者为执行算法配备高速缓冲存储器

检查桥接层与外部系统的版本是否兼容。如

果可能的话，对不同桥接供应商进行评估。

通过重新规划设计系统架构，则可完全旁路

桥接层

若因资源分配不足引起，则可依照最大预期

负载值上调存储池的最大容量；若因资源过

度使用引起，请参看本表“外部系统的过度

使用”一栏

后台系统可能已经完全宕机。监控系统可用

性对这样的状况有所帮助，也可以只是将多

次重复尝试的请求从成功的请求中筛选出来

或许根本没有必要进行同步（只需对系统重新

设计稍加改良），当然也可以定制一些外在的

锁定策略（如读取器或写入器的读/写锁）

解决方法选项包括主锁、即定的获取顺序以

及银行家算法

如此棘手的问题正在侵蚀着网络系统，如果

不及时升级系统的基础架构，提升网络及路

由器的运行速度，将无法扼制日后类似问题

的出现

表一

关键统计指标的测量

作为诊断系统性能问题的权责人员，您必须持续跟踪应用程序健康度的关键统计指标。您

能够测量到什么？又有什么工具可以提供帮助？具体如下

■ 内存的总体使用状况。多个不同层级（如JVM堆和操作系统）的内存使用状况。Java堆

事件探查器对堆的使用状况清晰可见；top，vmstat以及Windows Perfmon等工具对操作系

统层级的内存使用状况实时可见。在您的JVM中打开可用的-verbose:gc选项，便能够轻松查

看Java堆的汇总视图。

■ CPU时间。包括CUP时间汇总（通过top等功能实现）、每个组件占用的CPU时间、每种

方法占用CPU的时间（数据可通过Java事件探查器获得）。

■ 实际运行时间（又称作“真实”时间）。包括每个事务、每个组件和每种方法的实际运

行时间。可参照统计平均值，也可分别统计单个数据点的数值。Java事件探查器能够提供部

分此类数据，尽管如此，采用适当的应用程序监视解决方案才是您的最佳选择。

■ 内部资源。包括已分配的内部资源数量、使用中的内存资源数量，等待的客户数量、获

得某种资源的平均等待时间、某种资源的平均使用时间、使用某种资源完成工作请求的平

均时间。应用服务器通常会提供这些数据的最小可视化视图。

■ 外部资源。包括已分配的外部资源数量、使用中的外部资源数量、等待的客户数量、

平均等待时间以及由外部系统直接测量的数据（例如外部系统视图，表征其如何快速地完

成工作请求）。值得一提的是，运行应用服务器的操作系统和硬件也是“外部资源”（例

如，您是否使用过多进程和端口？）。对这些资源进行测量有两种形式：在JVM内部测量

提供该资源的桥接层；用外部资源自带的工具对其本身进行测量。

■ 网络资源使用状况。网络嗅探器等网络设备提供带宽使用率、响应的时间延迟等数据，

操作系统的本地工具（如netstat）也能够提供上述数据。

■ 系统状态。包括Thread- Dumps的使用、日志文件、追踪文件以及堆栈追踪等。深入分析

时也可引用调试器中查看到的变量的值。

图5.1 某电信应用系统的

监控示例，关键指标在一

张视图展示，便于监控

实验工作

很多时候，在一次标杆测评中获得的数据并不足以揭示答案。完成系统诊断的难点在于：

您要以有限的预算同时进行试验以及实验工作。应该进行何种试验？又需要观察或修改哪

些变量？这正是以下要回答的问题

■ 尝试观察系统行为随时间的变化。在恒定负载条件下观察测量值随时间的变化趋势。这

个过程短则一小时，长则数天。譬如您可能观察到内存使用率随时间的增加而增长。当内

存使用总量达到上限时，JVM用于碎片收集的时间、操作系统颠簸及内存页抖动的时间都

会增加，从而使得您的用户事务处理的总体响应时间延长。若GC进程崩溃，全部碎片的收

集耗时过长，将导致任何正在进行的事务处理出现超时和异常。此时就必须全面查找资源

或内存泄漏。

■ 尝试改变系统负载状况。选择3到4个工作负载（如10个、50个或100个用户），收集各

用户数据。图示化表示上述负载的测量值，比如您会发现：即使您的帐户登陆Servlet组件的

响应时间少于50毫秒，负责销售税计算的EJB组件的运行速度还是随用户数目的增多直线递

减。如果负载状况下该EJB组件性能的差异基本能够解释负载状况下总体响应时间的变化，

那么就需要对该组件进行深入分析。当然也要尝试将该负载退出，看看系统能否恢复正常

。

■ 尝试将大系统划分成若干规模较小的子系统，然后再依次测试。选择单条或多条坐标

轴划分系统。最基本的是系统层（包括负载均衡器、网络服务器、应用服务器、后台系统

等）。其它情况也可能包括用户帐户、内部组件、事务类型以及单个页面。以用户帐户为

例，在A用户的帐户下运行某些负载，然后在B用户的帐户（A、B最好存在较大差异）下运

行某些负载，比较两组数据的不同测量值；或者依次测量您的后台系统，对应用程序中频

繁调用后台系统的地方进行重点测试。根据您想验证或推翻的推断的不同，可取用不同的

坐标轴划分系统。建议如下

◆ 如果某个用户的登陆看似会引发某种问题，则可能是由该用户帐户的配置文件（如载入

2000个采购订单的完整历史记录）引起，也可能是由该用户使用该系统的方式（如页面访

问的顺序、某个用于检索个别文档的查询字符串）引起。

◆ 如果您使用的是群集系统，不妨以单台设备为单位划分系统。有时无论做何努力，列

表框中始终没有最新的应用服务器补丁或操作系统补丁（这些补丁能够极大地改善系统性

能）。除此之外，还需留意负载均衡器或守护进程，查看其是否均衡分配工作负荷，是否

及时响应入站请求。

7. 诊断：测试您的推断

至此，您应当拥有足够的信息去推断引起性能瓶颈的原因（参见表一）。为了确认推断正

确与否，有针对性地对多个备选推断进行筛选，就需要分析更多的信息，对系统进行附加

的标杆测评。这里提供部分建议以供参考

■ 通过查看CPU总体使用率，可将编码缺陷（不论是应用程序组件还是桥接层本身）和瓶

颈（包括内部或外部瓶颈）准确区分开来。当CPU总体使用率不随负载状况的变化而改变，

但系统的总体响应时间却随之变化时，则说明应用程序大部分时间都处于等待状态。

■ 某个外部资源看似出现了问题，并不代表您能够立即把责任归咎于它。譬如，桥接层本

身出现问题或者出现某个联网问题时，数据库看似运行缓慢，实则不然。举一个更为简单

的例子，您的数据库访问要求可能并不合理（如用户每次登录需将两百万行数据插入3个表

单）。因此有必要不时地将桥接层（如JDBC驱动程序）的响应时间与系统资源提供的时间

或专用工具（如DBA Studio）的本地时间相比较。

■ 架构图表有助于了解系统内部的整体交互情况。值得一提的是，示意图并不是真实的区

域版图。编码缺陷或对架构意向的错误理解都有可能使系统的实际行为偏离期望值。性能

监控工具提供的硬数字比一份声称“每个用户事务只发送一条SQL语句”的文档更加具有信

服力。

■ Occam’s Razor原理（即“如无必要，勿增实体”）。现在来讨论您的备选推断：一

是在某个拥有两百万行代码的系统中有一个存在编码缺陷的组件，该组件上周才与系统整

合；二是JVM的即时编译器正在生成有缺陷的机器码，严重破坏了该变量的内存完整性。

除非您能够拿出具体数据来证实（我曾经亲眼见到第二种情况的发生），否则就应更加深

入全面地分析第一个推断。虽然拜占庭故障（Byzantine Failures）是J2EE系统更容易出现的

故障模式，但却不要因此丧失您的判断力（即测试应从更为简单的推断开始）。

■ 日志文件中没有错误不表示错误不曾发生。出于很多原因异常未被写入日志，比如可能

由于程序员认定某些状况“永远不会发生”而忽略了那些异常状况；也可能是由于某个组

件的自动故障恢复机制，因而第一次故障未被记录。

图7.1 某电信应用系统的“费用

发生查询”操作，图中是单次操作

的追踪视图。

总耗时26秒，98%的时间是在做

SQL查询，看似数据库缓慢。

图7.2 实际上，统计这单个查

询，发现数据库操作有338次，平

均每次都不慢。

问题是在程序设计不合理，访问要

求过分频繁，属于典型的“千刀万

剐”现象。

诊断示例

示例分析一、您的应用程序呈现出的故障征兆是：系统运行随负载的增加越发缓慢。用户

叠加的数量越多，系统运行速度就越慢。负载退出后，系统便自行恢复正常运行状态，而

无任何副作用。通过评估这一早期故障征兆，查找结果如下（时间测量值是指单个典型事

务处理的端到端完成时间）

表二、应用程序性能随负

载的增加逐渐下降 负载（用户数） 来回时间（毫秒）

10 300

50 471

100 892

150 1067

您可由此稍作推测：也许这一故障现象可归咎于某个包含编码缺陷的组件，或者某个后台

系统的系统瓶颈，又或者是由一个同步阻塞点所导致。您能够分辨它们的不同吗？假定你

也同时测量了负载状况下应用服务器的CPU总体使用率，结果如下

表三、问题看来是一个

“等待”瓶颈 负载（用户数） 来回时间（毫秒） CPU总体使用率(%）

10 300 30

50 471 33

100 892 37

150 1067 41

看来系统并不是CPU密集型的，这就是说系统白白浪费掉大量等待时间。但这是来在内部

（如同步通信阻塞）还是外部（如数据库运行缓慢）呢？假定我们又多收集了几个数据，

具体如下

表四、SQL语句运行缓慢是

问题所在吗 负载（用户数） 来回时间（毫秒） CPU总体使用率(%）

负载（用户数） 等待数据库连接的线程数 JDBC查询时间（毫秒）

10 2 58

50 3 115

100 3 489

150 4612

看来，等待数据库连接的内部瓶颈并不是问题所在。是JDBC查询本身出现了问题。不单是

JDBC查询时间随事务处理的总体时间而变化，其性能的降低还能够解释整体性能下降的大

部分原因。至此为止，我们的工作尚未完成。您还有三个主要推断有待筛选：数据库本身

是否运行缓慢；应用程序是否有不合理的数据库访问要求；应用程序与数据库间的某个桥

接层是否出现问题。借助于数据库厂商提供的专用工具，从该角度查看响应时间。您希望

获取的数据如下

表五、实际原因是数据库中的SQL

语句执行慢 负载（用户数） JDBC查询时间（毫秒） 数据库SQL的实际运行时间（毫秒）

10 58 43

50 115 97

100 489 418

150 612 589

如果并未查看到上述数据，您则需要重新着手分析JDBC驱动程序，希望能够从中发现某类

同步问题（需要注意的是CPU并无崩溃）。所幸的是，在本例中您已经把具体问题界定到

某个数据库查询。确定查询要求是否合理，需要具备该领域的专业知识，需要对系统很熟

悉。在本例中您却只需通过将一个无索引域查询与一个外来码查询相比较，就成功诊断了

问题。您还能够与数据库管理员并肩作战，通过他来修改索引模式，以提高查询速度。至

此您已经圆满地实现了预期目标。

案例分析

某电信运营商的营销服务支撑系统，每月末高峰期持续频繁出现故障，故障表现是：用户

访问系统时处理性能缓慢，用户甚至无法连接上系统，管理员在一天内被迫多次重启应用

系统。

在此期间，各个系统指标并无异常表现。因此，可以判断故障的原因不在系统硬件和软件

上，而可能是应用程序或当时的环境导致。但由于业务系统的复杂性和不可见，难以定位

故障的原因。

部署CA|Wily Introscope监控软件后，通过实时组件监控功能，监控到故障发生时，查询

ADSL用户业务“qryADSLUserAction.do”性能不理想，有12笔此业务同时超过30秒（如图

9.1所示）。

图9.1 “Stalls”代表延时，缓

慢。

图中表示qryADSLUserAction.do业

务同时有12笔缓慢。

同时缓慢的一个后果是线程被长期占用。系统访问高峰时，线程会被全部用尽却来不及释

放，造成系统无法接受新的访问请求。

通过交易追踪功能（Introscope Transaction Trace），追踪单个缓慢的业务，发现每个慢交易

的时间都超过300秒，而原因是一条SQL语句缓慢（这条语句占了每笔交易99%的时间），

具体见下图9.2：

图9.2 缓慢的原因是下面这条

SQL查询语句

至此，我们已经根据常规的理论，初步诊断出问题的根源。此时，千万不要被小小胜利蒙

蔽眼睛。生产环境出现的棘手问题，往往不是简单问题，这个案例中也是如此。（这种情

况下，知识库中的专家意见往往效果甚微。）

我们查看Introscope对这条SQL的性能记录，发现这条语句在当时的响应时间稳定在300秒

左右（图9.3）：

图9.3 那条缓慢SQL语句的历史

统计曲线图，响应时间连续稳定在

300秒

如此稳定的缓慢，让我们怀疑它们做的是相同的查询（即查询参数都相同）。于是我们

再次检查那12笔缓慢的交易细节，果然发现这12笔是同一个用户的、多次相同的操作（图

9.4）。

图9.4

我们在测试环境找到了这一操作，验证后发现用户确实可以对此业务的“按钮”点击多

次，从而出现多次提交。

至此，我们可以对这次的问题作一个“案情分析”：用户点击此业务“按钮”后发现很

慢，于是疯狂点击，以为多按几次响应会加快（请不要觉得奇怪，这是前台业务员和一般

用户对应用系统的理解）。结果应用服务器这边出现多个重复的线程在工作，在月末使用

高峰期间，多几个“疯狂”的业务员，就可以把整个应用系统堵塞一段时间（实事正是如

此）。优化SQL性能和技术上禁止多次提交（让按钮在一次点击后失效）是合适的对策。

结束语

诊断J2EE应用程序的性能瓶颈会是一个艰难的过程。运用你的智慧，深入推测以探寻事实

真相，以确凿的证据来确认您的假设。本文通过对分类标准的有益尝试，引导您进一步深

入思考和实践探索。就如同进入调试阶段，如同经过玄思冥想方能修炼成功的魔法，慎思

明辨才是带您走出困境的唯一途径。

关于CA Wily最佳实践

CA Wily产品事业部一贯信守对客户的承诺。成功购买CA软件产品并不是CA 优质服务的中

止。在部署Introscope的各个阶段，通过CA支持人员随时随地的沟通与协助、专业培训计

划以及创新性的CA Wily最佳实践，与客户建立良好的伙伴关系。CA为客户提供可下载的

J2EE性能管理和Introscope相关文件。通过“CA Wily最佳实践”相关文献与客户和合作伙伴

共享CA 先进的知识经验。如果您对这份“最佳实践”文献中的任何信息存在疑问，请致电

CA中国 +86 10 65611136，或者登录www.ca.com.cn查询。

相同的Session，不

同的线程号，说明

同一个用户多次点

击提交这个请求。

居然提交了12次

CA Wily服务承诺

CA Wily不但拥有性能卓越的软件产品，还同时提供专业服务和培训计划，以协助客户与合

作伙伴成为世界级的 Java应用程序管理者。获取CA Wily所提供的客户服务的更多相关信

息，请即刻与我们联系。

专业服务

CA Wily 的专业服务人员作为Java应用程序管理最佳解决方案领域的专家，广为业界称道。

通过与全球众多企业组织的IT 团队紧密合作，将其经验成功运用于实际生产作业，全面提

升应用程序的性能和可用性。

培训计划

Wily培训计划提供入门级和高级培训课程，协助企业员工全面了解CA Wily的相关知识以及

各行业的最佳监控方案等方面内容。CA定期提供两种形式的培训课程：教室现场授课和虚

拟教室培训，同时为企业提供上门培训。有关现场培训的相关事宜敬请与我们联系。通过

www.wilytech.com/services/education.html 下载信息手册，或者致电

欲详细了解CA Wily技术公司如何帮助转化业务，请访问 wilytech.com。

CA中国北京市朝阳区光华路1号

北京嘉里中心南楼11层

邮编：100020

电话：86-10-65611136

传真：86-10-65611135

上海办事处上海市南京西路038号

梅龙镇广场1801

邮编：200041

电话：86-21-62185578

传真：86-21-62185567

广州办事处广州市天河体育东路138号

金利来数码网络大厦2902-2908室

邮编：510620

电话：86-20-38781212

传真：86-20-38781262

技术支持中心（售后）：4008100670

如需了解更多信息，请登录www.ca.com.cn

Copyright © 2006 CA. All Rights Reserved. One CA Plaza, Islandia, N.Y. 11749. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.