用 verbose GC 分析 IBM WebSphere Portal 的内存问题

核心提示： 分析这个日志文件条目现在，让我们将之前的日志条目细分成几个部分并分别加以分析，用 verbose GC 分析 IBM WebSphere Portal 的内存问题(2)，首先是：<AF[177]: Allocation Failure. need 528 bytes, 3602594 ms

分析这个日志文件条目

现在，让我们将之前的日志条目细分成几个部分并分别加以分析。

首先是：

<AF[177]: Allocation Failure. need 528 bytes, 3602594 ms since last AF>

通过这个条目，我们能够知道有一个分配失败，当 heap 内没有足够的连续空间可以分配给对象时，就会发生分配失败。对象是 verbose GC 输出中最为常见的。在本例中，它是一个 528 字节的小对象。

从此行可以看出，自我们上次运行了一个 GC 循环后已经过去了一段时间，3602594 ms。

接下来，我们研究最后一行：

<AF[177]: completed in 460 ms>

此行告诉我们在 GC 上花费的时间的数量。使用这个数字，我们就能够获得我们最近一次用在 GC 内的比率并找出我们花在 GC 和非实际工作上的时间比例；比如：

460/3602594 = .000127% of the time was spent in GC

在一个健康的服务器内，花在 GC 内的时间应该少于 13%，理想的是 7-10% 左右。

回到第二行：

<AF[177]: managing allocation failure, action=1 (0/585421800) (29966688/30811672)>

首先注意到的一点是 “action=”。对于一个分配失败，有七种不同的动作可以发生：

action=0 表示 pinnedFreeList 已用尽。

action=1 表示进行的是一个抢占式的垃圾收集循环。

action=2 表示一个完全的分配失败。

action=3 表示发生了一个 heap 拓展。

action=4 表示所有已知的软引用均已清除。

action=5 表示对临时 heap 进行了临时偷用。

action=6 表示空闲空间非常低。

这些动作的顺序代表了严重程度的等级；最严重的情况是服务器的内存完全用完（action=6）。