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

核心提示： 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，为了考虑到对

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 文件后，迅速定位了问题，终于柳暗花明，这种喜悦是难以言表的。

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

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