Native memory allocation (mmap) failed to map

倖福魔咒の 提交于 2021-02-17 21:38:40

问题


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 ?

Currently I have: -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)

回答1:


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 -Xms6G let alone more (-Xmx13G).

You need to figure out what other processes are consuming memory using, for instance, top and 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.

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).




回答2:


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=



回答3:


Jim Garrison provided a good answer as to why op is getting that issue.

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 -Xms as soon as the JVM starts, then grow as required to -Xmx, once that is reached, it goes garbage collecting (flushing things no longer used).

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.

You really should read https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/introduction.html



来源:https://stackoverflow.com/questions/48592602/native-memory-allocation-mmap-failed-to-map

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!