Weblogic常见问题解决方案.docx

《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