本机内存分配（mmap）无法映射

Question

我已经开始面临Native内存分配问题了。我想可能与-Xmx和-Xms设置有关。设置此值的推荐方法是什么？

目前我有：-Xmx13G -Xms6G

我读过，建议设置相同的值但不解释原因。

我得到的错误是：

    # There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 746061824 bytes for committing reserved memory.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (os_linux.cpp:2627), pid=13528, tid=0x00007f2b0b5f5700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_101-b13) (build 1.8.0_101-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.101-b13 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#

/proc/meminfo:
MemTotal:       16433112 kB
MemFree:          166336 kB
Buffers:          114324 kB
Cached:           398396 kB
SwapCached:            0 kB
Active:         15151496 kB
Inactive:         254348 kB
Active(anon):   14893020 kB
Inactive(anon):      604 kB
Active(file):     258476 kB
Inactive(file):   253744 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                12 kB
Writeback:             0 kB
AnonPages:      14892976 kB
Mapped:            24024 kB
Shmem:               696 kB
Slab:             349384 kB
SReclaimable:     187700 kB
SUnreclaim:       161684 kB
KernelStack:       43520 kB
PageTables:       276768 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8216556 kB
Committed_AS:   33089080 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       31404 kB
VmallocChunk:   34359652884 kB
HardwareCorrupted:     0 kB
AnonHugePages:  13486080 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       28672 kB
DirectMap2M:    16879616 kB

Memory: 4k page, physical 16433112k(166336k free), swap 0k(0k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (25.101-b13) for linux-amd64 JRE (1.8.0_101-b13), built on Jun 22 2016 02:59:44 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)

Answer 1

您显然需要的不仅仅是系统中可用的物理数据。你有16GB的总数，但它使用了90％，你没有任何交换空间，所以你不可能得到更多的-Xms6G（-Xmx13G）。

您需要弄清楚其他进程正在消耗内存，例如，使用top并按驻留内存排序（大写字母O，然后q），并在运行JVM之前停止足够的内存以释放至少6GB。

那，或者你的物理内存加倍到32GB，或者增加16GB的交换（但如果系统负载很重，可能会导致颠簸）。

Answer 2

Jim Garrison提供了一个很好的答案，为什么op正在解决这个问题。

我想谈谈op的第二个问题：

我读过，建议设置相同的值但不解释原因。

基本上，一旦JVM启动，JVM将分配你在-Xms中放置的任何内容，然后根据需要增长到-Xmx，一旦达到，它就会进行垃圾收集（不再使用冲洗的东西）。

在许多对象上运行GC（这里有7Gb的对象）并不是一个好主意，因为它需要时间和大量资源。将它们设置为相同的值是正常的，因为GC是沿途收集的。 GC具有“停止世界”的操作，在收集垃圾时没有其他任何东西可以运行。现在想象清理7Gb的垃圾，这将花费不可忽视的时间并导致长时间的停顿。

你真的应该阅读https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/introduction.html

Answer 3

Possible solutions:

  Reduce memory load on the system
  Increase physical memory or swap space
  Check if swap backing store is full
  Use 64 bit Java on a 64 bit OS
  Decrease Java heap size (-Xmx/-Xms)
  Decrease number of Java threads
  Decrease Java thread stack sizes (-Xss)
  Set larger code cache with -XX:ReservedCodeCacheSize=