【WebLogic故障处理】一次严重的WebLogic内存泄漏问题处理过程
问题描述最近应用服务器WebLogic服务每天均出现多次宕机情况，严重影响业务的使用

目的：由于某些原因，开发商不能修改程序，本次主要降低宕机频繁，保障春节期间正常运行。

环境：Linux ，Sun JDK 1.4.2 SR4，WebLogic Server 8.1.3（两台）

问题分析及处理

1、Weblogic线程超时

日志中经常出现与数据库相关的线程运行时间超过10分钟或30分钟而且超时，这种情况对数据库SQL语句进行优化处理后正常。

2、WebLogic JVM内存泄漏

主要表现为程序中存在许多对象占用内存不能被回收，特别是大对象，导致频繁FULL GC垃圾回收，而每次垃圾回收后又不能清理这些对象而回收占用空间，则系统的响应时间则越长，当新对象多次申请空间时又不能满足需求，最终出现内存溢出而WebLogic宕机。
如下图，其中(a),(b),(c)均是使用XXXX页面期间产生的3个线程（189,193,194）占用情况，WebLogic自身及其它对象使用只占用了140M。
此问题经过多次分析，均是由XXXX页面的访问引起。

3、应用服务器CPU占用比较高

经检查，发现占用CPU高的进程主要是Java进程，即WebLogic Server运行进程，通过分析JDK GC日志，发现在GC垃圾回收占用系统资源严重，而FULL GC垃圾回收又是整个垃圾回收的重点，而每次FULL GC垃圾回收都是对那些在年轻代区域中不能被回收的对象进行回收。
同时结合观察， 未进行FULL GC时，系统的CPU使用正常，但每次在FULL GC期间，系统CPU都在高位，说明CPU高与FULL GC垃圾回收有关，而FULL GC垃圾回收则是类似上图中的占用JVM内存较多的大对象。

首先解决运行环境的问题

针对以上内存溢出和CPU的问题，首先从运行环境中寻找其解决方案。
1、
升级WebLogic 8.1版本由SP3到SP6
2、
升级SUN jdk1.4.2 SR4到SUN jdk 1.4.2 SR19
//备注：在JDK每一个新版本都解决了这前版本许多的BUG，其中包含由JDK本身而引起的的JVM Crash、Thread Lock、CPU High等关键问题。
经过以上处理及JDK运行参数的调整后，对业务进行了压力测试，当单节点并发用户在80个以上同时运行了20多分钟，数据库的CPU达到100%时，而且WebLogic进程占用CPU情况较正常，但越到最后，CPU使用情况就比较糟糕了，但最终未出现宕机情况，此时观察GC垃圾回收日志，主要表现为FULL GC频繁。

下载次数:5
2010-2-21 18:29

再次处理环境外的问题
根据分析FULL GC频繁的原因主要表现为大对象不能被回收，出现内存溢出，如附图中的状况。

内存溢出问题是目前应用服务器宕机的普通表现，其彻底解决办法，也只能修改程序，调整相关参数只能起到缓解的作用。

根据多次观察及分析GC日志，根据目前32位环境的情况，目前JVM参数配置如下：

[list=1]
[*]-XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime

[*]-XX:+PrintGCApplicationConcurrentTime -Xms768m -Xmx1024m -XX:NewSize=512m -XX:MaxNewSize=512m

[*]-XX:NewRatio=2 -XX:SurvivorRatio=4 -XX:PermSize=128m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=20 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=13 -XX:+CMSPermGenSweepingEnabled -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection

[*]-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnable

根据春节期间连续9天未宕机的运行情况分析，结果如下：

9天的普通GC垃圾回收共计29,136次，平均间隔时间为23.4秒进行一次，每次普通GC垃圾回收时间平均为0.7秒；
9天的FULL GC垃圾回收共计2,313，平均间隔时间为2.2秒进行一次，每次FULL GC垃圾回收时间平均为1.3秒，这个还是比较严重；

根据结果分析，虽然通过调整使目前环境相比之前的环境会稳定一点，但根本的问题还是存在。

Number of Full Garbage Collections : 2,313
Number of Minor Garbage Collections : 29,136
Average Full Garbage Collection interval : 2,268 milliseconds
Average Minor Garbage Collection interval : 23,408 milliseconds
Average Full Garbage Collection duration : 1,324 milliseconds
Average Minor Garbage Collection duration : 733 milliseconds

处理结果
根据本次的处理，保障了XXXX业务系统在春节期间不宕机的正常运行。

经过多次分析及跟踪，宕机问题主要原因是因为程序中存在内存泄漏问题，而泄漏位置主要是XXXXX这个页面访问。

建议
1、 建议开发商修改程序XXXXX并。