内容发布更新时间 : 2024/7/1 17:28:24星期一 下面是文章的全部内容请认真阅读。

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 不使用并发标记，但是，使用一种改进的内存分配算法用来获

得更好的性能。

后两种在电子商务应用中可提升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