使用 IBM 性能分析工具解决生产环境中的性能有关问题

使用 IBM 性能分析工具解决生产环境中的性能问题

个人感觉 HeapAnalyzer 给出的分析结果可读性不强，而且不能准确定位问题，从分析结果看大致是因为加载的对象过多，但是是哪个模块导致的问题就跟踪不到了。笔者开始寻找 HeapAnalyzer 分析结果相关的资料，试图从这个可读性不强的结果中找到蛛丝马迹，可是许久没有进展，再一次陷入了困境。

?

在多次研究 heapdump 文件无果的情况下，笔者开始逐渐将注意力转移到 javacore 文件上，虽然它比较小，说不定内藏玄机呢。通过多方搜寻，找到了 IBM Thread and Monitor Dump Analyzer for Java（以下简称 jca）—— A tool that allows identification of hangs, deadlocks, resource contention, and bottlenecks in Java threads。通过它自身的这段描述来看，这正是笔者所需要的好工具。

?

这个工具的使用和 HeapAnalyzer 一样，非常容易，同样提供了详细的 readme 文档，这里也简单举例如下：

?

笔者直接在生产环境下直接通过它对产生的 javacore 文件进行分析，令人惊喜的是，其分析结果非常明了，笔者心头的疑云在对结果进行进一步分析核实后也渐渐散去。

图 3. jca 对 javacore.20090602.134015.430370.txt 的分析结果 —— 第一部分

从图中，我们可以清楚地看到引发错误的原因 —— The failure was caused because the class loader limit was exceeded。同时我们还能看出当前生产环境使用的 JRE 版本是：J2RE 5.0 IBM J9 2.3 AIX ppc-32 build j9vmap3223-20070201 ，这个 SR4 的版本有个问题，我们可以从分析结果图的第二部分的 NOTE 小节清楚地看到：

图 4. jca 对 javacore.20090602.134015.430370.txt 的分析结果 —— 第二部分

NOTE: Only for Java 5.0 Service Refresh 4 (build date:February 1st, 2007) and older. When you use delegated class loaders, the JVM can create a large number of ClassLoader objects. On IBM Java 5.0 Service Refresh 4 and older, the number of class loaders that are permitted is limited to 8192 by default and an OutOfMemoryError exception is thrown when this limit is exceeded. Use the -Xmxcl parameter to increase the number of class loaders allowed to avoid this problem, for example to 25000, by setting -Xmxcl25000, until the problem is resolved.

?

原来，OOM 竟然是因为这个原因产生的。那么到底是哪里加载的对象超过了这个 8192 的限制呢？接下来笔者结合分析结果和应用系统 log 进行了进一步的分析，更加验证了 JCA 分析结果的正确性。

?

在分析结果中可以看到 Current Thread ，就是对应引起 OOM 的应用服务器的线程，使用该线程的名称作为关键字在我们的 log 里进行搜索，迅速定位到了业务点——这是一个定时的调度，其功能是按固定时间间隔以 DBLink 的方式从外部应用的数据库系统中抽取数据，通过应用层逻辑转换后保存到内网数据库系统中。应用层的逻辑是对所有的业务数据进行循环，对每条业务数据进行到 POJO 的一一对照转换，这意味这一条业务数据需要 10 几个 POJO 进行组合对照，也就是说，如果外网在指定的时间间隔内数据量稍大，就会加载大量的对象，使 JVM 的 class loaders 瞬间超过 8192 的限制，而产生 OOM 的错误，从而使内存不断被消耗，直至宕机。

?

jca 还提供了对垃圾回收和线程状态的详细分析数据，可以参考如下两图：

图 5. jca 对垃圾回收状态的分析数据


图 6. jca 对垃圾线程状态的分析数据

问题核实后，如何进行解决呢？分析结果中也给出了相应的建议，从图 4 的 Recommended 小节我们可以看到：

?

Recommended -Xmxcl setting (only for IBM Java 5.0, up to and including Service Refresh 4 (build date:February 1st ,2007)) : 10,649 or greater。

?

为了考虑到对既有旧系统不产生影响，我们没有对 JRE 进行升级，而是采用了分析结果给出的建议，在应用服务器启动后设置 -Xmxcl 参数为 25000，为验证我们的修改是不是成功解决掉了 OOM 宕机的问题，笔者取消了对应用服务器的自动重启调度，通过一段时间的监控发现，系统运行良好，一直没有再出现 OOM 而宕机的问题，问题得以最终解决。

?

总结

?

整体规划

系统上线前要做好充分的准备工作，这一点很重要，上线计划可不是拍拍脑门就能想出来的，需要很多项目成员的参与。

项目实施计划书：要包括预计实施目标，双方的实施负责人（包括 backup），协调哪些资源应该找哪些人，详细的阶段性计划等等。实施小组：指定具有实施经验的架构师，系统工程师，开发组长组成实施小组，负责生产环境的搭建及调整。成员构成上一定要包含项目组内的稳定核心人员，以保证能在特殊情况需要时做 backup。核心人员的流动会引起项目风险，尤其是在上线初期的不稳定阶段。对可规划使用的资源一定要充分利用，这一点应包含在项目实施计划书内，尽量做到资源一步到位。因为本项目案例中，旧有系统和新系统并行运行，可用的资源在不断发生变化，期间为解决性能问题，曾尝试将资源分配向新系统倾斜，以尝试是否能解决问题，这在一定程度上也会影响实施的进度。需要对核心的配置进行确认，如 JRE 版本，数据库版本等。如果我们在生产环境建立的初期，就把 JRE 升级到最新的版本，可能就避免了这次 6 个月宕机的煎熬。
压力测试

大部分具有并发需求的应用系统上线前，都要经过开发团队的压力测试，这样在试运行阶段才能心里有底。本项目案例中，由于工期过于紧张，加之其他因素，导致压力测试不够充分，虽然 OOM 的问题并不是因为并发数过多产生，但是这一环节是不可忽视的。

攻坚团队

一个拥有高度的执行力的团队一定是一个责任分明的团队。在应对突发、严重、紧急情况时，要有专门的攻坚团队来解决这类问题，这个团队应该包括项目组的核心开发人员，有较强的动手能力和研究能力，能够变通解决问题，思路开阔。他们的作用是至关重要的，往往可能决定项目的成败。

信心很重要

每一次攻坚内存泄露的问题都是一次探险之旅，需要有清醒的意识和头脑，更要凝结你的意志和信心，因为这是一个艰苦的过程。本文案例由发生至解决有半年之久，当笔者转向分析 javacore 文件后，迅速定位了问题，终于柳暗花明，这种喜悦是难以言表的。

纸上得来终觉浅， 绝知此事要躬行。

这一条不多说了，有所行，才有所得。