java - javacore 和 heapdump 中的堆大小 : 20x difference on IBM JVM

Question

注意到生产服务器 (Websphere8.5.5) 开始消耗大量内存。

javacore dump 中的数字清楚地表明罪魁祸首是过大的堆:

|  +--Memory Manager (GC): 5,496,900,272 bytes / 3193 allocations
|  |  |
|  |  +--Java Heap: 5,368,770,560 bytes / 1 allocation
|  |  |
|  |  +--Other: 128,129,712 bytes / 3192 allocations  

但与此同时，在 MAT 中打开的堆转储报告堆的总容量约为 200M(有时高达 300M，但不会更多)。

这到底是什么意思？堆转储值得信赖吗？如果是，有没有办法释放未使用的堆内存？

更新:完整的 NATIVEMEM 部分，按要求

1MEMUSER       JRE: 7,211,791,256 bytes / 39196 allocations
1MEMUSER       |
2MEMUSER       +--VM: 6,772,051,048 bytes / 29934 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Classes: 370,339,176 bytes / 10002 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Shared Class Cache: 62,914,560 bytes / 1 allocation
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Other: 307,424,616 bytes / 10001 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Memory Manager (GC): 5,496,900,272 bytes / 3193 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Java Heap: 5,368,770,560 bytes / 1 allocation
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Other: 128,129,712 bytes / 3192 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Threads: 91,710,312 bytes / 3408 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Java Stack: 5,958,456 bytes / 349 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Native Stack: 68,812,800 bytes / 248 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Other: 16,939,056 bytes / 2811 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Trace: 3,415,376 bytes / 1229 allocations
2MEMUSER       |  |
3MEMUSER       |  +--JVMTI: 17,776 bytes / 13 allocations
2MEMUSER       |  |
3MEMUSER       |  +--JNI: 5,821,768 bytes / 9844 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Port Library: 794,750,560 bytes / 401 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Unused <32bit allocation regions: 794,704,552 bytes / 87 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Other: 46,008 bytes / 314 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Other: 9,095,808 bytes / 1844 allocations
1MEMUSER       |
2MEMUSER       +--JIT: 436,874,280 bytes / 8850 allocations
2MEMUSER       |  |
3MEMUSER       |  +--JIT Code Cache: 268,435,456 bytes / 1 allocation
2MEMUSER       |  |
3MEMUSER       |  +--JIT Data Cache: 48,235,968 bytes / 23 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Other: 120,202,856 bytes / 8826 allocations
1MEMUSER       |
2MEMUSER       +--Class Libraries: 2,865,928 bytes / 412 allocations
2MEMUSER       |  |
3MEMUSER       |  +--Harmony Class Libraries: 2,000 bytes / 1 allocation
2MEMUSER       |  |
3MEMUSER       |  +--VM Class Libraries: 2,863,928 bytes / 411 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--sun.misc.Unsafe: 2,635,720 bytes / 307 allocations
4MEMUSER       |  |  |  |
5MEMUSER       |  |  |  +--Direct Byte Buffers: 2,625,112 bytes / 304 allocations
4MEMUSER       |  |  |  |
5MEMUSER       |  |  |  +--Other: 10,608 bytes / 3 allocations
3MEMUSER       |  |  |
4MEMUSER       |  |  +--Other: 228,208 bytes / 104 allocations

Answer 1

NATIVEMEMINFO 部分显示了虚拟内存，因此 5,368,770,560 仅表示 JVM 已虚拟地为堆分配了那么多内存。实际驻留多少取决于实际堆大小和堆使用情况。例如，如果在 tenured region 中堆积了大量垃圾，然后在 full GC 中被清理，那么这些页面可能在某个时候成为常驻页面，但实际有多少是活跃的取决于许多因素。我相信当 JVM 启动时，它实际上分配了 -Xmx 的全部大小，所以我认为您总是会在 NATIVEMEMINFO 中看到堆的全部大小(也可能是它只分配 >-Xms，因此如果您看到的大于 -Xms，则意味着压力导致堆增加 [当然，请注意正常的 sawtooth ]) .

当您在 MAT 中加载转储时，它会运行完整的垃圾收集并默认从主视图中删除所有无法访问的对象。您可以单击“概述”页面上的“无法访问的对象直方图”链接，然后滚动到底部的浅堆总计总和行，以查看堆转储中有多少“垃圾”。 MAT 首选项中还有一个选项“保留无法访问的对象”，这会将所有这些对象保留在主 MAT View 中，但这通常不是很有用。

所以基本的答案是 MAT 只显示 Activity 对象，所以在转储时，有 200-300MB 的 Activity 对象。其余的可能在垃圾箱中，或者根本不存在，NATIVEMEMINFO 只是显示虚拟大小。

随着时间的推移查看堆使用情况的更好方法是 verbosegc 和加载 GCMV :

-Xverbosegclog:verbosegc.%seq.log,20,50000