Aru*_*run 7 java memory heap jmap
在少数情况下,我们的应用程序使用大约12 GB的内存.我们尝试使用jmap实用程序获取堆转储.由于应用程序使用了一些GB内存,因此会导致应用程序停止响应并导致生产中出现问题.
在我们的例子中,堆使用量在6小时内突然从2-3 GB增加到12 GB.为了找到内存使用趋势,我们尝试在重新启动应用程序后每隔一小时收集一次堆转储.但正如所说,因为使用jmap导致应用程序挂起,我们需要重新启动它,我们无法获得内存使用的趋势.
有没有办法在不挂起应用程序的情况下获取堆转储,或者是否有除jmap之外的实用程序来收集堆转储.
关于这一点的想法受到高度赞赏,因为没有得到内存使用的趋势,很难解决这个问题.
注意:我们的应用程序在CentOS中运行.
谢谢,阿伦
请尝试以下方法.它带有JDK> = 7:
/usr/lib/jvm/jdk-YOUR-VERSION/bin/jcmd PID GC.heap_dump FILE-PATH-TO-SAVE
例:
/usr/lib/jvm/jdk1.8.0_91/bin/jcmd 25092 GC.heap_dump /opt/hd/3-19.11-jcmd.hprof
这个转储过程比使用jmap转储要快得多!Dumpfiles要小得多,但它足以让你的想法,泄漏的地方.
在撰写此答案时,Memory Analyzer和IBM HeapAnalyzer存在一些错误,他们无法从jmap(jdk8,大文件)读取转储文件.您可以使用Yourkit读取这些文件.
首先，（据我所知）在进行线程转储/快照时冻结 JVM 是非常重要的。如果 JVM 在创建快照时能够继续运行，则几乎不可能获得一致的快照。
那么还有其他方法来获取堆转储吗？
但所有这些都必然会导致 JVM（至少）暂停。
如果您的应用程序实际上挂起（永久！），这听起来像是您的应用程序本身的问题。我的建议是在查找存储泄漏之前看看是否可以找到该问题。
我的另一个建议是，您查看单个堆转储，并使用统计信息来找出哪种对象正在使用所有空间……以及为什么它们是可访问的。您很可能根本不需要“趋势”信息。
| 归档时间： |
|
| 查看次数： |
13819 次 |
| 最近记录： |