Weblogic常见问题解决方案.docx

上传人:p** 文档编号:755409 上传时间:2024-02-26 格式:DOCX 页数:7 大小:26.91KB
下载 相关 举报
Weblogic常见问题解决方案.docx_第1页
第1页 / 共7页
Weblogic常见问题解决方案.docx_第2页
第2页 / 共7页
Weblogic常见问题解决方案.docx_第3页
第3页 / 共7页
Weblogic常见问题解决方案.docx_第4页
第4页 / 共7页
Weblogic常见问题解决方案.docx_第5页
第5页 / 共7页
Weblogic常见问题解决方案.docx_第6页
第6页 / 共7页
Weblogic常见问题解决方案.docx_第7页
第7页 / 共7页
亲,该文档总共7页,全部预览完了,如果喜欢就下载吧!
资源描述

《Weblogic常见问题解决方案.docx》由会员分享,可在线阅读,更多相关《Weblogic常见问题解决方案.docx(7页珍藏版)》请在第壹文秘上搜索。

1、1. WebLOgiC频繁宕机故障处理环境描述AIX5308WebLogic9.2MP3集群(6应用节点,1管理节点,1集群分发节点)JDK:IB町ava564-bitJDK(ServiceRefreshSR6b+IZ08455)JVM:-Xms2048M-Xmx2048MPatchID:NGZ8PerformancePack:servernativeaixppc64libmuxer.so系统使用过程中,平均每一个月至少宕机一次,表现为WebLogiC服务节点呈挂死现象,业务系统不能使用,只能重启服务节点后系统方能使用,并且在业务系统使用过程中,速度达不到理想的效果。故障分析1、WebLOgi

2、C服务节点挂机现象,经检查WebLogiC日志,发现在服务节点挂机之前有出“javalangOUtOfMemOryElTor”等报错,同时domains目录下也生成有javacoresheapdump等文件。JVM内存使用情况*WARNING*Javaheapisalmostexhausted:0%freeJavaheapDumpEventsysthrow”(00040000)Detail,zjavalangOutOfMemoryError,zreceivedFreeJavaheapsize:9,664bytesAllocatedJavaheapsize:4,294,967,296bytes目

3、前分配给Server的4G内存已全部使用,但又未得到新的内存,出现了OutOfMemoryError线程使用情况:从线程使用情况看,只有个别线程正在运行,其它线程均在等待或被阻塞。而运行的线程正在进行数据据访问操作检查内存使用情况:在重新调整JVM为IG的情况下,分析了内存再次溢出的DUMP文件,从下图看出有存内存泄漏问题,而且情况较为严重,一个ClaSS共消耗内存670M,这个泄漏对象当前正在进行JDBC数据访问操作。在JVM为IG的条件下,根据分析结果表明,目前内存泄漏问题主要表现在两个地方:1)对象com.XXXX.XXXX.XXXX.XXXX.model.DefectQueryVO此对

4、象分别创建了36414次、1239307次。2)一系列JDBC操作,这个操作说明在进行数库访问、数据交换。因此已建议开发商软件工程师检查程序并进行优化。故障处理结果将相应的表进行分区处理,优化了数据库,后来使用正常。2. WebLogicJVM内存泄漏主要表现为程序中存在许多对象占用内存不能被回收,特别是大对象,导致频繁FULLGC垃圾回收,而每次垃圾回收后又不能清理这些对象而回收占用空间,则系统的响应时间则越长,当新对象多次申请空间时又不能满足需求,最终出现内存溢出而WebLOgiC宕机。其中(a),(b),(c)均是使用XXXX页面期间产生的3个线程(189,193,194)占用情况,We

5、bLogic自身及其它对象使用只占用了140M)此问题经过多次分析,均是由XXXX页面的访问引起。3、应用服务器CPU占用比较高经检查,发现占用CPU高的进程主要是JaVa进程,即WebLogiCSerVer运行进程,通过分析JDKGC日志,发现在GC垃圾回收占用系统资源严重,而FULLGC垃圾回收又是整个垃圾回收的重点,而每次FULLGC垃圾回收都是对那些在年轻代区域中不能被回收的对象进行回收。同时结合观察,未进行FULLGC时,系统的CPU使用正常,但每次在FULLGC期间,系统CPU都在高位,说明CPU高与FULLGC垃圾回收有关,而FULLGC垃圾回收则是类似上图中的占用JVM内存较多

6、的大对象。Oslash;首先解决运行环境的问题针对以上内存溢出和CPlJ的问题,首先从运行环境中寻找其解决方案。1、升级WebLogic8.1版本由SP3到SP62、升级SUNjdkl.4.2SR4到SUNjdk1.4.2SR19备注:在JDK每一个新版本都解决了这前版本许多的BUG,其中包含由JDK本身而引起的的JVMCrash、ThreadLock、CPUHigh等关键问题。经过以上处理及JDK运行参数的调整后,对业务进行了压力测试,当单节点并发用户在80个以上同时运行了20多分钟,数据库的CPU达到100%时,而且WebLogic进程占用CPU情况较正常,但越到最后,CPlJ使用情况就比

