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

这些类型的错误不仅会因为堆空间总量耗尽而发生，而且当内存映射区域的数量耗尽时也会发生。

在 Linux 中，每个进程的最大映射区域数由 vm.max_map_count sysctl 参数控制（默认为 65536）。因此，例如，我会尝试将其加倍并检查会发生什么：

sysctl -w vm.max_map_count=131072

当堆转储列出了大量开放的 mmap 区域（在“动态库”部分下）时，表明您遇到了此问题

Answer 4

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=

Answer 5

对于按几个 G 的顺序分配的 VM，在这种情况下 (-Xmx13G -Xms6G)
在 Linux 上你可以使用大页面（2M 页面大小而不是常规的 4K）

-XX:+UseLargePages

这大大减少了计入 max_map_count 限制的内存段数量，并且还减少了虚拟内存转换开销。

请参阅 Oracle 文档：

vmoptions：https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html
大内存页：https://www.oracle.com/java/technologies/javase/largememory-pages.html

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

5 个答案: