WebSphere 内存泄漏 Java虚拟机收藏 (2)
Java, WebSphere, 机收, 泄漏
直到现在，系统一直运行平稳。
先说说我接手这项工作的经历吧：该项目大部分是06年10月就部署在客户那边了，到07年3月份，WAS宕机问题实在无法忍受，我才加入进来，前半年有另外一位同事断断续续处理，但对问题一直都无可奈何，而且项目负责人也没有引起足够的重视。可想而知，最后付出的代价是非常惨重的。在这近半年的时间内，服务器宕机63次。每次宕机时，WAS的JVM会dump出一个heapdump.phd文件(heap快照)，然后JVM就死掉了，当然，此时WAS也停止了响应。一般我们的做法是重启，最后是干脆AIX每天晚上定时重启。有时候一天还死多次。大家见附件的截图（all-GC.png）。这是我接手后，用IBM的分析工具得到的截图。对截图的分析，留给后面对应的部分吧。
服务器不稳定、宕机问题，拖延到最后，客户愤怒了，公司高层也害怕了，部门还专门成立了八人攻关组。当然了，我当时的压力也非常大，因为我是技术负责人，也就是实实在在干活、想主意的。
服务器诊断那段时间，从前到后，我们也是沿着一条线走下来，虽然最后发现很多路都走不通。现在就按这个思路，也就是时间先后一步步叙述吧。我想，大家如果也碰到类似应用服务器诊断，应该思路差不多。
术语说明：
IBM Websphere Application Server：WAS，WebSphere本身是一个平台，产品家族 OutOfMemoryError：OOM，内存泄漏，内存溢出 Gabage Collection：GC，自动垃圾回收
Content Management System：CMS，就是给新闻类门户网站编辑们用的系统
我们诊断大体上经历了以下几个阶段：
1、按Job调度线程池引起内存泄漏诊断：因为很多次OOM是发生在某个特定时候，譬如14：30、22：40左右。
2、按应用程序引起内存泄漏诊断：用JProfiler等工具探测：因为总是发生OOM。 3、分离WAS怀疑有OOM的应用：因为每个WAS应用太多，20来个，混一起没法定位。
4、用IBM官方heap、GC分析工具。以及和IBM技术支持联系。WAS、AIX参数优化。
5、隔离出WAS超级恶魔程序：一个CMS产品。 6、WAS、AIX参数优化、设置。
我们走到第5步时，才出现效果。计算一下，那时已经过去一个月了。服务器宕机、系统不稳定，在这个验收的时候，客户已经忍无可忍，以致后来的每一次行动都得胆战心惊得去做。
一、按Job调度线程池导致内存泄漏诊断
因为从我们WAS的日志(默认是native_stderr.log)来看，最近半年的宕机时间都有一个明显时间规律。见附件截图Job1-1.png。
我想，做过Java服务器性能调优的朋友，都知道在Web容器里面启线程池是个不太好的做法，因为Web容器本身有一个线程池，譬如Servlet线程池（Tomcat默认起25个），而自启的线程池很容易导致Servlet线程管理混乱，最终导致GC问题。我们的现象似乎和那很符合。如果我们沿着这个思路做下去，具体怎样实施呢？
我们的WAS上部署了20个左右的Web应用，譬如Lucene全文检索、B2B行业数据同步等，都是通过Quartz的Job调度做的，当然还有很多其它调度。当时，由我负责，通知相关负责人，将定时调度暂时去掉。观察了几天，后来发现问题依然存在，不过时间有点随机了。
不过，最后还是发现OOM不是由Job调度引起的。
也就是说，我们这个方案是 失败的。而且，我们的很多想法都是臆测的，没有可靠的根据，也没有方向，再加上我是第一次处理这种问题，这导致后来查找问题的艰难。但是，仔细想想，我们 又能拿什么做依据呢？出现OOM错误，我想大多数人想到的，除了JVM参数设置，就是内存泄漏。其实，OOM发生有很多种情况，在IBM、Sun、BEA 等不同虚拟机上，因为GC机制不一样，所以原因一般都不同，容易定位难度也不一样。下文会谈到。
于是，我们干脆釜底抽薪分析问题吧：用JProfiler检测。
二、按应用程序导致内存泄漏诊断，JProfiler检测
如果遇到OOM问题，我想大家都会想到内存检测工具，现在最可靠的还是下面三种分析工具：Borland 的Optimizeit Suite，Quest的JProbe，ej-technologies的JProfiler。但面临三个问题：
1、三个都是商业产品，公司暂时没有买，必须自己下载，而且要找序列号。 2、工具必须支持AIX5.3＋JDK1.42＋WAS6.0，不是Windows平台。
3、工具必须在客户真实环境下部署，对客户的业务不能有冲击，也就是说部署测试工具前，必须做个大量测试，对工具非常熟练，遇到意外可以立即恢复现场。
Note:项目上线后，而不是测试或试运行阶段遇到此类问题，非常考验人；另外一个，就是性能和可伸缩性问题，很可能把整个项目给毁了。
当我决定要这么做后，就立即动手查阅这些工具的官方文档，用emule下载，最终都下载到了。试用后，最终选择了JProfiler4.03，比起其它工 具，它界面美观、清晰、功能强大、集成度高(Heap,Memory,CPU,Thread都统一了)。另外，JProbe没有AIX版本，这也是放弃它 的一个原因。
JVM的Profiler原理，都是通过JVM内置的的标准C语言Profiler 接口收集数据，然后通过Profiler工具的客户端展 现。也就是说各厂商的Profiler工具，都有两个部分，一个部分是Profiler Agent，和JVM绑定，负责收集JVM内部数据，譬如方法调用次数、耗费时间等；另外一个部分就是Profiler front-end。通过Profiler工具的自定义local或remote协议传输到front-end，其实，我们最常用的JavaIDE的 debug功能就是在此基础上的
（JPDA）。（JProfiler的截图http://www.ej-technologies.com/p ... er/screenshots.html ）。
下面是Sun官方文档：
JDK1.42及以前是JVM PI：http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/jvmpi.html JDK1.5是JVM TI：http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html 具体到JProfiler的配置上，专门针对JDK1.4和1.5的JVM配置差别很大。
我用的JProfiler是4.31版本，透露给大家一个万能序列号吧(这东西不太好找)，对各版本应该都支持。深入了解Java，这类工具是不可少的： Name: License for You
Lincese Code: A-G667#42616F-10kg1r134fq9m#2217
为了保证真实环境的检测成功，我做了大量的试验，譬如： 1、Windows系列的本地、远程测试。 2、AIX的远程测试。
3、Tomcat5.0、WebLogic8.14、WebSphere6.02，以及上述两种方式的组合测试，排列组合，场景不下10个。
当时也参阅了大量JVM文档，JProfiler官方几百页英文文档，辅助的JProbe对照。而且也制造过内存泄漏造成的OOM场景。
当然，要是在几个月前，在客户那边部署的测试环境时，就进行测试该多好啊。 相关主题推荐
? ? ? ? ? ? ? ? ?
WebSphere Application Server 中的内存泄漏检测与分析(2) WebSphere Application Server 中的内存泄漏检测与分析(1) WebSphere配置JSP泄漏漏洞
IBM WebSphere配置JSP泄漏漏洞
WebSphere Application Server 中的内存泄漏检测与分析: 第 2 部分(1) WebSphere应用服务器内存泄漏探测与诊断工具选择最佳实践(1) WebSphere Application Server 中的内存泄漏检测与分析: 第 1 部分(1) WebSphere应用服务器内存泄漏
WebSphere JVM classloader 内存泄漏
本主题由 olivia 于 2012-7-17 09:09 移动
2#
二星级会员 52055687发表于 2008-2-29 17:15 | 只看该作者
在 公司内部，我用JProfiler测试了我们当时部署的几个应用，没有发现内存泄漏，所以，我们最怀疑的是就是CMS系统。因为出问题的那个WAS上它占 去了90％的负荷（我们有多台AIX、WAS服务器）。该CMS超级庞大，感觉著名的赛迪网就用它，当时该CMS厂商给我们部署都花了快一个月。所以再重 新部署一套测试环境也挺困难。另外，CMS提供商不给lisence。现在测试，客户早就对我们恼火了，当然不怎么配合，这对我们工作的开展就有很大的挑 战。
在大致可以确定万无一失的情况下，我们最终决定在客户的真实环境下测试。也