WAS6.1垃圾回收日志分析
有名的IBM离线内存日志分析工具：IBM Pattern Modeling and Analysis Tool for Java Garbage Collector。
通过记录内存使用的日志文件native_stderr.log，可以对WAS运行的情况进行分析。
运行ga29.jar,在菜单中打开native_stderr.log文件。
WAS打开“详细垃圾回收开关”生成native_stderr.log的方法：
服务器-->应用程序服务器(server1)--->java和进程管理---->进程定义---->java虚拟机------>详细垃圾回收
查看垃圾回收的详细信息
在WAS的日志目录下，WebSphere\AppServer5\logs\server1\，查看文件“native_stderr.log的内容， ”
…………
<AF[3]: Allocation Failure. need 528 bytes, 13780 ms since last AF>
<AF[3]: managing allocation failure, action=1 (0/167351272) (8807960/8807960)>
<GC(3): GC cycle started Tue Jun 21 13:25:10 2005
<GC(3): freed 131440728 bytes, 79% free (140248688/176159232), in 150 ms>
<GC(3): mark: 137 ms, sweep: 13 ms, compact: 0 ms>
<GC(3): refs: soft 0 (age >= 32), weak 14, final 362, phantom 0>
<AF[3]: completed in 172 ms>
…………
其中第一行红色部分是Allocation Failure时间，记做A；最后一行红色部分是本次垃圾回收时间，记做B。
如果“native_stderr.log”文件中有连续的A÷B < 10的话，说明目前WAS性能将下降，需要增加WAS的内存或减小WEB容器的线程池的设置。
通过记录内存使用的日志文件native_stderr.log，可以对WAS运行的情况进行分析。
运行ga29.jar,在菜单中打开native_stderr.log文件。
WAS打开“详细垃圾回收开关”生成native_stderr.log的方法：
服务器-->应用程序服务器(server1)--->java和进程管理---->进程定义---->java虚拟机------>详细垃圾回收
查看垃圾回收的详细信息
在WAS的日志目录下，WebSphere\AppServer5\logs\server1\，查看文件“native_stderr.log的内容， ”
…………
<AF[3]: Allocation Failure. need 528 bytes, 13780 ms since last AF>
<AF[3]: managing allocation failure, action=1 (0/167351272) (8807960/8807960)>
<GC(3): GC cycle started Tue Jun 21 13:25:10 2005
<GC(3): freed 131440728 bytes, 79% free (140248688/176159232), in 150 ms>
<GC(3): mark: 137 ms, sweep: 13 ms, compact: 0 ms>
<GC(3): refs: soft 0 (age >= 32), weak 14, final 362, phantom 0>
<AF[3]: completed in 172 ms>
…………
其中第一行红色部分是Allocation Failure时间，记做A；最后一行红色部分是本次垃圾回收时间，记做B。
如果“native_stderr.log”文件中有连续的A÷B < 10的话，说明目前WAS性能将下降，需要增加WAS的内存或减小WEB容器的线程池的设置。