您的位置: 首页  >  技术问答  >  Java有一个39G核心转储

Java有一个39G核心转储

分类: 技术问答 • 2022-09-20 17:54:38
问题描述：

我跑在solarix 86在WebLogic Server - 64的命令行：Java有一个39G核心转储

-Xrs -Xms4096m -Xmx4096m -XX:MaxPermSize=256m -da ...

所以最大堆大小应该是4G，经过一夜但是，它并坠毁生成的39G核心：

-bash-3.00$ ls -l core 
-rw------- 1 user group  39017429722 Sep 27 19:47 core

我用PMAP转储核心内容：

$ pmap core 
core 'core' of 21092: /opt/middleware/jdk1.6.0_21/bin/amd64/java -Xrs -Xms 
0000000000400000   52K r-x-- /opt/middleware/jdk1.6.0_21/bin/amd64/java 
000000000041C000   4K rw--- /opt/middleware/jdk1.6.0_21/bin/amd64/java 
000000000041D000 2226208K rw--- 
0000000088225000 2097152K rw--- 
0000000108225000 4194304K rw--- 
0000000208225000 8388608K rw--- 
0000000408225000 16777216K rw--- [ heap ] 
FFFFFD7EDF610000  512K rwx-- 
FFFFFD7EDF77A000   96K rw--- [ stack tid=147 ] 
FFFFFD7EDF87B000   96K rw--- [ stack tid=146 ] 
FFFFFD7EDF97C000   96K rw--- [ stack tid=145 ] 
FFFFFD7EDFA7D000   96K rw--- [ stack tid=144 ] 
..... 
    total  38102164K

正如你可以看到有一个16G HEA p在那边......为什么会发生这种情况？ java内存泄漏？

JMAP转储：

-bash-3.00$ /opt/middleware/jdk1.6.0_21/bin/jmap -heap /opt/middleware/jdk1.6.0_21/bin/java -d64 core 
Attaching to core core from executable /opt/middleware/jdk1.6.0_21/bin/java, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 17.0-b16 

using thread-local object allocation. 
Parallel GC with 4 thread(s) 

Heap Configuration: 
    MinHeapFreeRatio = 40 
    MaxHeapFreeRatio = 70 
    MaxHeapSize  = 4294967296 (4096.0MB) 
    NewSize   = 1310720 (1.25MB) 
    MaxNewSize  = 17592186044415 MB 
    OldSize   = 5439488 (5.1875MB) 
    NewRatio   = 2 
    SurvivorRatio = 8 
    PermSize   = 21757952 (20.75MB) 
    MaxPermSize  = 268435456 (256.0MB) 

Heap Usage: 
PS Young Generation 
Eden Space: 
    capacity = 1226899456 (1170.0625MB) 
    used  = 396823336 (378.44022369384766MB) 
    free  = 830076120 (791.6222763061523MB) 
    32.34359050852819% used 
From Space: 
    capacity = 104726528 (99.875MB) 
    used  = 2949120 (2.8125MB) 
    free  = 101777408 (97.0625MB) 
    2.816020025031289% used 
To Space: 
    capacity = 100728832 (96.0625MB) 
    used  = 0 (0.0MB) 
    free  = 100728832 (96.0625MB) 
    0.0% used 
PS Old Generation 
    capacity = 2864709632 (2732.0MB) 
    used  = 90771752 (86.56668853759766MB) 
    free  = 2773937880 (2645.4333114624023MB) 
    3.1686196390043064% used 
PS Perm Generation 
    capacity = 140509184 (134.0MB) 
    used  = 139181296 (132.73362731933594MB) 
    free  = 1327888 (1.2663726806640625MB) 
    99.05494576069846% used

附加信息：所以在这个核心加载的文件：

