Tag: jmap

Jmap堆转储，是否包括年轻一代？

快问 jmap堆转储是仅包含旧代，还是年轻代？ 很长的解释 我有2个堆转储（ jmap -heap:format=b 9999 ）： 我的一台服务器没有加载（没有HTTP请求） 一个工作50％CPU，高负载（基准测试） 现在，第一个转储显示的堆大小比第二个大 （我认为这很奇怪）。 可能是因为Young Generation（高负载）经常变化，因为垃圾收集器经常运行（是的，JVM几乎已满）？ 老一代人满99％，我注意到年轻一代的空间使用量差异很大。 因此，这意味着我在GC完成工作后立即进行了第二次转储，这就是为什么它的尺寸更小。 我对吗 ？ 附加信息 ： Java args： -XX:+UseParallelGC -XX:+AggressiveHeap -Xms2048m -Xmx4096m -XX:NewSize=64m -XX:PermSize=64m -XX:MaxPermSize=512m

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

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

垃圾收集器第一和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 […]

使用JMAP获取heapdump时出现exception

当我使用heapdump时，我得到以下exception jmap -F -dump：format = b，file = / tmp / heapdump / before.hprof 10737 Attaching to process ID 10737, please wait… Exception in thread “main” java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.tools.jmap.JMap.runTool(JMap.java:179) at sun.tools.jmap.JMap.main(JMap.java:110) Caused by: java.lang.RuntimeException: Type “nmethodBucket*”, referenced in VMStructs::localHotSpotVMStructs in the remote VM, was not present in […]

为什么我的Java堆转储大小比使用的内存小得多？

问题 我们试图在我们的Web应用程序中找到大内存泄漏的罪魁祸首。 我们在查找内存泄漏方面经验非常有限，但我们发现了如何使用jmap创建Java堆转储并在Eclipse MAT中对其进行分析。 但是，在我们的应用程序使用56 / 60GB内存时，堆转储的大小只有16GB，在Eclipse MAT中甚至更少。 上下文 我们的服务器在Ubuntu 14.04上使用Wildfly 8.2.0作为我们的Java应用程序，其进程使用95％的可用内存。 进行转储时，我们的缓冲区/缓存已用空间为56GB。 我们使用以下命令创建转储： sudo -u {application user} jmap -dump:file=/mnt/heapdump/dump_prd.bin {pid} 堆转储文件大小为16,4GB，当使用Eclipse MAT进行分析时，它表示有大约1GB的活动对象和大约14,8GB的无法访问/浅堆。 编辑：这里有一些关于我们看到的问题的更多信息。 我们监视我们的内存使用情况，我们看到它的增长和增长，直到剩下约300mb的可用内存。 然后它保持在那个内存量附近，直到进程崩溃，遗憾的是应用程序日志中没有错误。 这使我们假设它是一个硬OOM错误，因为这只发生在内存接近耗尽时。 我们为JVM使用-Xms25000m -Xmx40000m设置。 题 基本上，我们想知道为什么我们的大部分内存都没有在这个转储中被捕获。 顶部保留的大小类看起来并不太可疑，所以我们想知道是否存在与堆转储有关的问题我们做错了什么。

使用死Groovy代码定位填充PermGen的代码

我们已经使用java.lang.OutOfMemoryError: PermGen space每两周对我们的glassfish实例进行一段时间的研究。 我将PermGen空间增加到512MB，并使用jstat -gc转储内存使用量。 两周后，我想出了下图，显示了PermGen空间是如何稳定增加的（x轴上的单位是分钟，y轴是KB）。 我试着用谷歌搜索某种可以查明错误的分析工具，并在SO上提到了一个提到jmap的post，这被certificate是非常有用的。 在从jmap -permstats $PID转储的大约14000行中，大约12500行包含groovy/lang/GroovyClassLoader$InnerLoader ，指向我们自己的Groovy代码或Groovy本身的某种内存泄漏。 我必须指出，Groovy构造的相关代码库不到1％。 示例输出如下： class_loader classes bytes parent_loader alive? type 3811 14830264 null live 0x00007f3aa7e19d20 20 164168 0x00007f3a9607f010 dead groovy/lang/GroovyClassLoader$InnerLoader@0x00007f3a7afb4120 0x00007f3aa7c850d0 20 164168 0x00007f3a9607f010 dead groovy/lang/GroovyClassLoader$InnerLoader@0x00007f3a7afb4120 0x00007f3aa5d15128 21 181072 0x00007f3a9607f010 dead groovy/lang/GroovyClassLoader$InnerLoader@0x00007f3a7afb4120 0x00007f3aad0b40e8 36 189816 0x00007f3a9d31fbf8 dead org/apache/jasper/servlet/JasperLoader@0x00007f3a7d0caf00 …. 那么我该如何继续了解更多关于导致此问题的代码？ 在本文中，我推断我们的Groovy代码是在某处动态创建类。 从jmap的转储我可以看到大多数死对象/类（？）都有相同的parent_loader，虽然我不确定在这种情况下这意味着什么。 我不知道怎么从这里开始。 附录 对于后来者来说，值得指出的是， 接受的答案并不能解决问题 […]

是JVM在执行jmap时停止了吗？

当jmap进行内存转储时，我的java应用程序是否继续运行？ 谢谢

当使用live选项时，jmap是否强制进行垃圾收集？

我今天一直在尝试使用jmap -histo和jmap -dump 按此顺序运行时 jmap -dump:format=b,file=heap.1 [pid] jmap -dump:live,format=b,file=heap.2 [pid] jmap -dump:format=b,file=heap.3 [pid] heap.3比heap.1 。 特别是，我在heap.1中感兴趣的“死”对象在heap.1中不存在。 看到这个，我开始寻找可以告诉我应该期待的文档。 我最接近的是这次讨论 ，来自briand和alanb的评论意味着在实践中我可以预期当我使用live选项时会发生这个GC; 但答案是五年了，论坛上的post对于规范来说似乎有些不正式。 我在哪里可以找到记录的当前行为？

使用gcore进行核心转储，jmap转换为hprof文件格式失败，并显示错误消息

我们最近遇到了一个JVM崩溃，留下了gcore命令生成的核心转储文件。 我们想看一下文件的内容，找出导致崩溃的确切原因。 使用jmap命令，您应该能够将核心转储文件转换为hprof文件格式的文件，然后您可以使用VisualVM和许多其他工具进行分析。 我试过这个并收到错误信息。 这是我运行的命令（在崩溃发生的同一个框中，使用相同的JVM）： jmap -dump:format=b,file=dump.hprof /usr/java/jdk1.6.0_16/bin/java core.dump.2878 整个回应是： > Attaching to core core.dump.8483 from executable /usr/java/jdk1.6.0_16/bin/java, please wait… > Error attaching to core file: Can’t attach to the core file 这不是一个非常有用的错误消息。 我想知道它是否是一个权限问题，但是我得到了运行该命令的相同消息，就像运行导致核心转储的JVM一样。 我也想知道核心文件是否已损坏，所以我决定使用gdb来查看是否可以打开核心文件并查看其中的内容。 这就是我得到的： > gdb GNU gdb（GDB）红帽企业Linux（7.0.1-37.el5_7.1） 许可证GPLv3 +：GNU GPL版本3或更高版本 这是免费软件：您可以自由更改并重新分发它。 在法律允许的范围内，不提供任何担保。 输入“显示复制” 和“显示保修”的详细信息。 此GDB配置为“x86_64-redhat-linux-gnu”。 有关错误报告说明，请参阅： 。 （gdb）core-file core.dump.8483 [新主题2889] [新主题2893] [新主题2894] […]