Tag: heap dump

如何使用MAT理解类加载器泄漏以及如何避免它们

好吧，这将是一个很长的问题（我想问很多相关的问题，我觉得卡住了！）。 我花了很多时间试图弄清楚某些事情，但我无法自信地得出结论。 我是性能分析/堆分析的新手，我要求初学者帮助深入研究这些领域。 我发现很难理解这些概念，并按照方法弄清楚事情…… 我们面临的问题是，经过几个小时的执行，我们的应用程序响应时间增加，执行变得如此缓慢，使应用程序停止运行！ 我还分析了线程转储，我不敢说没有从中收集到太多信息。 我可以看到一些处于timed_waiting状态的线程，但没有一个被阻塞或者没有看到任何死锁检测。 因此，我们已将搜索转向堆转储分析。 答：我正在使用MAT进行堆转储分析。 我读过一些博客。 根据这些，我试图形成我的结论。 我想validation一下我的理解。 问题：从上图中我们可以看到1和2中有多个相同类型的类加载器。 为什么会这样？ 事实上，sun.reflect.DelegatingClassLoader有超过1000个条目。 我无法理解这是什么。 现在，让我们深入研究WebappClassLoader的第一个 B. Q1。 这些是这个类加载器定义/加载的类的列表吗？ 正如我们在3中看到的那样，有一个父元素。 这是否意味着这个类加载器总是首先咨询这个父类加载器，并检查它是否由它加载。 如果它的祖先的层次结构不可能加载该类，那么只有它自己加载它？ Is this understanding of the hierarchy of class loading correct? 我仍然没有得到Defined类和实例列数的含义？ 什么实例？ 我的意思是，加载类并不是实例化其对象，不是加载器的工作吗？ 那个实例数是多少？ 在这种情况下，我们可以看到：WebappClassloader有4361个定义的类和65973个实例。 类似地，URLClassLoader（它的父级）有766个定义的类和37399个实例。 它到底意味着什么？ 它是否表明任何Classloader泄漏？ 现在，当我深入查看WebappClassloader的第二个实例时，我看到它们具有相同的父级（0x80a887a8），并且由它加载/定义的类列表也几乎相同。 为什么会这样？ C.现在，当我在WebappClassloader的第一个实例上执行“GC根路径”时，我们可以看到这一点。 我的理解：很multithreading（从我们的应用程序中产生）引用了加载器。 这是一个糟糕的线程实现问题吗？ 我需要找到问题的根本原因，然后我只想进一步解决它。 来自堆转储的其余部分的一些其他观察 ThreadGroupContext和WebappClassloader消耗了大部分堆。 当我深入研究ThreadGroupContext的支配树时，我看到了WeakIdentityMap。 那些是什么？ 这个dominatior树实际上向我们展示了什么？ 当我们深入了解统治者树中的条目时，我们得到了哪些信息？ 具有传出引用的向下钻取视图： 带有传入引用的向下钻取视图：我不明白这一点。 […]

heapdump size vs hprof size

当我的jboss服务器以4096m的xms和4096m的xmx以及512m的permsize运行时，我最近以hprof格式创建了一个heapdump。 生成的hprof文件超过5GB。 当我在visualvm，mat analyzer或yourkit中加载heapdump时，我只看到大约1gb的总字节数。 我已尝试更改yourkit中的可访问性范围，但它不会显示超过1 GB。 知道文件大小与显示的堆转换大小有什么重大差异会导致什么？ ps：我正在使用jdk1.6.0_23 不幸的是我不允许在这里提交截图。 在文件系统上，hprof大小为5.227.659 kb，在yourkit中它指出： 对象：9.738.282 /浅尺寸740 mb /保留大小：740 mb其中可达到的字符串：6.652.515（68％）/浅尺寸：381 mb（51％）/保留大小：381 MB（51％） 保留的最大大小是一个字节[] 206.810.176

如何分析Websphere核心* .dmp文件和Snap * .trc文件？

全部，我的应用程序在websphere app server 7.0上运行。 我得到了一些核心转储和跟踪文件，如 core.20110909.164930.3828.0001.dmp 和 Snap.20110909.164930.3828.0003.trc。 我的问题是，就像WAS生成的线程转储可以由IBM-Thread Dump Analyzer工具打开和分析一样 是否有工具可以由IBM或任何其他人打开上述文件？ 谢谢，阿尤斯曼

eclipse ide中的内存分析在单击获取堆转储对话框时不会列出任何本地进程ID

使用eclipse ide（kepler）中的内存分析器，我正在尝试在程序运行时从本地运行的VM获取堆转储，但是获取堆转储对话框不会列出要选择的任何pid。 我尝试配置hdrof jmap dump provider 同 -jdkhome C：\ Program Files \ Java \ jdk1.8.0_05 \ bin 但没有任何反应。 任何解决方案 谢谢。

增加jvisualVM OQL结果集的最大大小

