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

核心提示： 理解了 heap 如何增长以及如何为 JVM 所用之后，现在您就能更好地理解进程运行时有多少内存被 JVM 实际使用，用 verbose GC 分析 IBM WebSphere Portal 的内存问题(9)，分析一个进程使用多少内存对于一个进程或 portal 在运行时使用多少内存，存在着一些

理解了 heap 如何增长以及如何为 JVM 所用之后，现在您就能更好地理解进程运行时有多少内存被 JVM 实际使用。

分析一个进程使用多少内存

对于一个进程或 portal 在运行时使用多少内存，存在着一些误解。通常，portal 的用户通过 ps avg 命令或 Microsoft® Windows® Task Manager（它显示了系统分配给 Java 进程的内存数量）来决定 Java 进程使用了多少内存。

如您所见，分配给进程 X 数量内存，并不意味着有进程实际使用了这么多数量的内存。

如果 Task Manager 或 “ps avg” 显示 Java 进程使用了 616 M 内存，但如果我们查看这个 verbose GC，就会看到它当前只使用了该数量的 40%：

<GC(177): freed 218620376 bytes, 40% free (248587064/616233472), in 459 ms>

在 heap 内仍有空闲内存时出现 OUTOFMEMORY 错误

如果在 heap 内仍有空闲内存的情况下收到一个 OUTOFMEMORY 错误，可以通过查看此 verbose GC 来判断是何原因。如下所示的是来自 verbose GC 内的一个内存不足错误的示例输出:

<AF[2474]:　Allocation　Failure.　need　16777232　bytes,　114　ms　since　lastAF>　
<AF[2474]:　managing　allocation　failure,　action=2(1026078032/1601894912)>　
　<GC(2835):　GC　cycle　started　Thu　Jul　16　11:21:34　2009　
　<GC(2835):　freed　5827392　bytes,　64%　free　(1031905424/1601894912),　in　2519　ms>　
　<GC(2835):　mark:　567　ms,　sweep:　24　ms,　compact:　1928　ms>　
　<GC(2835):　refs:　soft　0　(age　>=　32),　weak　0,　final　6,　phantom　0>　
　<GC(2835):　moved　1711341　objects,　87482984　bytes,　reason=1,　used　8　more　bytes>　
<AF[2474]:　managing　allocation　failure,　action=3　(1031905424/1601894912)>　
　<GC(2835):　need　to　expand　mark　bits　for　1610611200-byte　heap>　
　<GC(2835):　expanded　mark　bits　by　135168　to　25165824　bytes>　
　<GC(2835):　need　to　expand　alloc　bits　for　1610611200-byte　heap>　
　<GC(2835):　expanded　alloc　bits　by　135168　to　25165824　bytes>　
　<GC(2835):　need　to　expand　FR　bits　for　1610611200-byte　heap>　
　<GC(2835):　expanded　FR　bits　by　270336　to　50331648　bytes>　
　<GC(2835):　expanded　heap　fully　by　8716288　to　1610611200　bytes,　64%　free>　
<AF[2474]:　managing　allocation　failure,　action=4　(1040621712/1610611200)>　
<AF[2474]:　clearing　all　remaining　soft　refs>　
　<GC(2836):　GC　cycle　started　Thu　Jul　16　11:21:35　2009　
　<GC(2836):　freed　227346312　bytes,　78%　free　(1267968024/1610611200),　in　1600　ms>　
　<GC(2836):　mark:　370　ms,　sweep:　19　ms,　compact:　1211　ms>　
　<GC(2836):　refs:　soft　438　(age　>=　32),　weak　1178,　final　70,　phantom　0>　
　<GC(2836):　moved　1359393　objects,　60973368　bytes,　reason=1,　used　600　more　bytes>　
<AF[2474]:　managing　allocation　failure,　action=6　(1267968024/1610611200)>　
JVMDG217:　Dump　Handler　is　Processing　OutOfMemory　-　Please　Wait.　
JVMDG315:　JVM　Requesting　Heap　dump　file　
JVMDG318:　Heap　dump　file　written　to　
/opt/WebSphere/AppServer/heapdump.20090716.112135.19377.phd　
JVMDG303:　JVM　Requesting　Java　core　file　
JVMDG304:　Java　core　file　written　to　
/opt/WebSphere/AppServer/javacore.20090716.112144.19377.txt　
JVMDG274:　Dump　Handler　has　Processed　OutOfMemory.　
<AF[2474]:　Insufficient　space　in　Javaheap　to　satisfy　allocation　request>　
<AF[2474]:　completed　in　19738　ms>