7、较糟糕了,但最终未出现宕机情况,此时观察GC垃圾回收日志,主要表现为FULLGC频繁。再次处理环境外的问题根据分析FULLGC频繁的原因主要表现为大对象不能被回收,出现内存溢出,如附图中的状况。内存溢出问题是目前应用服务器宕机的普通表现,其彻底解决办法,也只能修改程序,调整相关参数只能起到缓解的作用。根据多次观察及分析GC日志,根据目前32位环境的情况,目前JvM参数配置如下:-XX:+PrintGCTimeStamps-XX:+PrintGCDetails-XX:+PrintGcApplicationStoppedTime*-XX:+PrintGCApp1icatiOnConcurrentT

8、ime-Xms768m-Xmx1024m-XX:NewSize=512m-XX:MaxNewSize=512m*-XX:NewRatio-2-XX:SurvivorRatio=4-XX:PermSize=128m-XX:MaxPermSize=256m-XX:MaxTenuringThreshold=20-XX:+Disab1eExpIicitGC-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:ParallelGCThreads=IS-XX:+CMSPermGenSweepingEnab1ed-XX:+CMSParaHelRemarkEnabled-XX:

9、+UseCMSCompactAtFulIColIection*-XX:+UseFastAccessorMethods-XX:+UseCMSInitiatingccupancyn1y-XX:CMSInitiatingOccupancyFractiOn=70-XX:+CMSParaIlelRemarkEnab1ed复制代码,结果如下:9天的普通GC垃圾回收共计29,136次,平均间隔时间为23.4秒进行一次,每次普通GC垃圾回收时间平均为0.7秒;9天的FULLGC垃圾回收共计2,313,平均间隔时间为2.2秒进行一次,每次FULLGC垃圾回收时间平均为1.3秒,这个还是比较严重;根据结果分析,虽

10、然通过调整使目前环境相比之前的环境会稳定一点,但根本的问题还是存在。NumberofFullGarbageCollections:2,313NumberofMinorGarbageCollections:29,136AverageFullGarbageCollectioninterval:2,268millisecondsAverageMinorGarbageCollectioninterval:23,408millisecondsAverageFullGarbageCollectionduration:1,324millisecondsAverageMinorGarbageCollectio

11、nduration:733milliseconds处理结果根据本次的处理,保障了XXXX业务系统在短时间不宕机的正常运行。经过多次分析及跟踪,宕机问题主要原因是因为程序中存在内存泄漏问题,而泄漏位置主要是XXXXX这个页面访问。4、配置weblogic时指定jdk版本问题javax.xml.stream.FactoryConfigurationError:Providerjavax.xml.stream.XMLTnputFactorycouldnotbeinstantiated:java.lang.InstantiationExceptionatjavax.xml.stream.XMLInpu

12、tFactory.newlnstance(XMLInputFactory.java:158)atwebIogic.application,descriptor.BasicMunger2.(BasicMunger2.java:76)atweblogic,application.ApplicationDescriptorSMyApplicatiOnDescriptor.creatGXMLStreamReader(ApplicationDescriptor.java:438)atweblogic,application,descriptor.AbstractDescriptorLoader2.Cre

13、ateDescriptorBean(AbstractDescriptorLoader2.java:369)atweblogic,application,descriptor.AbstractDescriptorLoader2.IoadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:720)Truncated,seelogfileforcompletestacktrace此问题己经解决,原来是在myeclipse中jdk版本的问题,我安装的是jdkl.6,而WeblOgiC的默认版本是1.5.06,又长了一志。但是在每次配置域的时

14、候选择其它jdk版本,选择的版本比WeblOgiC的默认版本要高,报错,这可能是版本问题。5部署Web项目到WeblOgiC中,启动WebIOgiC出现异常:UnabletoloaddescriptorD:beauser_projectsdomainsbase_domain.autodeploydataSwitchingWEB-INF/web.xmlofmoduledataSwitching.Theerrorisweblogic,descriptor.DescriptorException:Unmarshallerfailedatweblogic,descriptor,internal.Mar

15、shallerFactorySl.CreateDescriptor(MarshaIlerFactory.java:147)atweblogic,descriptor.DescriptorManager.CreateDescriptor(DescriptorManager.java:280)atweblogic,descriptor.DescriptorManager.CreateDescriptor(DescriptorManager.java:248)atwebIogic.application,descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:749)原来是web.xml中web-app版本的原因,改回2.4即可tomcat向weblogic迁移注意事项!3、运行环境为:中文WindoWSXPSP2,Tomcat5.5,Weblogic9.2,JDKl.54、启动WeblOgiC报错已加锁的解决办法/base_domain/servers/AdminServer/data/store/diagnostics/WLS_DIAGNOS

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > IT计算机 > Web服务

copyright@ 2008-2023 1wenmi网站版权所有

经营许可证编号:宁ICP备2022001189号-1

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。第壹文秘仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第壹文秘网,我们立即给予删除!