查看: 8288|回复: 0

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

[复制链接]
认证徽章
论坛徽章:
5
2011新春纪念徽章
日期:2011-02-18 11:43:35ITPUB十周年纪念徽章
日期:2011-11-01 16:23:26ITPUB 11周年纪念徽章
日期:2012-10-09 18:08:152013年新春福章
日期:2013-02-25 14:51:24优秀写手
日期:2013-12-18 09:29:09
发表于 2010-10-26 20:49 | 显示全部楼层 |阅读模式
问题描述


最近应用服务器WebLogic服务每天均出现多次宕机情况,严重影响业务的使用


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


环境:Linux ,Sun JDK 1.4.2 SR4,WebLogic Server 8.1.3(两台)

问题分析及处理
1、
Weblogic线程超时

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


1、
WebLogic JVM内存泄漏

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


页面附图:内存泄漏.gif

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

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


Oslash;
首先解决运行环境的问题

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





本帖最后由 chaowang 于 2010-2-21 19:01 编辑

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

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

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


  • -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:+CMSParallelRemarkEnabled

复制代码
根据春节期间连续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并。

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

DTCC2020中国数据库技术大会 限时9.5折

【架构革新 高效可控】2020年8月17日~19日第十一届中国数据库技术大会将在北京隆重召开。

大会设置2大主会场,20+技术专场,将邀请超百位行业专家,重点围绕数据架构、AI与大数据、传统企业数据库实践和国产开源数据库等内容展开分享和探讨,为广大数据领域从业人士提供一场年度盛会和交流平台。

http://dtcc.it168.com


大会官网>>
TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表