web-dev-qa-db-fra.com

Échec de mappage de l'allocation de mémoire native (mmap)

J'ai commencé à faire face à un problème d'allocation de mémoire native. Je suppose que cela pourrait être lié aux paramètres -Xmx et -Xms. Quelle est la méthode recommandée pour définir ces valeurs?

Actuellement, j'ai: -Xmx13G -Xms6G 

J'ai lu qu'il est recommandé de définir les mêmes valeurs mais sans expliquer pourquoi.

L'erreur que je reçois est la suivante:

    # 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
3
Juan Cesar Villalba

Vous demandez clairement beaucoup plus que ce qui est physiquement disponible sur votre système. Vous avez un total de 16 Go, mais 90% de son utilisation est effective et vous ne disposez d'aucun espace d'échange. Il est donc impossible que vous obteniez -Xms6G, sans parler de davantage (-Xmx13G). 

Vous devez déterminer quels autres processus consomment de la mémoire en utilisant, par exemple, top et trier par mémoire résidente (lettre majuscule O, puis q) et en arrêter suffisamment pour libérer au moins 6 Go avant d'exécuter votre machine virtuelle 

Cela, ou doublez votre mémoire physique à 32 Go, ou ajoutez 16 Go d’échange (mais cela pourrait entraîner une compression si le système est lourdement chargé).

5
Jim Garrison

Jim Garrison a bien expliqué la raison pour laquelle op est confronté à ce problème.

Je voudrais aborder une question secondaire de l'op:

J'ai lu qu'il est recommandé de définir les mêmes valeurs mais sans aucun explication de pourquoi.

En gros, la machine virtuelle alloue tout ce que vous avez mis dans -Xms dès son démarrage, puis croît selon les besoins en -Xmx; une fois atteinte, elle passe à la corbeille (ne vide plus les objets utilisés).

Exécuter GC sur de nombreux objets (ici une valeur de 7 Go d’objets) n’est pas une bonne idée car cela prendra du temps et beaucoup de ressources. Il est correct de leur attribuer la même valeur, car la collecte de GC est effectuée en cours de route. Le GC a des opérations "stop-the-world", dans lesquelles rien d’autre ne peut fonctionner pendant la collecte des ordures. Maintenant, imaginez nettoyer 7 Go de déchets, cela va prendre un temps non négligeable et causer de longues pauses.

Vous devriez vraiment lire https://docs.Oracle.com/javase/8/docs/technotes/guides/vm/gctuning/introduction.html

1
thecarpy