银行GC分析报告

查看新的错误日志native_stderr.log，在文件尾部在 18：40分有大量的AF日志，内存分配失败都是由于无法分配照成，和先前的症状相同。

= 32), weak 0, final 0, phantom 0>

= 32), weak 0, final 2, phantom 0>

JVMDBG001: malloc failed to allocate 12288 bytes, time: Tue Oct 07 18:41:41 2008

由于IBM的1.4 JVM 的分配策略，当GC发生时，只能移动，回收不用的对象，而不能移动，回收Class对象，这些class对象会一直存在内存当中，当需要给大对象分配内存时，内存中已经无法找到足够的连续空间，就会造成AF错误，直至OOM。

建议调整参数-Xloratio，默认值为0.05，修改为0.2，
该参数是预留部分内存为大对象，如果是0.2 则预留当前heapsize 的20%,当收到新的分配内存申请>= 64 KB，JVM先从其他的80%中分配内存，如果分配失败，则在这20%中分配。如果仍然出现分配失败可以考虑加大预留内存，0.3-0.5.

配置方法：

Servers > Application Servers > server_name > Java and Process Management > Process definition > Java Virtual Machine > Generic JVM Arguments

使用ISA 分析工具分析内存GC情况。

以下是ISA分析报告。

Tuning recommendation

Heap usage seems to be growing over time. It increased by 15% in the last third of the log compared to the middle of the log. The heap size increased by 15% in response to the increased pressure on the heap. While this kept the change in the rate of collections to -100%, the heap growth is not sustainable. Unless the application stops growing its memory requirements, it is likely that an out memory error or severe performance degradation will eventually occur.If you don't know of a reason why the memory requirements of your application should be growing, your application may be leaking memory. Consider reviewing your application for references which are being held unneccessarily, large maps and sets, and large statically-held objects. Using weak references where appropriate may help.

Garbage collection is causing some large pauses. The largest pause was 5917 ms. This may affect application responsiveness. If responsiveness is a concern then a switch of policy or reduction in heap size may be helpful.

The garbage collector tried to allocate from the large object area and failed 309 times. Consider setting or increasing -Xloratio. You may need to also increase the heap size with -mx. Be cautious of increasing -Xloratio to anything greater than 0.2.

The mean heap unusable due to fragmentation is estimated at 17.98%, which is high.You are using the optthrupput gc policy, which is already a reasonable choice. You may be able to reduce fragmentation levels by increasing -Xloratio to increase the room available for large objects or increasing the pinned free list size with the -Xp command line parameter.

At one point 10144 objects were queued for finalization. Using finalizers is not recommended as it can slow garbage collection and cause wasted space in the heap. Consider reviewing your application for occurrences of the finalize() method.

The application seems to be using some quite large objects. The largest request which triggered an allocation failure (and was recorded in the verbose gc log) was for 4194320 bytes.

The recommended command line is -Xloratio0.2.

Summary

Heap size

Fragmentation (estimate)

Used heap (after collection)

JVM restarts