web-dev-qa-db-ja.com

ネイティブメモリ割り当て（mmap）のマッピングに失敗しました

ネイティブメモリ割り当ての問題に直面し始めました。 -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)
javaout-of-memory
8
Juan Cesar Villalba

システムで物理的に利用できる以上のことを明らかに求めています。合計16GBありますが、使用率は90％であり、スワップスペースがありません。したがって、-Xms6G言うまでもなく（-Xmx13G）。

topなどを使用してメモリを消費している他のプロセスを把握し、常駐メモリ（大文字のO、次にq）でソートして停止する必要があります。 JVMを実行する前に少なくとも6GBを解放するのに十分です。

または、物理メモリを2倍にして32 GBにするか、16 GBのスワップを追加します（ただし、システムの負荷が高い場合はスラッシングが発生する可能性があります）。

7
Jim Garrison

ジムギャリソンは、なぜopがその問題を抱えているのかについて良い答えを提供しました。

私はopの二次的な質問に対処したいと思います：

同じ値を設定することをお勧めしますが、理由の説明はありません。

基本的に、JVMは、-Xms JVMが起動するとすぐに、必要に応じて-Xmx、一度到達すると、ガベージコレクションが行われます（使用されなくなったものをフラッシュします）。

多くのオブジェクト（ここでは7Gb相当のオブジェクト）でGCを実行するのは、時間がかかり、多くのリソースが必要になるため、お勧めできません。 GCは途中で収集されるため、同じ値に設定しても問題ありません。 GCには、「世界を停止する」操作があります。この操作では、ガベージが収集されている間は何も実行できません。ここで、7GBのゴミのクリーンアップを想像してください。これは無視できない量の時間を費やし、長い休止を引き起こすことになります。

本当に読む必要があります https://docs.Oracle.com/javase/8/docs/technotes/guides/vm/gctuning/introduction.html

1
thecarpy
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=
0
Vishrant