websphere内存溢出处理常用方法带截图.doc

WebSphere内存溢出处理

1. jvm大小调整到768-1.5g，不要超出1536（MB）。对于32位JDK如果初始值超过2048（即2GB的JVM堆大小），将导致JVM初始化失败，websphere服务器无法启动。经验：如果使用超过1.5GB的JVM大小，就有可能出现古怪的内存分配失败问题。（websphere6.1使用IBM JDK 5.0，针对大对象的内存分配做了处理。）注意：调整JVM堆大小是最后应该考虑的手段，因为增大JVM同时也会增加垃圾回收的系统暂停时间。
2. IBM JDK 5.0有4种垃圾回收机制可针对不同问题使用。
命令：-Xgcpolicy:<optthruput|optavgpause|gencon|subpool>
l Optthruput 默认的回收策略，不使用并发标记。如果用户没有因为内存回收时系统暂停时间过长问题，可以保持这个默认的参数。
l Optavgpause 如果内存回收时导致系统暂停时间过长，建议使用这个策略。它可以缩短系统内存回收时的被暂停时间。
l Gencon 是一种将并发标记和传统的垃圾回收机制综合使用的策略，用于将内存回收时的暂停时间最小化。
l Subpool 不使用并发标记，但是，使用一种改进的内存分配算法用来获得更好的性能。
后两种在电子商务应用中可提升30%~60%的吞吐量。
3. 打开垃圾回收详细信息功能。
可以在控制台中设置，设置后需要重新启动websphere才能生效。开启这个功能后会生成进程日志（vnative_stdout.log或者vnative_stderr.log）包含垃圾处理过程的信息。这项功能默认是不启用的。可以使用相应的工具分析这些文件来分析垃圾回收的情况。

勾选这项重启，就可以了。
垃圾回收分析工具PMAT（ga）支持多种JDK版本的分析。
启动java -Duser.language=cn -Duser.country=CN -jar ga29.jar
不同的系统产生的日志采用不同参数，默认的是IBM的。
点击导入vnative_stderr.log文件。

（used（after）就是GC完成后占用内存大小的变化曲线）
AF（Allocation Failure）内存分配失败
内存泄露（Memory Leak）由于应用程序的非正常的申请越来越多的内存对象导致最终所有的内存空间被用完。
内存碎片（Memory Fragmentation）即虽然所有的空闲的内存空间的总和大于所需申请的内存，但是，由于这些内存不是连续的（由于某些内存无法移动）而无法分配。内存碎片问题多数是由于固定对象和大对象问题引起的。
分析方向：（两个图表 两次分配失败的间隔时间（Time since last AF）和GC完成时间（Complete time））
Ø 如果GC的频率很高（不论GC的完成时间是否正常），则很可能是真正的内存碎片问题。可以尝试调大JVM堆大小。
Ø GC的每次执行时间应该小于10S。如果大于这个值说明垃圾回收器要花很长一段时间去清理大空间堆里的对象。这一般说明JVM堆的最大值过大，应该调小。
Ø “GC的周期和分布”可以用来分析GC的开销是否过大；“GC后的空闲内存空间”可以用来发现内存泄露；“GC前的空闲内存空间”和“引起AF请求的大小”可以发现碎片过多和大对象问题，等等。
Ø 碎片问题（AF发生前的总空闲内存大小和导致AF的内存请求大小图表）正常情况下，AF发生前的总空闲内存大小应该比较小，或至少小于导致AF的内存请求大小。正常情况下，这个曲线应该贴近水平坐标轴，即AF发生前剩余空间应该接近零。反之，就很可能出现了内存碎片问题。
Ø 内存碎片问题解决（大部分是由于固定对象问题（pinned object）和大对象问题），固定对象问题可以通过设置“-Xk”和“-Xp”通用JVM参数来解决。在通用JVM参数中设置参数“-verbosegc –Dibm.dg.trc.print=st_verify”，重新启动websphere就可以在日志中看到相应的“pinned=nnnn”等信息。
序号
参数
含义
单位
1
Since
从上次AF到现在的时间
millisecond
2
Freed
这次GC释放的空间
byte
3
Needed/Requested
这次AF的请求空间
byte
4
Free
这次GC后总的空闲空间
byte
5
Total
GC后的Java 堆大小
byte
6
Completed
完成AF的时间
millisecond
7
GC Completed or GC
完成GC消耗的时间
millisecond
8
Overhead
完成AF的时间%
%
9
Mark
标记状态消耗的时间
millisecond
10
Sweep
打扫状态消耗的时间
millisecond
11
Compact
压缩耗时
millisecond
12
Exhausted
是否没有足够的空间分配使失败

4. 两种情况会导致java.lang.OutOfMemoryError exception
l The Java™ Virtual Machine (JVM) might run out of contiguous Java heap space to allocate a Java object.
l The JVM might not be able to allocate native memory.
5. 分析系统的堆镜像（heapdump）文件
系统有可能自动产生，但是建议在系统运行过程中手工产生heapdump文件。下面介绍两种手工产生heapdump文件的方法。
对于IBM JDK，可以使用IBM HeapDump，这是IBM自带的工具。为了使用这个工具，需要在websphere管理控制台中添加JVM的如下定制属性：
IBM_HEAPDUMP=TRUE
IBM_HEAP_DUMP=TRUE
IBM_HEAPDUMPDIR=<HEAPDUMP文件输出路径>
IBM_HEAPDUMP_OUTOFMEMORY=TRUE
IBM_JAVADUMP_OUTOFMEMORY=TRUE
IBM_JAVA_HEAPDUMP_TEXT=TRUE
如果没有设置IBM_HEAPDUMPDIR，默认的输出路径就是应用服务器的根目录。保存修改后重新启动应用服务器。在unix平台需要获取应用服务器进程的进程PID，Unix下需要获得heapdump文件的时候，在命令行输入“kill -3 <PID>”命令。该命令会在指定的目录下产生“heapdump”和“javacore”文件。一般来说需要产生多次heapdump文件来对比分析。Windows下，没有kill命令，需要通过webshpere应用服务器的命令行控制台进行。如下例：
<WAS_HOME>\profiles\server1\bin>wsadmin.bat
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
wsadmin>$AdminControl invoke $jvm dumpThreads
可以使用分析工具有Heap Analyzer和MDD4J（分析heapdump）。
6. Heap Analyzer使用分析javacore文件
使用命令行：java –Xmx1300m -jar ha26.jar

打开载入界面

可以查看是否有死锁

7.