用 verbose GC 分析 IBM WebSphere Portal 的内存问题
2010-06-23 00:00:00 来源:WEB开发网分析这个日志文件条目
现在,让我们将之前的日志条目细分成几个部分并分别加以分析。
首先是:
<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)。
更多精彩
赞助商链接