开发学院软件开发Java 用 verbose GC 分析 IBM WebSphere Portal 的内存... 阅读

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

 2010-06-23 00:00:00 来源:WEB开发网   
核心提示: 分析这个日志文件条目现在,让我们将之前的日志条目细分成几个部分并分别加以分析,用 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)。

上一页  1 2 3 4 5 6 7  下一页

Tags:verbose GC 分析

编辑录入:爽爽 [复制链接] [打 印]
[]
  • 好
  • 好的评价 如果觉得好,就请您
      0%(0)
  • 差
  • 差的评价 如果觉得差,就请您
      0%(0)
赞助商链接