Java HeapDump指出在OutOfMemory异常之后，使用的堆大小比实际的堆定义小30％ [英] Java HeapDumps indicate that used Heap Size is 30% smaller than actual heap definition after OutOfMemory exceptions

问题描述

在JVM抛出 OutOfMemory 异常之后，我分析了一堆堆转储。我在Windows 2008R2平台上使用Hotspot JDK 1.7（64位）。应用服务器是一个JBoss 4.2.1GA，通过 Tanuki Java Service Wrapper 。

它以下列参数启动：

  wrapper.java.additional.2 = -XX：MaxPermSize = 256m 
 wrapper.java.initmemory = 1498 
 wrapper.java.maxmemory = 3000 
 wrapper.java.additional.19 = -XX：+ HeapDumpOnOutOfMemoryError 
  

可以转换为：

-Xms1498m -Xmx3000m -XX：MaxPermSize = 256m -XX：+ HeapDumpOnOutOfMemoryError

还有其他一些GC& JMX配置参数。

我的问题是当我分析由于 OutOfMemoryException 使用，MAT总是显示我的堆大小为2.3G或2.4G。我已经在MAT中的选项中启用了 Keep Unreachable Objects ，所以我不相信MAT正在修剪堆。

  java.lang.RuntimeException：java.lang.OutOfMemoryError：GC开销限制超过
  

或

  java.lang.OutOfMemoryError：Java堆空间
  
 
 
 
  
 
 
 尺寸：2.3 GB类：21.7k对象：47.6m类加载器：5.2k 
  
我的实际堆大小大约是3300KB，所以它们符合我最大堆大小3000m的设置。
 
 
 
那么MAT中缺失的500-600M内存在哪里？为什么MAT只显示我的堆大小为2.4G？
 
 
 
 SO上的其他帖子倾向于表明它是在堆转储之前执行GC的JVM，但如果失踪的500M是由于GC，为什么它甚至把OOM放在首位呢？如果一个GC实际上可以清理500M（或者我的堆的近25％），那么JVM是否真的内存不足？ 
 
 
 
有没有方法调整堆转储，以便我可以获得堆的完整/完整图片（包括缺失的500M）？
 
 
 
如果不是，我发现我真的很难找到/首先遇到这些OOM的原因。 
 
 
根据要求通过某人，我附加了 jstat -gc< PID>的输出。 1000 来自活动节点： http://pastebin.com/07KMG1tr 。
解决方案
你在使用哪种GC？ 
您可能错过了Eden，尝试使用 jstat  -  Java虚拟机统计监控工具 
 
I have a handful of heap dumps that I am analyzing after the JVM has thrown OutOfMemory exceptions.  I'm using Hotspot JDK 1.7 (64bit) on a Windows 2008R2 platform.  The application server is a JBoss 4.2.1GA, launched via the Tanuki Java Service Wrapper.

It is launched with the following arguments:
wrapper.java.additional.2=-XX:MaxPermSize=256m
wrapper.java.initmemory=1498
wrapper.java.maxmemory=3000
wrapper.java.additional.19=-XX:+HeapDumpOnOutOfMemoryError
which translate to:

-Xms1498m -Xmx3000m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError

There are some other GC & JMX configuration parameters as well.

My issue is when I analyze a heap dump created due to an OutOfMemoryException using the Eclipse Memory Analyzer, invariably, MAT shows me heap sizes of 2.3G or 2.4G.  I have already enable the option in MAT to Keep Unreachable Objects, so I don't believe that MAT is trimming the heap.
java.lang.RuntimeException: java.lang.OutOfMemoryError: GC overhead limit exceeded
or
java.lang.OutOfMemoryError: Java heap space
Summary in MAT:
Size: 2.3 GB Classes: 21.7k Objects: 47.6m Class Loader: 5.2k
My actual heap file sizes are roughly 3300KB, so they are in line with my 3000m max heap size setting.

So where is the missing 500-600M of memory in MAT?  Why does MAT only show my heap size as 2.4G?

Other posts on SO tend to indicate that it is the JVM doing some GC prior to dumping the heap, but if the missing 500M is due to a GC, why is it even throwing the OOM in the first place?  If a GC could actually clear up 500M (or nearly 25% of my heap), is the JVM really out of memory?  

Are there ways to tune the heap dumps so I can get a full/complete picture of the heap (including the missing 500M)?

If not, I find I'm really struggling to find how/why I'm encountering these OOMs in the first place.

As requested by someone, I am attaching the output of a jstat -gc <PID> 1000 from a live node: http://pastebin.com/07KMG1tr.
解决方案
Which GC are you using?
You are probably missing Eden, try to use jstat - Java Virtual Machine Statistics Monitoring Tool

                        
这篇关于Java HeapDump指出在OutOfMemory异常之后，使用的堆大小比实际的堆定义小30％的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！