【WebLogic故障处理】一次严重的WebLogic内存泄漏问题处理过程

教程发布:风哥 教程分类:ITPUX技术网 更新日期:2022-02-12 浏览学习:1212

【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并。

本文标签:
网站声明:本文由风哥整理发布,转载请保留此段声明,本站所有内容将不对其使用后果做任何承诺,请读者谨慎使用!
【上一篇】
【下一篇】