• 1. 曹春 联动北方科技中间件技术支持JVM 内存管理机制分析与OOM问题浅析 用心联动世界 品质源于专业400-810-2327 www.landingbj.com
  • 2. 主讲内容如下400-810-2327 www.landingbj.com了解Java基本内存管理基本概念 了解Jvm参数的参数配置及其作用 了解发生内存不足/内存泄露错误的主要原因 如何诊断内存不足/内存泄露 使用分析工具分析内存不足和内存泄露 OOM错误实例
  • 3. 了解Java基本内存管理基本概念400-810-2327 www.landingbj.comJava内存包括哪几部分? Java 堆内存(Heap) Permanent区(Sun/Hp JDK) 本地内存(Native Memory) Java 堆内存(Heap): 是 JVM 用于分配 Java 对象的内存,包含活动对象和freed对象 堆大小使用 java 命令中的 –Xms(最小) –Xmx(最大)标志来定义。 Permanent区: 是Sun JDK和HP JDK用来加载类(class)的专门的内存区 这个区域不归属Java 堆内存(Heap)范围 如果Java应用很大,例如类(class)很多,那么建议增大这个区域的大小来满足加载这些类的内存需求 通过–XX:PermSize=***M –XX:MaxPermSize=***M调整
  • 4. 了解Java基本内存管理基本概念400-810-2327 www.landingbj.com本地内存(Native Memory) 是 JVM 用于其内部操作的本地内存(非Java内存) JNI 代码和第三方本地模块(例如,本地 JDBC 驱动 程序)也使用本地内存 最大本地内存大小取决于以下因素: 操作系统进程内存大小限制 已经指定用于 Java 堆的内存 进程的内存大小等于什么? 32位操作系统,理论最大值2的32次方=4G 64位操作系统,理论最大值是一个很大的数字 进程内存 = Java (Heap)+本地内存 + 加载的可执行文件和库 + 操作系统保留内存
  • 5. 了解Java基本内存管理基本概念400-810-2327 www.landingbj.comJava堆内存大小的决定因素: 进程大小限制,例如:<=4G “加载的可执行文件和库+系统保留内存”不同操作系统和应用不一样, 通常在百M到1G间 JVM的本地内存在不同的JDK之间也不一样。JRockit相对Sun JDK,做了非常好的JIT优化,但是本地内存要求更多的空间 通常Java堆内存大小推荐不大于2G 大部分操作系统默认也上不到2G,需要做内核调整--大内存模式 Java堆内存的大内存模式: PlatformDefault Maximum Heap SizeWindows on a 64 bit platform75% of total physical memory up to 3 GBLinux or Solaris on a 64 bit platform75% of physical memory up to 3 GBWindows on a 32 bit platform75% of total physical memory up to 1 GBLinux or Solaris on a 32 bit platform75% of physical memory up to 1 GB
  • 6. 了解Java基本内存管理基本概念400-810-2327 www.landingbj.com垃圾回收 (Garbage Collection, GC)的作用: JVM自动检测和释放不再使用的内存。 Java 运行时JVM会执行 GC,这样程序员不再需要显式 释放对象。 通常在空闲内存降低到某一水平或内存分配达到某一 数量后自动触发。 各种JDK的垃圾回收都有多种算法和策略(预了解详情请参考附件) 以下OutOfMemory 简称 OOM 以下Memory Leak 简称 ML
  • 7. Java内存的两种表现形式400-810-2327 www.landingbj.comJava内存问题的两种表现形式: 内存溢出错误(OOM) 内存泄露错误(ML) 现在先不管这两种内存问题是什么愿意导致的,但是最终它们都会抛出同样的内容:java.lang.OutOfMemoryError 共同点是什么呢? 没有空闲内存可供 JVM 或本地代码用于分配新对象或内存块 通常最终的状态就会导致 OOM 错误 在 Java 堆或本地内存中都可能发生 不同点是什么呢? ML是已经分配好的内存或对象,当不再需要,没有得到释放 而OOM则是没有足够的空间来供jvm分配新的内存块 ML 的内存曲线总体上是一条斜向上的曲线而OOM不是那样子的
  • 8. Java内存问题的两个主要发生区段400-810-2327 www.landingbj.comJava内存问题的两个主要发生区段: Java内存--包括heap堆内存和permanent区 本地内存--包括JVM进程内存和java使用的第三方本地代码 Java内存不足 Java堆内存heap不足,无法再分配新对象或内存块 permanent区内存不足,无法再加载类到内存中(Sun & Hp JDK) 本地内存不足 物理内存不够,无法再得到内存 第三方本地代码有内存泄漏的Bug JVM的JIT或者JVM本身的Bug(很古老的技术啦)
  • 9. 物理内存和虚拟内存 400-810-2327 www.landingbj.com计算机的可寻址空间 = RAM + 交换空间 进程A的虚拟内存进程D的虚拟内存进程B的虚拟内存进程C的虚拟内存RAM交换空间进程的虚拟内存由 OS 映射到物理内存本地内存可执行文件/库Os使用本地内存Os使用本地内存Os使用本地内存Os使用Java heapJava heapJava heapJava heap可执行文件/库可执行文件/库可执行文件/库当然了,进程大小受到os的限制
  • 10. 了解Jvm参数的参数配置及其作用400-810-2327 www.landingbj.comHotSpot JVM OptionJRockit JVM OptionFunction-verbose:gc-Xverbose:gcThis option prints log information about the memory system-Xmn, -XXNewSize, and -XXMaxNewSize-XnsThis option sets the size of the young generation-XX:+UseConcMarkSweepGC-Xgc:singleconThis option sets the garbage collector to use a concurrent strategy.-XX:+UseParallelGC-Xgc:parallelThis option sets the garbage collector to use a parallel strategy-Xms-Xms-Xms参数是用来设置java heap最小值。 Java heap (the heap) 是内存的一部分-Xmx-Xmx设置最大java heap,这些内存块是分配给对象或者是freed,在gc期间是可以被回收的
  • 11. 了解发生内存不足/内存泄露错误的主要原因和症状400-810-2327 www.landingbj.com了解发生内存不足/内存泄露错误的主要原因和症状 第二讲
  • 12. Java内存问题的主要发生在?400-810-2327 www.landingbj.com操作系统本身 Java内存区: heap堆内存 permanent区(SUN & HP) 本地内存区: JVM进程内存 Java使用的第三方本地代码
  • 13. 内存不足和内存泄漏错误的典型原因(1)400-810-2327 www.landingbj.com物理内存不足 物理内存有限,例如只有1G 物理内存很大,但是应用很多,占用太多内存 Swap区大小不够 Weblogic Server压力太大 并发用户太多 大数据量分配应用,例如统计报表 Permanent区太小 用户代码内存不释放 http session放置了大量对象 在内存分配大量数据 用户自己创建太多线程 调用AWT等画图接口 用户代码内存泄漏问题 jdbc连接没有close 分配好的对象没有close和释放
  • 14. 内存不足和内存泄漏错误的典型原因(2)400-810-2327 www.landingbj.comWeblogic Server配置不当 给Heap分配的内存太多 session timeout时间太长(如果用session对象保存大量的对象) EJB pool和Cache的太大 JMS配置 Java内存碎片 尤其在IBM JDK上表现明显 第三方Java应用的内存问题 第三方Java应用也存在内存不足或者泄漏问题 第三方本地代码的内存泄漏问题 第三方JDBC驱动的内存泄漏 其他第三方本地代码的内存泄漏 JVM本身的内存问题 JVM本身的一些bug
  • 15. 在 Java 堆中发生的 OOM 的故障症状 400-810-2327 www.landingbj.com如果 Java Heap发生 OOM/ML: Weblogic Server运行缓慢,响应速度很慢(JVM在频繁的做GC,Java进程占用比较多的CPU ) 最终JVM抛出 java.lang.OutOfMemoryError 异常,stdout 或 stderr 中将显示这则消息 通过thread dump可以看到大部分时间 所有线程都在wait,只有GC线程在工作 很多线程都在申请内存 线程可能会异常退出(即在 Thread Dump 中看不到这个线程,线程丢失) 持续的Java 堆OOM/ML错误偶尔也会导致JVM进程退出服务,通常伴随会产生一个文本Core文件
  • 16. 本地内存中发生的 OOM 的故障症状 400-810-2327 www.landingbj.com如果本地内存OOM/ML: Weblogic Server运行缓慢,响应速度很慢 通过操作系统观察可以看到,Java进程内存很大,而且一直在增长(当然要长时间观察) 通过console或者GC log可以看到,heap内存通常还有富余 JVM 的通常做法是:处理 OOM 状态,记录消息,然后退出进程。 如果 JVM 或任何其它已加载的模块(例如,libc 或第 三方模块)不处理异常,OS 将通过 sigabort 强制 JVM 退出。 通常会导致JVM异常退出,通常会产生 JVM 文本Core文件和二进制核心文件。
  • 17. JVM退出时产生的文本Core文件400-810-2327 www.landingbj.com通常JVM异常退出伴随会产生一个文本Core文件 除了OOM,JVM也会因为其他原因异常退出 IBM JDK -- javacore****.txt文件 Sun & Hp JDK -- hs_err_pid****.log文件 JRockit JDK – jrockit.****.dump文件 文本Core文件包含JVM退出时收到的信号量,并会用*标识导致退出的lib库文件 Signal -1 Signal 0 Signal 4 Signal 10 Signal 11 实践表明,收到以上的信号量,通常但不绝对,表明JVM的内存出现问题 需要结合thread dump或者GC日志来分析
  • 18. 诊断、定位和解决内存不足和内存泄漏错误 400-810-2327 www.landingbj.com如何诊断内存不足/内存泄露第三讲
  • 19. 探查OOM/ML问题基本步骤400-810-2327 www.landingbj.com确定是否OOM/ML错误 如果保留现场,立即查看 物理内存大小 Java进程内存大小 剩余可用内存大小 Swap区大小 查看GC log 或 进console查看内存使用曲线 并发用户数量/主要业务类型分析 立即做thread dump帮助分析 如果没有保留现场,那么 加上GC log,收集垃圾回收日 如果条件允许加上heapdump 直到再次发生OOM/ML,分析GC日志和heapdump 基本确定内存问题类型 物理内存不足 并发太多/Java堆内存不足 本地泄漏 其他原因 应用代码问题 采取相应措施 观察,问题是否重现 重复定位/问题解决
  • 20. 怎样确定是否是OOM/ML错误?400-810-2327 www.landingbj.com明确的OOM/ML错误 是否有明确的OutOfMemory错误信息显示 是否明确的看到内存曲线一直在顶部 是否GC日志明确显示内存紧张 不明确的信息,但是可以归到OOM/ML错误 需要更多信息来证实 GC日志和heapdump文件 Thread Dump 文本Core文件 通常可以归到OOM/ML错误的可能症状: Weblogic Server不响应or很慢 GC异常,例如heap使用到顶,GC时间很长 Thread Dump显示几乎所有的线程都在等待,只有GC线程在工作 Core文件指出信号量为-1/0/4/10/11
  • 21. 查看现场/收集信息(1)400-810-2327 www.landingbj.com物理内存大小 如果物理内存不够,请增加物理内存 Java进程内存大小 如果Java进程内存不大,只有几百M或者1G左右,要结合并发用户和GC日志来考虑 如果Java进程内存特别大,例如到2.5G以上,结合heap设置综合考虑。如果heap设置不大1G左右,那么需要考虑本地内存泄漏的可能 剩余可用内存 结合物理总内存,Java进程内存综合考虑是否合理 Swap区大小 Swap区通常建议是物理内存的2-3倍
  • 22. 查看现场/收集信息(2)400-810-2327 www.landingbj.com查看GC log 或 进console查看内存情况 并发用户数量/主要业务类型分析 当时并发用户数量以及session大小分析 主要业务类型分析,是否有大内存占用的业务,例如统计报表等等 立即做thread dump帮助分析 每隔30秒做一次,做3次 Unix/Linux : kill -3 pid IBM JDK:kill -3 pid 生成一个javacore.年月日.时分秒.pid.txt Windows : Ctrl+break 收集操作系统/JDK/WLS信息 操作系统版本信息 JDK版本信息 WebLogic Server版本信息 是否使用了第三方本地代码
  • 23. 查看现场/收集信息--采取措施400-810-2327 www.landingbj.com调整措施 增加物理内存 调整合理的Heap设置 调整Swap区大小 继续跟踪 通过Java进程内存大小和Heap大小判断 Java堆内存问题 本地内存问题 加上GC log和heapdump来分析 IBM JDK: -verbose:gc -Xverbosegclog: -XX:+HeapDumpOnOutOfMemoryError HP JDK: -Xverbosegc[:help]|[0|1][:file=[stdout|stderr|]] -Xloggc Sun JDK / BEA Jrockit: -verbose:gc 继续下一步 – 分析GC日志和heapdump
  • 24. 分析GC日志--完整 GC 的输出 400-810-2327 www.landingbj.com不同的JDK将产生不同格式GC日志,详细的gc输出格式请参考我的word文档,下面就以分析以Sun JDK标准GC日志为准: 不同的JDK有各自的其他丰富信息的GC开关选项 完整 GC 将产生类似如下内容的消息: -verbose:gc 在虚拟机发生GC时在输出设备显示信息 完整 GC 将产生类似如下内容的消息: [time] : GC K->K (K), ms 其中: GC 的开始时间(秒),从 JVM 启动开始计算 回收前对象所使用的内存 (KB) 回收后对象所使用的内存 (KB) 回收后的堆大小 (KB) 执行回收的总时间(毫秒) [Full GC 9701K->9092K(16068K), 0.1164020 secs] [GC 10628K->9324K(16884K), 0.0033240 secs] [GC 10847K->9553K(16884K), 0.0063060 secs] [GC 10899K->9845K(16884K), 0.0067960 secs]
  • 25. 分析GC日志--分析 GC 输出 400-810-2327 www.landingbj.comGC 输出可以反映以下情况: OOM 错误是否发生在运行完整 GC 之后 GC 返回了多少空闲空间,GC运行了多长时间 内存使用量是否增加缓慢(即表明发生了内存泄漏,通常需要观察长时间/大量的GC日志) 是否存在内存碎片 结合JVM进程内存大小,判断Java heap内存问题还是本地内存问题
  • 26. 分析GC日志--确定内存问题类型400-810-2327 www.landingbj.com基本确定内存问题类型 Java堆内存不足 本地内存泄漏 不同内存问题类型,解决方案有所不同 如何确定: Java堆内存不足 Java进程内存比较稳定 GC日志显示,heap区内存不够,GC很频繁 本地内存泄漏 GC日志显示,heap内存尚有足够空间 但是Java进程却随时间一直在增长(需要长时间观察积累)
  • 27. 处理 Java Heap OOM 错误 400-810-2327 www.landingbj.com对于java Heap OOM错误: 请确保启用 verbose GC,也就是在启动服务器时使用 java -verbosegc 开关 检查 OOM 错误是否发生在运行了完整的 GC 之后 检查是否执行了内存压缩以减少内存碎片 还要留意初始(和周期)JVM 堆可用性/占用率
  • 28. 针对 Java 堆 OOM 的应用程序分析 400-810-2327 www.landingbj.com如果 JVM 正确执行了 GC,则应该是应用程序问题所致: 如果应用程序使用了缓存对象: 请确保对缓存对象数量施加了限制 或许可以降低缓存限值来减少总体堆大小 如果应用程序使用了活动时间长的对象,请减少这些对象的数量或缩短它们的生命周期,例如,缩短 HTTP 会话的超时期间 调整垃圾回收策略,可能解决OOM问题 查找内存泄漏,例如,不正确的 JDBC 池连接处理 如果服务器只是对负载增加或添加应用程序作出反应,JVM 自然会需要更大的Heap
  • 29. 分析GC日志--内存缓慢增长400-810-2327 www.landingbj.com从GC日志中看到内存的缓慢增长: 5384.404: [GC 601124K->441427K(1390272K), 0.0170360 secs] 5433.628: [GC 601363K->444158K(1390912K), 0.0182190 secs] 5444.562: [GC 605118K->443712K(1385856K), 0.0178850 secs] 5444.960: [GC 604672K->443727K(1391104K), 0.0156540 secs] 5567.835: [GC 605327K->445869K(1390848K), 0.0170140 secs] 5568.236: [GC 607469K->445872K(1391872K), 0.0156460 secs] 5610.380: [GC 608624K->449775K(1391680K), 0.0151670 secs] 5800.084: [GC 612527K->447057K(1392064K), 0.0150910 secs] 6038.867: [GC 609809K->447846K(1386816K), 0.0169620 secs] 6167.461: [GC 609638K->450058K(1389376K), 0.0163890 secs] 6167.890: [GC 610890K->450180K(1389952K), 0.0172030 secs]
  • 30. 分析GC日志--内存碎片400-810-2327 www.landingbj.com从GC日志中分析观察到内存碎片现象: [memory ] 8.162: GC 73043K->72989K (131072K) in 12.938 ms [memory ] 8.172: GC 72989K->72905K (131072K) in 12.000 ms [memory ] 8.182: GC 72905K->72580K (131072K) in 13.509 ms …… java.lang.OutOfMemoryError 这个问题多发生在IBM JDK上,因为它采用的垃圾回收算法跟别的JDK不一致(注:IBM JDK GC输入与上略有不同) 在Sun JDK / HP JDK不常见,很少出现 调整策略 IBM JDK:-Xcompactgc Sun JDK:增加young区大小 -XX:NewRatio -XX:NewSize -XX:MaxNewSize -XX:SurvivorRatio(详细参见Sun文档) GC减小了使用的heap,其大小已最大heap有明显差距,但是在日志中OOM依然出现
  • 31. 分析GC日志--Permanent区不够400-810-2327 www.landingbj.com从weblogic/GC日志中观察到 ####<2010-10-18 下午01时55分01秒 CST> <> <> <> <1287381301597> <63% of the total memory in the server is free> ####<2010-10-18 下午01时56分29秒 CST> <> <> <> <1287381389654> <87% of the total memory in the server is free> ####<2010-10-18 下午01时57分29秒 CST> <> <> <> <1287381449659> <72% of the total memory in the server is free> ####<2010-10-18 下午01时59分19秒 CST> <> <> <> <1287381559017> <91% of the total memory in the server is free> ####<2010-10-18 下午02时00分32秒 CST> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1287381632070> <[ServletContext@15209872[app:stzscqzw module:stzscqzw.war path:/stzscqzw spec-version:2.5]] Root cause of ServletException. java.lang.OutOfMemoryError: PermGen space at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.newInstance0(Class.java:326) at java.lang.Class.newInstance(Class.java:308) at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381) 这个问题发生在Sun/HP JDK上,因为它采用Permanent区来存放Java的class对象 这个问题的主要区别在于两者发生的时间不一样 调整策略 增加Permanent区大小 (weblogic上默认是48M) -XX:MaxPermSize=256M(推荐128M以上)
  • 32. 进一步分析 Java 堆 OOM 400-810-2327 www.landingbj.com如果迄今为止所进行的分析不起作用,请使用 JVM 性能探查工具: 该探查工具将实现 JVM 事件探查器接口 (JVM Profiler Interface, JVMPI),如 Jprobe 或 OptimizeIt或者YourKit 确定占用堆的对象的类型、数量和大小 确定对象在代码中的创建位置 其用法的详细信息,请参考相应的JVM性能探查工具文档 不过,JVM 事件探查器通常需要较高的系统开销, 因此在生产机器上很少使用这样子的探查方法,建议一定不要在生产环境中使用! 与应用程序团队合作,查明可能存在的内存泄漏或 改进对象的使用和/或生命周期状况。
  • 33. 处理本地内存 OOM(1)400-810-2327 www.landingbj.com对于本地内存 OOM 错误: 采用的探查方法与对 Java 堆 OOM 采用的探查方法相同: 通过 -verbosegc 开关收集 GC 信息 确认 GC 的运行合乎预期,例如,是在 OOM 发生前 运行 留意 JVM 堆的初始(和周期)可用性/占用率。 定期监视进程内存大小: 在 Unix/Linux 上,使用 ps -p -o vsz 或者top命令 在 Windows 上,使用 perfmon 工具。 确定是否使用了任何本地模块或 JNI 代码。 还要检查计算机的物理内存总量(RAM 和交换空间之和)是否足以满足所有正在运行的进程的需要
  • 34. 处理本地内存 OOM(2)400-810-2327 www.landingbj.com使用收集到的数据来解决 OOM 错误 如果怀疑发生了内存泄漏,集中精力查找泄漏源 第三方代码(例如,JDBC 驱动程序)或 JNI 代码 可能会发生泄漏 排除法,不使用第三方代码 可能的情况下尝试替换纯 Java 实现,以确认泄漏源。 如果存在本地内存泄漏 增加物理内存,只能够延缓故障发生,无法根除问题
  • 35. 处理本地内存 OOM(3)400-810-2327 www.landingbj.com从GC日志中看到Heap实际使用大小远小于最大值,可以减少这个最大值,提供更多可用的本地内存 如果 RAM 和交换空间不足,添加内存或者升级计算机 JVM 使用本地内存: 加载类和生成代码,但在启动几小时后,内存使用量通常会稳定下来 可能会发生运行时类加载和代码优化(JIT很古老的技术) 禁用JIT功能: 如果使用的是 JRockit,-Xnoopt 如果使用的是 Sun/HP的JDK,-Xint 如果使用的是 IBM JDK,-Djava.compiler=NONE
  • 36. 处理本地内存 OOM(5)400-810-2327 www.landingbj.com最后,如果无法查明本地内存 OOM 错误的成因: 请与 JVM 供应商联系,找到跟踪本地内存分配调用的方法 请与第三方模块或 JNI 代码供应商联系,是否有调试/跟踪功能 继续收集和分析有关 OOM 错误发生时间和发生原因的信息 如果存在多个成因,缩小探查范围可能需要一些时间。 升级 升级JDK 升级操作系统 升级Weblogic Server
  • 37. 使用分析工具分析内存不足和内存泄露400-810-2327 www.landingbj.com第四讲使用分析工具分析内存不足和内存泄露
  • 38. 使用分析工具分析内存不足和内存泄露400-810-2327 www.landingbj.com发生Java Heap OOM 问题时,无法定位到问题,最终的办法只能使用分析工具来做分析。 JDK本身的一些工具 Jmap Jconsole等等 常用内存分析工具 此类工具非常多 推荐使用轻量级分析工具 HeapAnalyzer or HeapRoots for IBM JDK Only-离线分析 BEA JRA Memory Leak Detector– JRockit YourKit -轻量级 OptimizeIt
  • 39. HeapAnalyzer400-810-2327 www.landingbj.comHeapAnalyzer是一款针对IBM JDK的内存文本镜像HeapDump的分析工具 特性: 离线分析,不影响生产系统 需要得到IBM JDK内存镜像 只支持IBM JDK HeapRoots字符界面,HeapAnalyzer是HeapRoots的图形界面 只能静态分析,要求得到现场数据 启动方式: -XX:+HeapDumpOnOutOfMemoryError得到heapdump文件 启动HeapAnalyzer,加载heapdump文件 图形化分析
  • 40. HeapAnalyzer(2)400-810-2327 www.landingbj.comHeapDump是IBM JDK Heap内存的一个文本镜像,默认生成位置在Weblogic Server启动目录下,通常是Domain目录 如果得不到HeapDump,可能是禁止生成 HeapDump的生成开关 export IBM_HEAPDUMP=true export IBM_HEAP_DUMP=true export IBM_HEAPDUMP_OUTOFMEMORY=true export IBM_JAVADUMP_OUTOFMEMORY=true export IBM_JAVACORE_OUTOFMEMORY=true export IBM_HEAPDUMPDIR= 注意: 通常HeapDump会比较大,尤其是在Heap内存设置很大的情况下 为了重现问题,得到现场数据,建议先把HeapDump调小,推荐1G以下 在Window上,如果HeapDump大于1G,可能会无法打开,出现OOM错误 启动HeapAnalyzer需要指定-Xmx参数(例如:javaw -Xms1200M -Xmx1300M -jar D:\ha408\ha408.jar)
  • 41. HeapAnalyzer(3)400-810-2327 www.landingbj.com启动界面
  • 42. HeapAnalyzer(4)400-810-2327 www.landingbj.com找到怀疑泄漏的内存对象
  • 43. OutOfMemory错误实例400-810-2327 www.landingbj.com案 例 一
  • 44. OutOfMemory错误实例(1)现象400-810-2327 www.landingbj.com环境Linux2.6.18-164,sun JDK1.6.11,WebLogic Server 10.3.1集群 、内存:16G 、CPU:2.4GHZ*16 Weblogic server配置参数:-Xmx2G,其它都是默认 刚启动很好,过了一段时间,在测试环境中(用户1~2个),就发生OOM。 只能重启。重启过了一段时间又是这样。
  • 45. OutOfMemory错误实例(1)问题400-810-2327 www.landingbj.com收集什么信息?
  • 46. OutOfMemory错误实例(1)答案400-810-2327 www.landingbj.comGC日志(没有) JavaCore文件分析(没有) Thread Dump HeapDump用HeapAnalyser(没有) Weblogic配置文件 Weblogic日志和nohup文件
  • 47. OutOfMemory错误实例(1) - weblogic日志400-810-2327 www.landingbj.com####<2010-10-15 下午05时35分41秒 CST> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1287135341183> <[ServletContext@7132946[app:bea_wls_deployment_internal module:bea_wls_deployment_internal.war path:/bea_wls_deployment_internal spec-version:null]] Root cause of ServletException. java.lang.OutOfMemoryError: PermGen space > ####<2010-10-15 下午05时36分00秒 CST> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1287135360568> <[ServletContext@7132946[app:bea_wls_deployment_internal module:bea_wls_deployment_internal.war path:/bea_wls_deployment_internal spec-version:null]] Root cause of ServletException. java.lang.OutOfMemoryError: PermGen space > ####<2010-10-15 下午05时37分10秒 CST> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1287135430522> ####<2010-10-15 下午05时37分20秒 CST> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1287135440749> <[ServletContext@29206103[app:BJProject module:BJProject.war path:/BJProject spec-version:2.5]] Servlet failed with Exception java.lang.OutOfMemoryError: PermGen space > ####<2010-10-15 下午05时37分20秒 CST> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1287135440749> <[ServletContext@29206103[app:BJProject module:BJProject.war path:/BJProject spec-version:2.5]] Servlet failed with Exception java.lang.OutOfMemoryError: PermGen space > ####<2010-10-15 下午05时37分20秒 CST> <[ACTIVE] ExecuteThread: '11' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1287135440749> <[ServletContext@7132946[app:bea_wls_deployment_internal module:bea_wls_deployment_internal.war path:/bea_wls_deployment_internal spec-version:null]] Root cause of ServletException. java.lang.OutOfMemoryError: PermGen space >
  • 48. OutOfMemory错误实例(1) - weblogic日志400-810-2327 www.landingbj.com在weblogic日志中可以看到关于weblogic输出的关于heap情况的日志中可以发现,这时候JVM的heap的使用情况。
  • 49. OOM错误分析400-810-2327 www.landingbj.com可以确定JVM heap在发生OOM后还有剩余 日志中明确指定了是JVM的PermGen space空间不足 在安装的时候没有调整PermGen space的大小,默认是使用weblogic的默认参数48M 所以调整方案也很是简单了,调整PermGen space的大小,推介128M以上。
  • 50. OutOfMemory错误实例400-810-2327 www.landingbj.com案 例 二
  • 51. OutOfMemory错误实例(2)现象400-810-2327 www.landingbj.com环境Operating System is AIX 5.3 , J2RE 5.0 IBM J9 2.3 AIX ppc64-64 build j9vmap6423-20071007, weblogic server 9.2.3 刚刚启动,运行非常正常 但是在gc图中看到内存使用量是不断在上升,经过几天左右,JVM可用内存耗尽。 weblogic必须重启
  • 52. OutOfMemory错误实例(2)问题400-810-2327 www.landingbj.com我们要收集什么信息?
  • 53. OutOfMemory错误实例(2)问题400-810-2327 www.landingbj.comGC日志 Thread Dump HeapDump用HeapAnalyser
  • 54. GC分析图400-810-2327 www.landingbj.com
  • 55. Thread dump分析400-810-2327 www.landingbj.com
  • 56. Weblogic日志400-810-2327 www.landingbj.com#### <> <> <> <1295576962668> 这个是日志中偶尔发现的,因为他们要保证系统的正常运行。所以在每次内存出现问题后,都要马上重启weblogic系统。
  • 57. Heap dump分析结果400-810-2327 www.landingbj.com
  • 58. OutOfMemory错误实例(2) - 分析400-810-2327 www.landingbj.com问题在那里?
  • 59. OutOfMemory错误实例(2) - 分析400-810-2327 www.landingbj.comGC内存使用量很高的问题:用户使用了润钱报表业务 用户调整报表业务的实现方式和技术方案:例如在润钱中减少缓存的驻留时间 经过很开发人员的沟通,在heapdump中那些怀疑是内存泄露的地方,那里主要是一个仓储管理的业务。
  • 60. end400-810-2327 www.landingbj.com谢谢!