我有一个内存转储文件，它有近5000个特定对象的实例。 这些对象将被写入数据库，我这样做的方法是在jvisualvm中编写一个OQL查询，以生成一个字符串，用作SQL插入，例如 select “insert into trades (id, tradeNumber) values (“+ x.id+ “, ” + x.tradeNumber +”);” from com.test.application.TradeObject x; 当我通过OQL运行时，我得到一个这样的结果集 – insert into trades (id, tradeNumber) values (1,12345); insert into trades (id, tradeNumber) values (2,123456); insert into trades (id, tradeNumber) values (3,123457); 等等 但是，由于实例总数很大（大约5000），JvisualVM只显示其中的大约100个。 然后出现错误消息“结果太多。请优化您的查询。” 我无法优化查询，因为我必须以这种方式解析所有实例。 有没有办法可以让JvisualVM向我显示所有实例而不限制结果数量？ 我还看到Jvisual vm显示了没有任何filter的前100个实例，是否可以通过OQL查询获得接下来的100个实例等等？ 谢谢

如何从运行tomcat 7获取堆转储

我已经尝试过从Tomcat 6获取JVM上的堆转换但是它对我不起作用，是否有其他方法可以从tomcat服务器获取堆转储？ 提前致谢！

垃圾收集器第一和JMap EOF错误

我们正在研究客户端的生产服务器堆，以检测和解决内存泄漏问题。 为此，我们定期使用jmap来收集必要的信息。 但是上周我们无法进行转储，因为它触发了EOF错误并关闭了Tomcat实例。 我在互联网上搜索但找不到有关此错误的任何具体信息。 我们检测到只有在使用Gc First垃圾收集器算法时才会发生。 这是我们用于执行jmap的命令行： jmap -dump:format=b,file=heap.bin 服务器上的Java版本：JDK 1.7.0_7 x64 有没有人遇到过这种错误？ 可能缺少一些配置或需要java / jmap的补丁。 UPDATE 我们收集的有关此错误的更多信息： [root]# jmap -dump:format=b,file=heap.bin 7806 Dumping heap to /tmp/heap.bin … Exception in thread “main” java.io.IOException: Premature EOF at sun.tools.attach.HotSpotVirtualMachine.readInt(HotSpotVirtualMachine.java:244) at sun.tools.attach.LinuxVirtualMachine.execute(LinuxVirtualMachine.java:193) at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:213) at sun.tools.attach.HotSpotVirtualMachine.dumpHeap(HotSpotVirtualMachine.java:180) at sun.tools.jmap.JMap.dump(JMap.java:241) at sun.tools.jmap.JMap.main(JMap.java:140) [root]# 注意 ：目标目录有超过500GB的可用空间 错误输出到catalina.out（JVM转储错误）： # A fatal error has […]

巨大的堆转储（11GB） – Jhat失败和Eclipse MAT需要帮助

我们的EA中出现内存错误，我们使用-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/some/dir在OOM时转储堆。 我们有一个12GB的堆内存和256MB的perm gen。 堆转储是在我们运行我们的应用程序的Linux框中生成的，其大小为11.5GB。 我们没有权限将其下载到我们的本地。 当我们尝试使用JHAT分析11GB堆转储时，它会抛出一个OOM。 我们从Linux CLI尝试了以下命令。 jhat java_pid1491.hprof jhat -J-Xmx16g -XX:-UseBiasedLocking java_pid1491.hprof jhat -J-d64 -J-Xmx16g -J-XX:-UseBiasedLocking java_pid1491.hprof#1 对于所有选项，它在读取转储几分钟（> 30分钟）后抛出一个OOMexception。 我们用谷歌搜索它并发现MAT作为一个强大的堆转储分析器，但不是在LINUX中使用它的方法。 任何建议都会有更大的帮助。 谢谢。 改性： 在Linux x86_64机器上安装了MAT，但在执行时出现了以下错误./MemoryAnalyzer (.:17319): GLib-GObject-WARNING **: invalid (NULL) pointer instance (.:17319): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)’ failed (.:17319): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)’ failed (.:17319): GLib-GObject-CRITICAL **: g_object_get: […]

Java堆转储错误 – 元数据似乎不是多态的

在尝试从正在运行的Java进程中获取堆转储时，我得到了这个Stacktrace。 导致这种情况的原因以及如何进行正确的堆转储？ Dumping heap to dump.bin … Exception in thread “main” java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at sun.tools.jmap.JMap.runTool(JMap.java:201) at sun.tools.jmap.JMap.main(JMap.java:130) Caused by: java.lang.InternalError: Metadata does not appear to be polymorphic at sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:278) at sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) at sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:68) at sun.jvm.hotspot.memory.DictionaryEntry.klass(DictionaryEntry.java:71) at sun.jvm.hotspot.memory.Dictionary.classesDo(Dictionary.java:66) at sun.jvm.hotspot.memory.SystemDictionary.classesDo(SystemDictionary.java:190) at sun.jvm.hotspot.memory.SystemDictionary.allClassesDo(SystemDictionary.java:183) at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClasses(HeapHprofBinWriter.java:942) at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:427) at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62) […]

使用-XX：HeapDumpPath选项但希望集成进程ID

使用-XX:+HeapDumpOnOutOfMemoryError ，如果指定路径下已存在转储文件，则JVM不会覆盖堆转储。 我希望能够在非默认位置拥有多个堆转储，并且计划在堆转储路径中使用pid以允许它。 但是，当我试图像这样指定参数时： -XX:HeapDumpPath=some/heapdump/path/heapdump-%p.hprof 然后创建了一个堆转储，我得到%p而不是文件名中的实际pid。 但是， %p的使用似乎与-XX:OnOutOfMemoryError选项一起使用。 是否有一些我应该用于-XX:HeapDumpPath=其他语法-XX:HeapDumpPath= ？