JVM内存问题最佳实践

JVMBestPractice王超weblogicfans.
net站长JVM内存问题最佳实践本次技术交流,涵盖范围为:如何选择合适的Java虚拟机了解Java基本内存管理基本概念了解发生内存不足/内存泄漏错误的原因和症状了解如何诊断内存不足/内存泄漏错误了解如何解决内存不足/内存泄漏错误3MENU选择合适的Java虚拟机Java内存管理的基本概念GC次数过多消耗时间过长的原因和症状内存不足和内存泄漏错误的原因和症状诊断、定位和解决内存不足和内存泄漏错误使用分析工具解决内存不足和内存泄漏错误预防内存不足和内存泄漏OutOfMemory错误实例4Java虚拟机的种类OracleJava虚拟机–原SunJava虚拟机–原BEAJRockit–两种Java虚拟机,都运行在Windows、Linux、Solaris平台HPJava虚拟机:–与SUNJDK基本兼容,有自己独特的启动参数–运行在HPUNIX上IBMJava虚拟机:–与SunJDK基本兼容–启动参数的写法风格与SunJDK、HPJDK非常不同–主要用于WebSphere、跑在AIX上的中间件服务器开源Java虚拟机:–与SUNJDK兼容5如何选择合适的Java虚拟机选择稳定的JDK:–刚刚GA的版本不稳定,比如1.
5.
0_001.
6.
0_00–刚增加新特性的版本不稳定,比如1.
5.
0_071.
6.
0_14–安装JDK之前,先看厂商的ReleaseNotes根据平台和应用,选择合适厂商的JDK:–HP-UX只能选择HPJDK,AIX只能选择IBMJDK–Windows、Linux可以选择SUNJDK和JRockit–Solaris平台,最好使用SUNJDK–开源JDK,目前生产环境中用的极少6Java虚拟机32VS64尽量选择使用32位JDK:–32位JDK在TPS测试中,结果比64位JDK要好;JDK6.
0启用指针压缩技术后,64位略微领先32位JDK–主要适用于内存需求较小,CPU密集型应用64位JDK主要用于大内存应用:–突破4G内存限制–吞吐量并没有提高–主要用于大内存需求的系统–尽量启用指针压缩技术IBM:-XcompressedrefsSUN:-d64-XX:+UseCompressedOopsBEA:-XXcompressedRefs=true7小节回顾Java虚拟机的种类如何选择合适的Java虚拟机32bitVS64bit在本小节中,我们讲述了以下内容:8MENU选择合适的Java虚拟机Java内存管理的基本概念GC次数过多消耗时间过长的原因和症状内存不足和内存泄漏错误的原因和症状诊断、定位和解决内存不足和内存泄漏错误使用分析工具解决内存不足和内存泄漏错误预防内存不足和内存泄漏OutOfMemory错误实例9Java内存管理的基本概念Java内存–Java堆内存(heap)–Permanent区(Sun/HpJDK)Java堆内存(heap):–是JVM用于分配Java对象的内存,包含活动对象和不可用对象–堆大小通常是在服务器启动时使用java命令中的–Xms(最小)–Xmx(最大)标志来定义.
Permanent区:–是SunJDK和HPJDK用来加载类(class)的专门的内存区–这个区域不归属Java堆内存(heap)范围–如果Java应用很大,例如类(class)很多,那么建议增大这个区域的大小来满足加载这些类的内存需求–通过–XX:PermSize=***M–XX:MaxPermSize=***M调整10Java内存管理的基本概念本地内存(nativememory):–是JVM用于其内部操作的本地内存(非Java内存)–JNI代码和第三方本地模块(例如,本地JDBC驱动程序)也使用本地内存–最大本地内存大小取决于以下因素:操作系统进程内存大小限制已经指定用于Java堆的内存进程内存大小:–32位操作系统,理论最大值2的32次方=4G–64位操作系统下使用64位的JDK,按照现在的硬件条件,可以看做无限制–进程内存=Java内存+本地内存+加载的可执行文件和库+操作系统保留内存11Java内存管理的基本概念Java堆内存大小的决定因素:–进程大小限制,HPJDK-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|]]-XloggcSunJDK/BEAJrockit-verbose:gc–继续下一步–分析GC日志41分析GC日志--完整GC的输出不同的JDK将产生不同格式GC日志,以下分析以SunJDK标准GC日志为准不同的JDK有各自的其他丰富信息的GC开关选项完整GC将产生类似如下内容的消息:[memory]:GCK->K(K),ms其中:GC的开始时间(秒),从JVM启动开始计算回收前对象所使用的内存(KB)回收后对象所使用的内存(KB)回收后的堆大小(KB)执行回收的总时间(毫秒).
完整GC消息示例:[memory]7.
160:GC131072K->130052K(131072K)in1057.
359ms42分析GC日志--分析GC输出GC输出可以反映以下情况:–OOM错误是否发生在运行完整GC之后–GC返回了多少空闲空间,GC运行了多长时间–内存使用量是否增加缓慢(即表明发生了内存泄漏,通常需要观察长时间/大量的GC日志)–是否存在内存碎片–结合JVM进程内存大小,判断Javaheap内存问题还是本地内存问题43分析GC日志--确定内存问题类型基本确定内存问题类型–Java堆内存不足–本地内存泄漏不同内存问题类型,解决方案有所不同如何确定:–Java堆内存不足Java进程内存比较稳定GC日志显示,heap区内存不够,GC很频繁–本地内存泄漏GC日志显示,heap内存尚有足够空间但是Java进程却随时间一直在增长(需要长时间观察积累)44处理JavaHeapOOM错误对于JavaHeapOOM错误:–请确保启用verboseGC,也就是在启动服务器时使用java-verbosegc开关–检查OOM错误是否发生在运行了完整的GC之后–检查是否执行了内存压缩以减少内存碎片–还要留意初始(和周期)JVM堆可用性/占用率.
45针对Java堆OOM的应用程序分析如果JVM正确执行了GC,则应该是应用程序问题所致:–如果应用程序使用了缓存对象:请确保对缓存对象数量施加了限制或许可以降低缓存限值来减少总体堆大小–如果应用程序使用了活动时间长的对象,请减少这些对象的数量或缩短它们的生命周期,例如,缩短HTTP会话的超时期间–调整垃圾回收策略,可能解决OOM问题–查找内存泄漏,例如,不正确的JDBC池连接处理–如果服务器只是对负载增加或添加应用程序作出反应,JVM自然会需要更大的Heap46分析GC日志--内存缓慢增长从GC日志中看到内存的缓慢增长[GC71678K->61588K(98112K),0.
0073410secs][GC97999K->87826K(98240K),0.
0073438secs][GC190603K->170624K(191640K),0.
0196674secs][GC144325K->121582K(225376K),0.
0850580secs][GC189537K->162596K(257432K),0.
0170420secs][GC239766K->210684K(277080K),0.
0299292secs][GC246611K->208929K(359776K),0.
0172918secs]…………………47分析GC日志--内存碎片从GC日志中分析观察到内存碎片现象–这个问题多发生在IBMJDK上,因为它采用的垃圾回收算法跟别的JDK不一致(注:IBMJDKGC输入与上略有不同)–在SunJDK/HPJDK不常见,很少出现调整策略–IBMJDK:-Xcompactgc–SunJDK:增加young区大小-XX:NewRatio-XX:NewSize-XX:MaxNewSize-XX:SurvivorRatio(详细参见Sun文档)GC减少了使用的堆,其大小已与最大堆大小有明显差距,OOM却依然出现!
显示在执行GC后仍存在碎片的GC消息示例:[memory]8.
162:GC73043K->72989K(131072K)in12.
938ms[memory]8.
172:GC72989K->72905K(131072K)in12.
000ms[memory]8.
182:GC72905K->72580K(131072K)in13.
509ms.
.
.
java.
lang.
OutOfMemoryError48分析GC日志--Permanent区不够从GC日志中观察到–这个问题发生在Sun/HPJDK上,因为它采用Permanent区来存放Java的class对象–这个问题的主要区别在于两者发生的时间不一样调整策略–增加Permanent区大小–-XX:MaxPermSize=256M(推荐128M以上)OOM却依然出现!
注意这种情况主要出现在WLS启动不久,通常在1-20分钟内.
GC日志显示内存还充足[memory]8.
162:GC73043K->72989K(131072K)in12.
938ms[memory]8.
172:GC72989K->72905K(131072K)in12.
000ms[memory]8.
182:GC72905K->72580K(131072K)in13.
509ms.
.
.
java.
lang.
OutOfMemoryError49进一步分析Java堆OOM如果迄今为止所进行的分析不起作用,请使用JVM性能探查工具:–该探查工具将实现JVM事件探查器接口(JVMProfilerInterface,JVMPI),如Jprobe或OptimizeIt或者YourKit–确定占用堆的对象的类型、数量和大小–确定对象在代码中的创建位置–其用法的详细信息,请参考相应的JVM性能探查工具文档不过,JVM事件探查器通常需要较高的系统开销,因此建议一定不要在生产环境中使用!
与应用程序团队合作,查明可能存在的内存泄漏或改进对象的使用和/或生命周期状况.
50JRockit功能JRockit1.
4.
2支持Java运行时分析器(JavaRuntimeAnalyzer,JRA):–该分析器对JRockitJVM及JRockit上运行的Java应用程序都能够进行运行时性能分析.
JRA包括以下两个部分:–收集有关JVM和当前正在运行的Java应用程序的数据.
–使用分析器工具来查看收集到的信息.
执行几分钟的记录,然后对数据进行分析,以确定具体的JVM问题JRockit1.
4.
2_05的JRA支持MemoryLeak检测功能51处理本地内存OOM(1)对于本地内存OOM错误:–采用的探查方法与对Java堆OOM采用的探查方法相同:通过-verbosegc开关收集GC信息确认GC的运行合乎预期,例如,是在OOM发生前运行留意JVM堆的初始(和周期)可用性/占用率.
–定期监视进程内存大小:在Unix/Linux上,使用ps-p-ovsz或者top命令在Windows上,使用perfmon工具.
–确定是否使用了任何本地模块或JNI代码.
–还要检查计算机的物理内存总量(RAM和交换空间之和)是否足以满足所有正在运行的进程的需要52处理本地内存OOM(2)请记住,进程内存大小:–是进程运行时所占用的地址空间–受OS进程大小值的限制:32位Unix:进程大小限值为4GB,保留1-2GB供OS自己使用RedHatLinuxAS2.
1:可供应用程序使用的进程大小为3GBWindows:进程大小限值为2GB(缺省值),但可以增加到3GB–包括Java堆内存,JVM在服务器启动时会保留指定的最大值–还可能由JNI代码或本地模块(例如,本地JDBC驱动程序)进行分配–还会受计算机物理内存及计算机中运行的其它进程的限制.
53处理本地内存OOM(3)使用收集到的数据来解决OOM错误如果怀疑发生了内存泄漏,集中精力查找泄漏源–第三方代码(例如,JDBC驱动程序)或JNI代码可能会发生泄漏–排除法,不使用第三方代码–可能的情况下尝试替换纯Java实现,以确认泄漏源.
如果存在本地内存泄漏–增加物理内存,只能够延缓故障发生,无法根除问题54处理本地内存OOM(4)从GC日志中看到Heap实际使用大小远小于最大值,可以减少这个最大值,提供更多可用的本地内存如果RAM和交换空间不足,添加内存或者升级计算机JVM使用本地内存:–加载类和生成代码,但在启动几小时后,内存使用量通常会稳定下来–可能会发生运行时类加载和代码优化(JIT)–禁用JIT功能:如果使用的是JRockit,-Xnoopt如果使用的是Sun/HP的JDK,-Xint如果使用的是IBMJDK,-Djava.
compiler=NONE55处理本地内存OOM(5)最后,如果无法查明本地内存OOM错误的成因:–请与JVM供应商联系,找到跟踪本地内存分配调用的方法–请与第三方模块或JNI代码供应商联系,是否有调试/跟踪功能继续收集和分析有关OOM错误发生时间和发生原因的信息如果存在多个成因,缩小探查范围可能需要一些时间.
升级–升级JDK–升级操作系统–升级WeblogicServer56小节回顾如何识别Java内存错误和本地内存错误根据GC日志解决内存问题解决Java内存问题的步骤解决本地内存问题的步骤在本小节中,我们讲述了以下内容:57MENU选择合适的Java虚拟机Java内存管理的基本概念GC次数过多消耗时间过长的原因和症状内存不足和内存泄漏错误的原因和症状诊断、定位和解决内存不足和内存泄漏错误使用分析工具解决内存不足和内存泄漏错误预防内存不足和内存泄漏OutOfMemory/MemoryLeak错误实例58使用分析工具来分析OOM问题发生JavaHeapOOM问题时,无法定位到问题,最终的办法只能使用分析工具来做分析.
常用内存分析工具–此类工具非常多,推荐使用轻量级分析工具–YourKit-轻量级–EeclipseMemoryAnalyzer-离线分析–IBMHeapAnalyzer&MDD4J-离线分析59YourKit(1)YourKit是一款轻量级的Java运行时分析工具http://www.
yourkit.
com特性:–性能好,对生产系统造成的影响相对其他工具比较小–支持多种平台(windows/linux/mac/solaris)–支持多种JDK(理论上)–界面友好启动方式:–安装YourKit,启动并加载license–拷贝domain下的启动脚本startWebLogic.
cmd或startWebLogic.
sh,并重命名为startWLS.
cmd/startWLS.
sh–在YourKit中找到startWLS.
cmd/startWLS.
sh,得到新的启动脚本startWLS_with_yjp.
bat/startWLS_with_yjp.
sh–使用startWLS_with_yjp.
bat/startWLS_with_yjp.
sh启动weblogicserver,记住启动时YourKit在weblogicserver上得到的监听端口–在YourKit中连接到这个监听端口,并开始监控和分析weblogicserver的运行情况60YourKit(2)启动和配置YourKit123461YourKit(3)使用收集到的数据来解决OOM错误如果YourKit跟WebLogicServer本机运行,选第一项如果YourKit连接远程的WebLogicServer,选第二项需要IP和Port62YourKit(4)抓取内存镜像SnapShot,做分析63EclipseMemoryAnalyzer(1)EclipseMemoryAnalyzer原名SAPMemoryAnalyzer,后SA公司捐献给Eclipse社区,现在IBM也加入进来,是目前最实用的免费离线内存诊断工具特性:–离线分析,不影响生产系统–需要得到JDK内存镜像–支持SUN、HP(1.
4.
2_121.
5.
0_07及以后版本)–最新版本支持IBMJDK启动方式:–启动参数增加-XX:+HeapDumpOnCtrlBreak-XX:+HeapDumpOnOutOfMemoryError–Kill-3得到heapdump文件–JDK5.
0可以采用jmap-heap:format=bpidofjava–JDK6.
0可以采用jmap-dump:live,format=b,file=/tmp/xxx.
hprofpidofjava–启动EclipseMemoryAnalyzer,加载heapdump文件–图形化分析64EclipseMemoryAnalyzer(2)启动界面65EclipseMemoryAnalyzer(3)Overview视图66EclipseMemoryAnalyzer(4)LeakSuspects视图67EclipseMemoryAnalyzer(5)Dominatortree视图68EclipseMemoryAnalyzer(6)结合使用LeakSuspects和Dominatortree视图69HeapAnalyzer(1)HeapAnalyzer是一款针对IBMJDK的内存文本镜像HeapDump的分析工具特性:–离线分析,不影响生产系统–需要得到IBMJDK内存镜像–只支持IBMJDK–只能静态分析,要求得到现场数据启动方式:–Kill-3得到heapdump文件–启动HeapAnalyzer,加载heapdump文件–图形化分析70HeapAnalyzer(2)HeapDump是IBMJDKHeap内存的一个文本镜像,默认生成位置在WeblogicServer启动目录下,通常是Domain目录如果得不到HeapDump,可能是禁止生成HeapDump的生成开关–exportIBM_HEAPDUMP=true–exportIBM_HEAP_DUMP=true–exportIBM_HEAPDUMP_OUTOFMEMORY=true–exportIBM_JAVADUMP_OUTOFMEMORY=true–exportIBM_JAVACORE_OUTOFMEMORY=true–exportIBM_HEAPDUMPDIR=注意:–通常HeapDump会比较大,尤其是在Heap内存设置很大的情况下–为了重现问题,得到现场数据,建议先把HeapDump调小,推荐1G以下–在Window上,如果HeapDump大于1G,可能会无法打开,出现OOM错误–启动HeapAnalyzer需要指定-Xmx参数71HeapAnalyzer(3)启动界面72HeapAnalyzer(4)内存按树状引用关系显示73HeapAnalyzer(5)内存按对象和类型显示74HeapAnalyzer(6)找到怀疑泄漏的内存对象75HeapAnalyzer(7)内存碎片分析76小节回顾内存分析工具YourKitEeclipseMemoryAnalyzerIBMHeapAnalyzer&MDD4J在本小节中,我们学习了以下内容:77MENU选择合适的Java虚拟机Java内存管理的基本概念GC次数过多消耗时间过长的原因和症状内存不足和内存泄漏错误的原因和症状诊断、定位和解决内存不足和内存泄漏错误使用分析工具解决内存不足和内存泄漏错误预防内存不足和内存泄漏OutOfMemory/MemoryLeak错误实例78预防内存不足和内存泄漏最好的补救不如事先的预防预防内存不足和内存泄漏–系统管理–代码编写79预防内存不足和内存泄漏-系统管理系统管理–足够的物理内存,适当的Swap区大小–最佳的HEAP内存设置–使用最新的操作系统/最新的JDK/最新版本的WLS–使用WeblogicServer认证的JDK–尽量少使用第三方本地代码,或使用Java替代方案–对SunJDK,合适的Permanent区大小–适当的垃圾回收算法和策略–适当的HttpSessionTimeout时间–适当的EJBPool/Cache–适当的weblogicserver调优80预防内存不足和内存泄漏-代码编写代码编写–不要放置大量对象到Session中–不要缓存太多数据–用完的资源一定要close(),例如IO,File,JDBC连接–不要违反J2EE规范.
例如在EJB里开Socket–合理的从数据库取得适量数据–XML解析对大内存的需求–统计和报表业务的负荷问题–良好的代码习惯81小节回顾预防内存不足和内存泄漏系统管理代码编写在本小节中,我们讲述了以下内容:82MENU选择合适的Java虚拟机Java内存管理的基本概念GC次数过多消耗时间过长的原因和症状内存不足和内存泄漏错误的原因和症状诊断、定位和解决内存不足和内存泄漏错误使用分析工具解决内存不足和内存泄漏错误预防内存不足和内存泄漏OutOfMemory/MemoryLeak错误实例83OutOfMemory错误实例案例一84OutOfMemory错误实例(1)现象环境IBMAIX5.
2,JDK1.
4.
2,WeblogicServer813刚启动很好,过了一段时间,用户数上来,就发生OOM.
自动产生heapdump和javacore文件只能重启.
重启过了一段时间又是这样.
85OutOfMemory错误实例(1)问题收集什么信息86OutOfMemory错误实例(1)答案GC日志JavaCore文件分析ThreadDumpHeapDump用HeapAnalyser87OutOfMemory错误实例(1)-GC日志88OutOfMemory错误实例(1)-ThreadDump1TISIGINFOOUTOFMEMORYreceived1TIDATETIMEDate:2005/05/11at15:56:131TIFILENAMEJavacorefilename:/bea/user_projects/domains/mydomain/javacore696496.
1115798173.
txt1XHTIMEWedMay1115:56:1320051XHSIGRECVUnexpectedsignal-1receivedat0x0in.
Processingterminated.
1XHFULLVERSIONJ2RE1.
4.
2IBMAIXbuildca1420-200406262CIUSERARG-Xms1024m2CIUSERARG-Xmx1024m2CIUSERARG-verbose:gc2CIUSERARG-Xverbosegclog:/bea/gc.
log1STHEAPFREEBytesofHeapSpaceFree:45b8(17,848)1STHEAPALLOCBytesofHeapSpaceAllocated:3ffefa00(1,073,674,752)2LKREGMONHeaplock(0x30071788):owner"ExecuteThread:'0'forqueue:'weblogic.
socket.
Muxer'"(0x7BA1EC20),entrycount23LKWAITERQWaitingtoenter:3LKWAITER"ExecuteThread:'2'forqueue:'weblogic.
kernel.
Non-Blocking'"(0x7DF83CA0)3LKWAITER"ListenThread.
Default"(0x7D9D78A0)3LKWAITER"weblogic.
health.
CoreHealthMonitor"(0x7C6E3320)3LKWAITER"Thread-5"(0x7C25BC20)3LKWAITER"ExecuteThread:'2'forqueue:'weblogic.
admin.
RMI'"(0x7BD332A0)3LKWAITER"ExecuteThread:'0'forqueue:'weblogic.
admin.
RMI'"(0x7BD298A0)3LKWAITER"ExecuteThread:'2'forqueue:'weblogic.
socket.
Muxer'"(0x7BA1FEA0)3LKWAITER"ExecuteThread:'1'forqueue:'weblogic.
socket.
Muxer'"(0x7BA1F8A0)3LKWAITER"ExecuteThread:'149'forqueue:'weblogic.
kernel.
Default'"(0x7B4AE3A0)3LKWAITER"ExecuteThread:'143'forqueue:'weblogic.
kernel.
Default'"(0x7B180920)3LKWAITER"ExecuteThread:'142'forqueue:'weblogic.
kernel.
Default'"(0x7B0F8F20)3LKWAITER"ExecuteThread:'128'forqueue:'weblogic.
kernel.
Default'"(0x7A98E6A0)3LKWAITER"ExecuteThread:'127'forqueue:'weblogic.
kernel.
Default'"(0x7A906D20)3LKWAITER"ExecuteThread:'122'forqueue:'weblogic.
kernel.
Default'"(0x7A660C20)3LKWAITER"ExecuteThread:'107'forqueue:'weblogic.
kernel.
Default'"(0x79E6EA20)3LKWAITER"ExecuteThread:'100'forqueue:'weblogic.
kernel.
Default'"(0x79AB6420)3LKWAITER"ExecuteThread:'99'forqueue:'weblogic.
kernel.
Default'"(0x79A2EA20)3LKWAITER"ExecuteThread:'98'forqueue:'weblogic.
kernel.
Default'"(0x799A70A0)89OutOfMemory错误实例(1)-ThreadDump3XMTHREADINFO"ExecuteThread:'81'forqueue:'weblogic.
kernel.
Default'"(TID:0x30106330,sys_thread_t:0x790A5AA0,state:CW,nativeID:0x5B5C)prio=54XESTACKTRACEatjava.
lang.
Object.
wait(NativeMethod)4XESTACKTRACEatjava.
lang.
Object.
wait(Object.
java:443)4XESTACKTRACEatweblogic.
kernel.
ExecuteThread.
waitForRequest(ExecuteThread.
java:153)4XESTACKTRACEatweblogic.
kernel.
ExecuteThread.
run(ExecuteThread.
java:172)3XMTHREADINFO"ExecuteThread:'98'forqueue:'weblogic.
kernel.
Default'"(TID:0x30105890,sys_thread_t:0x799A70A0,state:MW,nativeID:0x6C6D)prio=54XESTACKTRACEatjava.
lang.
String.
substring(String.
java(CompiledCode))4XESTACKTRACEatjava.
lang.
String.
substring(String.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
internal.
WarClassFinder.
getSource(WarClassFinder.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
internal.
WebAppServletContext.
getSource(WebAppServletContext.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
internal.
WebAppServletContext.
getResourceAsSource(WebAppServletContext.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
internal.
WebAppServletContext.
getResourceAsSource(WebAppServletContext.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
internal.
WebAppServletContext.
isResourceStale(WebAppServletContext.
java(CompiledCode))4XESTACKTRACEatjsp_servlet.
_feebyowner.
__search_result.
_isStale(__search_result.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
jsp.
JspStub.
isServletStale(JspStub.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
internal.
ServletStubImpl.
isStale(ServletStubImpl.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
jsp.
JspStub.
checkForReload(JspStub.
java(CompiledCode))4XESTACKTRACEatweblogic.
servlet.
internal.
ServletStubImpl.
getServlet(ServletStubImpl.
java(CompiledCode))90OutOfMemory错误实例(1)-分析问题在哪里91OutOfMemory错误实例(1)分析用户没有估计到报表业务的内存需求量用户调整报表业务的实现方式和技术方案92OutOfMemory错误实例案例二93OutOfMemory错误实例(2)现象环境Windows2003,JDK1.
5.
0_2232bit,WeblogicServer9.
2MP3刚刚启动,运行非常正常过了一段时间(不定),WeblogicServer抛出OOM异常.
从GC日志中看到,Heap区在极短时间内被占光物理系统足够,空闲内存足够94OutOfMemory错误实例(2)问题收集什么信息95OutOfMemory错误实例(2)答案GC日志系统参数,采用的第三方组件用性能检测工具分析用EeclipseMemoryAnalyzer进行离线分析96OutOfMemory错误实例(3)-分析问题在哪里97OutOfMemory错误实例(3)过程和结果用EeclipseMemoryAnalyzer分析显示:–内存中存在apache的poiexcel处理组件–根据业务系统的需要,升级到64位WebLogic9.
2MP3,问题解决98小节回顾两个OOM/ML解决实例在本小节中,我们讲述了以下内容:99回顾内存不足/内存泄漏的基本概念诊断和定位内存问题故障排除步骤和方案应用分析工具解决问题OOM/ML实例