[quote]原帖由 [i]mfkqwyc86[/i] 于 2010-10-26 20:49 发表 [url&＃61;http://www.itpub.net/redirect.php?goto&＃61;findpost&pid&＃61;16646868&ptid&＃61;1361828][img]http://www.itpub.net/images/common/back.gif[/img][/url]
问题描述
最近应用服务器WebLogic服务每天均出现多次宕机情况&＃xff0c;严重影响业务的使用
目的&＃xff1a;由于某些原因&＃xff0c;开发商不能修改程序&＃xff0c;本次主要降低宕机频繁&＃xff0c;保障春节期间正常运行。
环境&＃xff1a;Linux &＃xff0c;Sun JDK 1.4.2 SR4&＃xff0c;WebLogic Server 8.1.3(两台)
问题分析及处理1、
Weblogic线程超时
日志中经常出现与数据库相关的线程运行时间超过10分钟或30分钟而且超时&＃xff0c;这种情况对数据库SQL语句进行优化处理后正常。
1、
WebLogic JVM内存泄漏
主要表现为程序中存在许多对象占用内存不能被回收&＃xff0c;特别是大对象&＃xff0c;导致频繁FULL GC垃圾回收&＃xff0c;而每次垃圾回收后又不能清理这些对象而回收占用空间&＃xff0c;则系统的响应时间则越长&＃xff0c;当新对象多次申请空间时又不能满足需求&＃xff0c;最终出现内存溢出而WebLogic宕机。
如下图&＃xff0c;其中(a),(b),(c)均是使用XXXX页面期间产生的3个线程(189,193,194)占用情况&＃xff0c;WebLogic自身及其它对象使用只占用了140M。
此问题经过多次分析&＃xff0c;均是由XXXX页面的访问引起。
页面附图&＃xff1a;内存泄漏.gif
1、
应用服务器CPU占用比较高
经检查&＃xff0c;发现占用CPU高的进程主要是Java进程&＃xff0c;即WebLogic Server运行进程&＃xff0c;通过分析JDK GC日志&＃xff0c;发现在GC垃圾回收占用系统资源严重&＃xff0c;而FULL GC垃圾回收又是整个垃圾回收的重点&＃xff0c;而每次FULL GC垃圾回收都是对那些在年轻代区域中不能被回收的对象进行回收。
同时结合观察&＃xff0c; 未进行FULL GC时&＃xff0c;系统的CPU使用正常&＃xff0c;但每次在FULL GC期间&＃xff0c;系统CPU都在高位&＃xff0c;说明CPU高与FULL GC垃圾回收有关&＃xff0c;而FULL GC垃圾回收则是类似上图中的占用JVM内存较多的大对象。
Oslash;
首先解决运行环境的问题
针对以上内存溢出和CPU的问题&＃xff0c;首先从运行环境中寻找其解决方案。
1、
升级WebLogic 8.1版本由SP3到SP6
2、
升级SUN jdk1.4.2 SR4到SUN jdk 1.4.2 SR19
//备注&＃xff1a;在JDK每一个新版本都解决了这前版本许多的BUG&＃xff0c;其中包含由JDK本身而引起的的JVM Crash、Thread Lock、CPU High等关键问题。
经过以上处理及JDK运行参数的调整后&＃xff0c;对业务进行了压力测试&＃xff0c;当单节点并发用户在80个以上同时运行了20多分钟&＃xff0c;数据库的CPU达到100%时&＃xff0c;而且WebLogic进程占用CPU情况较正常&＃xff0c;但越到最后&＃xff0c;CPU使用情况就比较糟糕了&＃xff0c;但最终未出现宕机情况&＃xff0c;此时观察GC垃圾回收日志&＃xff0c;主要表现为FULL GC频繁。
内存泄漏.GIF (13.2 KB)
下载次数:5
2010-2-21 18:29
http://bbs.weblogicfans.net/attachments/month_1002/1002211829e93467e885f679bf.gif
本帖最后由 chaowang 于 2010-2-21 19:01 编辑
再次处理环境外的问题
根据分析FULL GC频繁的原因主要表现为大对象不能被回收&＃xff0c;出现内存溢出&＃xff0c;如附图中的状况。
内存溢出问题是目前应用服务器宕机的普通表现&＃xff0c;其彻底解决办法&＃xff0c;也只能修改程序&＃xff0c;调整相关参数只能起到缓解的作用。
根据多次观察及分析GC日志&＃xff0c;根据目前32位环境的情况&＃xff0c;目前JVM参数配置如下&＃xff1a;
[*]-XX:&＃43;PrintGCTimeStamps -XX:&＃43;PrintGCDetails -XX:&＃43;PrintGCApplicationStoppedTime
[*]-XX:&＃43;PrintGCApplicationConcurrentTime -Xms768m -Xmx1024m -XX:NewSize&＃61;512m -XX:MaxNewSize&＃61;512m
[*]-XX:NewRatio&＃61;2 -XX:SurvivorRatio&＃61;4 -XX:PermSize&＃61;128m -XX:MaxPermSize&＃61;256m -XX:MaxTenuringThreshold&＃61;20 -XX:&＃43;DisableExplicitGC -XX:&＃43;UseConcMarkSweepGC -XX:&＃43;UseParNewGC -XX:ParallelGCThreads&＃61;13 -XX:&＃43;CMSPermGenSweepingEnabled -XX:&＃43;CMSParallelRemarkEnabled -XX:&＃43;UseCMSCompactAtFullCollection
[*]-XX:&＃43;UseFastAccessorMethods -XX:&＃43;UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction&＃61;70 -XX:&＃43;CMSParallelRemarkEnabled
根据春节期间连续9天未宕机的运行情况分析&＃xff0c;结果如下&＃xff1a;
9天的普通GC垃圾回收共计29,136次&＃xff0c;平均间隔时间为23.4秒进行一次&＃xff0c;每次普通GC垃圾回收时间平均为0.7秒&＃xff1b;
9天的FULL GC垃圾回收共计2,313&＃xff0c;平均间隔时间为2.2秒进行一次&＃xff0c;每次FULL GC垃圾回收时间平均为1.3秒&＃xff0c;这个还是比较严重&＃xff1b;
根据结果分析&＃xff0c;虽然通过调整使目前环境相比之前的环境会稳定一点&＃xff0c;但根本的问题还是存在。
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
处理结果
根据本次的处理&＃xff0c;保障了XXXX业务系统在春节期间不宕机的正常运行。
经过多次分析及跟踪&＃xff0c;宕机问题主要原因是因为程序中存在内存泄漏问题&＃xff0c;而泄漏位置主要是XXXXX这个页面访问。
建议
1、 建议开发商修改程序XXXXX并。 [/quote]
来自 “ ITPUB博客 ” &＃xff0c;链接&＃xff1a;http://blog.itpub.net/15797451/viewspace-1422369/&＃xff0c;如需转载&＃xff0c;请注明出处&＃xff0c;否则将追究法律责任。
京公网安备 11010802041100号