-bash-3.00$ grep so p.txt|sort -k 4 
FFFFFD7FFF3B2000  228K r-x-- /lib/amd64/ld.so.1 
FFFFFD7FFF3FB000   8K rwx-- /lib/amd64/ld.so.1 
FFFFFD7FFF3FD000   8K rwx-- /lib/amd64/ld.so.1 
FFFFFD7EE8100000   32K r-x-- /lib/amd64/libaio.so.1 
FFFFFD7EE8118000   4K rw--- /lib/amd64/libaio.so.1 
FFFFFD7EE8119000   4K rw--- /lib/amd64/libaio.so.1 
FFFFFD7FFF1F0000  1252K r-x-- /lib/amd64/libc.so.1 
FFFFFD7FFF339000   36K rw--- /lib/amd64/libc.so.1 
FFFFFD7FFF342000   16K rw--- /lib/amd64/libc.so.1 
FFFFFD7FFF350000   4K r-x-- /lib/amd64/libdl.so.1 
FFFFFD7FFF361000   4K rw--- /lib/amd64/libdl.so.1 
FFFFFD7FFE390000   8K r-x-- /lib/amd64/libdoor.so.1 
FFFFFD7FFE3A2000   4K rw--- /lib/amd64/libdoor.so.1 
FFFFFD7FFE1E0000   28K r-x-- /lib/amd64/libgen.so.1 
FFFFFD7FFE1F7000   4K rw--- /lib/amd64/libgen.so.1 
FFFFFD7FFE3E0000   16K r-x-- /lib/amd64/libm.so.1 
FFFFFD7FFE3F3000   4K rw--- /lib/amd64/libm.so.1 
FFFFFD7FFE250000  348K r-x-- /lib/amd64/libm.so.2 
FFFFFD7FFE2B6000   24K rw--- /lib/amd64/libm.so.2 
FFFFFD7FFE1C0000   48K r-x-- /lib/amd64/libmd.so.1 
FFFFFD7FFE1DC000   4K rw--- /lib/amd64/libmd.so.1 
FFFFFD7FFE1A0000   16K r-x-- /lib/amd64/libmp.so.2 
FFFFFD7FFE1B4000   4K rw--- /lib/amd64/libmp.so.2 
FFFFFD7FFE2C0000  664K r-x-- /lib/amd64/libnsl.so.1 
FFFFFD7FFE376000   16K rw--- /lib/amd64/libnsl.so.1 
FFFFFD7FFE37A000   36K rw--- /lib/amd64/libnsl.so.1 
FFFFFD7EE8120000   32K r-x-- /lib/amd64/librt.so.1 
FFFFFD7EE8138000   4K rw--- /lib/amd64/librt.so.1 
FFFFFD7FFE220000  100K r-x-- /lib/amd64/libscf.so.1 
FFFFFD7FFE249000   4K rw--- /lib/amd64/libscf.so.1 
FFFFFD7FFF190000   60K r-x-- /lib/amd64/libsocket.so.1 
FFFFFD7FFF1AF000   4K rw--- /lib/amd64/libsocket.so.1 
FFFFFD7FFF3A0000   20K r-x-- /lib/amd64/libthread.so.1 
FFFFFD7FFE200000   36K r-x-- /lib/amd64/libuutil.so.1 
FFFFFD7FFE219000   4K rw--- /lib/amd64/libuutil.so.1 
FFFFFD7FFF370000   36K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/jli/libjli.so 
FFFFFD7FFF388000   8K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/jli/libjli.so 
FFFFFD7EE80D0000   64K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libj2pkcs11.so 
FFFFFD7EE80EF000   4K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libj2pkcs11.so 
FFFFFD7FFDFE0000  188K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libjava.so 
FFFFFD7FFE01E000   12K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libjava.so 
FFFFFD7EE7DF0000   28K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libmanagement.so 
FFFFFD7EE7E06000   4K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libmanagement.so 
FFFFFD7EE82A0000   72K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libnet.so 
FFFFFD7EE82C1000   8K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libnet.so 
FFFFFD7EE8140000   32K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libnio.so 
FFFFFD7EE8157000   4K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libnio.so 
FFFFFD7FFE030000   68K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libverify.so 
FFFFFD7FFE050000   8K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libverify.so 
FFFFFD7FFDF70000   64K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libzip.so 
FFFFFD7FFDF8F000   12K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/libzip.so 
FFFFFD7FFDFC0000   40K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/native_threads/libhpi.so 
FFFFFD7FFDFD9000   4K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/native_threads/libhpi.so 
FFFFFD7FFDFDA000   20K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/native_threads/libhpi.so 
FFFFFD7FFE400000  12932K r-x-- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/server/libjvm.so 
FFFFFD7FFF0B2000  628K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/server/libjvm.so 
FFFFFD7FFF14F000  112K rw--- /opt/middleware/jdk1.6.0_21/jre/lib/amd64/server/libjvm.so 
FFFFFD7FFE3B0000   60K r-x-- /usr/lib/amd64/libCrun.so.1 
FFFFFD7FFE3CE000   8K rw--- /usr/lib/amd64/libCrun.so.1 
FFFFFD7FFE3D0000   24K rw--- /usr/lib/amd64/libCrun.so.1 
FFFFFD7EE8070000   28K r-x-- /usr/lib/amd64/libcryptoutil.so.1 
FFFFFD7EE8087000   8K rw--- /usr/lib/amd64/libcryptoutil.so.1 
FFFFFD7EE8090000  136K r-x-- /usr/lib/amd64/libpkcs11.so.1 
FFFFFD7EE80C2000   4K rw--- /usr/lib/amd64/libpkcs11.so.1 
FFFFFD7EE80C3000   4K rw--- /usr/lib/amd64/libpkcs11.so.1 
FFFFFD7FFF1C0000   4K r-x-- /usr/lib/amd64/libsched.so.1 
FFFFFD7EE8010000  304K r-x-- /usr/lib/security/amd64/pkcs11_softtoken_extra.so.1 
FFFFFD7EE806C000   12K rw--- /usr/lib/security/amd64/pkcs11_softtoken_extra.so.1
+1

我不认为命令行上的堆大小直接影响VM（不是您的代码）可以使用多少内存。 – 2010-09-28 17:11:23

+1

根据_jmap_，您的Java堆大约为4 GB。因此，您在_pmap_中看到的内容必须由其他内容使用，例如泄漏内存的本机代码（共享库）。您是否正在使用任何共享库（除了VM加载的那个）？ – Codo 2010-09-28 17:29:18

+0

甚至JRE本机库可能会泄漏内存。这对于Java开发人员来说非常令人沮丧，因为他们不应该在JVM下挖掘。需要一个更接近金属的记忆分析工具来确定谁在吃掉记忆。 – irreputable 2010-09-28 18:03:25

答

-Xmx4096m为Java堆的大小。 核心转储是关于整个java虚拟机地址空间的过程。

根据操作系统的不同，您可以获得比预期更大的虚拟寻址空间。所以转储可能会更大。

例如，WindowsXP对于每个进程都有4GB的地址空间，即使在256MB的RAM上运行也是如此。

我认为核心转储大小取决于Java VM + O.S.。实现。例如，Solaris和Linux核心转储完全没有共同之处。

UPDATE： 两个选项： 您在使用本机库（即非标准的东西）？ 如果这样禁用本地扩展并进行一些测试。禁用Java NIO也可以提供帮助。如果你使用的是普通的vanilla WebLogic，试试你的支持：64位它在大型部署中并不常见（而且），而且你似乎有很大的一个（你有很多RAM，然后我甚至看到:)

+0

是的，我明白这部分..但我试图找到原因。似乎有些本地部分正在泄漏内存...... – Shawn 2010-10-01 00:45:59

+0

谢谢..我也对我们的部署感到惊讶 - 需要太多的内存。无论如何，这是一个历史问题。我想要求Oracle支持是我唯一的选择 – Shawn 2010-10-04 19:31:16

相关推荐