Java 本机内存分配 (mmap) 无法映射
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/48592602/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Native memory allocation (mmap) failed to map
提问by Juan Cesar Villalba
I have started facing Native memory allocation issue. I guess could be related with the -Xmx and -Xms settings. What is the recommended way to set this values ?
我已经开始面临本机内存分配问题。我想可能与 -Xmx 和 -Xms 设置有关。设置此值的推荐方法是什么？
Currently I have: -Xmx13G -Xms6G
目前我有：-Xmx13G -Xms6G
I read that is recommended to set same values but without any explanation of why.
我读到建议设置相同的值，但没有解释原因。
The error I am getting is :
我得到的错误是：
# 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)
回答by Jim Garrison
You are clearly asking for a lot more than is physically available on your system. You have 16GB total but it's 90% in use, and you don't have any swap space, so there's no way you're getting -Xms6Glet alone more (-Xmx13G).
显然，您要求的比系统上实际可用的要多得多。您总共有 16GB，但 90% 正在使用中，而且您没有任何交换空间，因此您不可能-Xms6G更不用说更多 ( -Xmx13G)。
You need to figure out what other processes are consuming memory using, for instance, topand sort by resident memory (upper-case letter O, then q), and stop enough of them to free up at least 6GB before running your JVM.
例如，您需要弄清楚哪些其他进程正在使用内存，top并按常驻内存（大写字母O，然后是q）排序，并在运行 JVM 之前停止足够多的进程以释放至少 6GB 的空间。
That, or double your physical memory to 32GB, or add 16GB of swap (but that could result in thrashing if the system is heavily loaded).
那，或者将你的物理内存加倍到 32GB，或者增加 16GB 的交换空间（但如果系统负载很重，这可能会导致颠簸）。
回答by thecarpy
Jim Garrison provided a good answer as to why op is getting that issue.
Jim Garrison 提供了一个很好的答案，说明为什么 op 会遇到这个问题。
I would like to address a secondary question of the op:
我想解决操作的第二个问题：
I read that is recommended to set same values but without any explanation of why.
我读到建议设置相同的值，但没有解释原因。
Basically, the JVM will allocate whatever you put in -Xmsas soon as the JVM starts, then grow as required to -Xmx, once that is reached, it goes garbage collecting (flushing things no longer used).
基本上，JVM 将-Xms在 JVM 启动后立即分配您放入的任何内容，然后根据需要增长-Xmx，一旦达到，它就会进行垃圾收集（刷新不再使用的东西）。
Running GC on lots of objects (here 7Gb worth of objects) is not a good idea because it will take time and a lot of resources. Setting them to the same value is OK, as GC is collected along the way. GC has operations that are "stop-the-world", where nothing else can run while garbage is collected. Now imagine cleaning up 7Gb of garbage, that is going to take a non-negligible amount of time and cause long pauses.
对大量对象（此处为 7Gb 的对象）运行 GC 不是一个好主意，因为这需要时间和大量资源。将它们设置为相同的值是可以的，因为在此过程中会收集 GC。GC 具有“stop-the-world”的操作，在收集垃圾时没有其他任何东西可以运行。现在想象一下清理 7Gb 的垃圾，这将花费不可忽略的时间并导致长时间的停顿。
You really should read https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/introduction.html
你真的应该阅读https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/introduction.html
回答by Vishrant
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=
