Fatal编程技术网
  • java/
  • Java有一个39G内核转储

Java有一个39G内核转储

java jvm

Java有一个39G内核转储,java,jvm,solaris,coredump,Java,Jvm,Solaris,Coredump,我使用命令行在solarix x86-64位上运行weblogic服务器： -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'

我使用命令行在solarix x86-64位上运行weblogic服务器：

-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的堆……为什么会发生这种情况？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
-Xmx4096m是java堆的大小。 核心转储是关于整个java虚拟机地址空间进程的

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

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

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

更新： 两种选择： 您是否使用本机库（即非标准库）？ 如果是，请禁用本机扩展并执行一些测试。禁用JavaNIO也会有所帮助

如果您使用的是普通的WebLogic，请尝试您的支持：64位在大型部署中并不常见，而且您似乎有一个非常大的支持（您有很多RAM，我甚至看到：）

我不认为命令行上的堆大小直接影响VM（而不是您的代码）可以使用多少内存，您的Java堆大约为4GB。因此，您在pmap中看到的内容必须被其他东西使用，例如泄漏内存的本机代码（共享库）。您是否使用任何共享库（除了VM加载的库之外）？即使是JRE本机库也可能泄漏内存。这对java开发人员来说非常令人沮丧，因为他们不应该在JVM下挖掘。需要一个更接近金属的内存分析工具来找出谁在消耗内存。这也是我的怀疑…weblogic有一些本机库，让我检查它们中的任何一个是否已加载…-Xms和-Xmx仅限制堆大小。还有另一个内存区域（堆栈和其他）可以在没有控制的情况下成长…是的，我理解这一部分。。但我正在努力寻找原因。似乎一些本机部分正在泄漏内存…谢谢..我也对我们的部署感到惊讶--需要这么多内存。无论如何，这是一个历史问题。我想请求Oracle支持是我唯一的选择