mémoire insuffisante pour que Java Runtime Environment continue à fonctionner RAM montre 6 Go d'espace libre
Lors de l'exécution de l'application Java, je reçois le vidage de mémoire suivant.
Après avoir installé Java 8 (avec Java 7, l'application fonctionnait auparavant), j'ai commencé à obtenir l'erreur ci-dessous.
J'utilise 16 Go RAM et dans le gestionnaire de tâches, lorsque j'ai vérifié (au démarrage de l'application), environ 6 Go RAM était libre.
Quelqu'un pourrait-il s'il vous plaît aider ce qui pourrait être le problème?
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 472736 bytes for Chunk::new
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32 bit mode, the process size limit was hit
# 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=
# This output file may be truncated or incomplete.
#
# Out of Memory Error (allocation.cpp:390), pid=1104, tid=0x00000000000016ec
#
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode windows-AMD64 compressed oops)
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
--------------- T H R E A D ---------------
---------------------------------------------------
Java Threads: ( => current thread )
0x00000000232a8800 JavaThread "AWSessionMonitor Thread" daemon [_thread_blocked, id=14084, stack(0x0000000022b20000,0x0000000022c20000)]
0x0000000028728800 JavaThread "Thread-3" [_thread_blocked, id=11332, stack(0x00000000210b0000,0x00000000211b0000)]
0x00000000252a4800 JavaThread "Thread-2" [_thread_blocked, id=5272, stack(0x0000000020fb0000,0x00000000210b0000)]
0x000000001e874000 JavaThread "SQLStatementMonitor" [_thread_blocked, id=1876, stack(0x0000000022620000,0x0000000022720000)]
0x000000001de0d800 JavaThread "Thread-1" daemon [_thread_blocked, id=13052, stack(0x0000000022520000,0x0000000022620000)]
0x000000001f7f8000 JavaThread "Session Timeout Thread" daemon [_thread_blocked, id=11088, stack(0x0000000022220000,0x0000000022320000)]
0x0000000002c11800 JavaThread "DestroyJavaVM" [_thread_blocked, id=14168, stack(0x0000000002a00000,0x0000000002b00000)]
0x000000001f32b800 JavaThread "Thread-0" [_thread_in_vm, id=10720, stack(0x0000000020bc0000,0x0000000020cc0000)]
0x000000001fb3e800 JavaThread "Perf_Log_Traceplan-" daemon [_thread_blocked, id=2992, stack(0x0000000020ac0000,0x0000000020bc0000)]
0x0000000020319800 JavaThread "Perf_Log_Traceperf-" daemon [_thread_blocked, id=6176, stack(0x00000000209c0000,0x0000000020ac0000)]
0x000000001da8b000 JavaThread "Service Thread" daemon [_thread_blocked, id=9968, stack(0x000000001e020000,0x000000001e120000)]
0x000000001da64000 JavaThread "C1 CompilerThread2" daemon [_thread_blocked, id=12708, stack(0x000000001df20000,0x000000001e020000)]
0x000000001c13e000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=10652, stack(0x000000001de20000,0x000000001df20000)]
=>0x000000001c128000 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=5868, stack(0x000000001d920000,0x000000001da20000)]
0x000000001c118000 JavaThread "JDWP Event Helper Thread" daemon [_thread_blocked, id=12444, stack(0x000000001d820000,0x000000001d920000)]
0x000000001c10c000 JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_native, id=2640, stack(0x000000001d720000,0x000000001d820000)]
0x000000001c100800 JavaThread "Attach Listener" daemon [_thread_blocked, id=9952, stack(0x000000001d620000,0x000000001d720000)]
0x000000001c0ff800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=13880, stack(0x000000001d520000,0x000000001d620000)]
0x000000001c0e6000 JavaThread "Finalizer" daemon [_thread_blocked, id=7868, stack(0x000000001d340000,0x000000001d440000)]
0x000000001c0bd000 JavaThread "Reference Handler" daemon [_thread_blocked, id=11580, stack(0x000000001d240000,0x000000001d340000)]
Other Threads:
0x000000001c0b3800 VMThread [stack: 0x000000001d140000,0x000000001d240000] [id=12984]
0x000000001db42800 WatcherThread [stack: 0x000000001e120000,0x000000001e220000] [id=9136]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap:
PSYoungGen total 524800K, used 42318K [0x000000076c580000, 0x000000078cf80000, 0x00000007c0000000)
eden space 515584K, 8% used [0x000000076c580000,0x000000076eed3b10,0x000000078bd00000)
from space 9216K, 0% used [0x000000078bd00000,0x000000078bd00000,0x000000078c600000)
to space 8704K, 0% used [0x000000078c600000,0x000000078c600000,0x000000078ce80000)
ParOldGen total 99328K, used 24647K [0x00000006c5000000, 0x00000006cb100000, 0x000000076c580000)
object space 99328K, 24% used [0x00000006c5000000,0x00000006c6811d80,0x00000006cb100000)
Metaspace used 22833K, capacity 23012K, committed 23344K, reserved 1071104K
class space used 2715K, capacity 2786K, committed 2864K, reserved 1048576K
Card table byte_map: [0x00000000120c0000,0x00000000128a0000] byte_map_base: 0x000000000ea98000
Marking Bits: (ParMarkBitMap*) 0x0000000069bf64f0
Begin Bits: [0x00000000131e0000, 0x00000000170a0000)
End Bits: [0x00000000170a0000, 0x000000001af60000)
Polling page: 0x00000000024b0000
CodeCache: size=245760Kb used=11544Kb max_used=11559Kb free=234215Kb
bounds [0x0000000002d00000, 0x0000000003860000, 0x0000000011d00000]
total_blobs=2659 nmethods=2233 adapters=346
compilation: enabled
Compilation events (10 events):
Event: 191.393 Thread 0x000000001da64000 2532 3 org.Apache.xerces.util.XMLAttributesImpl::checkDuplicatesNS (278 bytes)
Event: 191.393 Thread 0x000000001c13e000 2535 4 org.Apache.xerces.impl.XMLEntityScanner::scanQName (510 bytes)
Event: 191.394 Thread 0x000000001da64000 nmethod 2532 0x0000000003825d10 code [0x0000000003825f60, 0x0000000003826d38]
Event: 191.394 Thread 0x000000001da64000 2530 3 org.Apache.xerces.impl.xs.opti.SchemaDOM::emptyElement (23 bytes)
Event: 191.394 Thread 0x000000001da64000 nmethod 2530 0x00000000037d66d0 code [0x00000000037d6840, 0x00000000037d6a98]
Event: 191.394 Thread 0x000000001da64000 2533 3 org.Apache.xerces.impl.xs.opti.SchemaDOM::startElement (29 bytes)
Event: 191.395 Thread 0x000000001da64000 nmethod 2533 0x00000000037fb4d0 code [0x00000000037fb640, 0x00000000037fb8b8]
Event: 191.395 Thread 0x000000001da64000 2534 3 org.Apache.xerces.impl.xs.opti.SchemaDOM::endElement (30 bytes)
Event: 191.395 Thread 0x000000001da64000 nmethod 2534 0x0000000003825750 code [0x00000000038258c0, 0x0000000003825b90]
Event: 191.423 Thread 0x000000001c13e000 nmethod 2535 0x000000000384fe10 code [0x0000000003850000, 0x0000000003850fe0]
--------------- S Y S T E M ---------------
OS: Windows 8.1 , 64 bit Build 9600 (6.3.9600.17415)
CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 58 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, erms, ht, tsc, tscinvbit, tscinv
Memory: 4k page, physical 16442864k(1810952k free), swap 19025808k(6260k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (25.92-b14) for windows-AMD64 JRE (1.8.0_92-b14), built on Mar 31 2016 21:03:04 by "Java_re" with MS VC++ 10.0 (VS2010)
time: Mon May 23 12:38:20 2016
elapsed time: 191 seconds (0d 0h 3m 11s)
Java, par défaut, n'utilise pas toute la mémoire disponible. Vous devez exécuter l'application avec les paramètres correspondants.
Voir cette question à tous les détails. (Cela peut changer avec la version de Java).
Le paramètre peut être défini sur la ligne de commande, mais si vous utilisez une application, vous pouvez avoir un fichier de configuration. Par exemple, dans Eclipse, vous avez Eclipse.ini où vous pouvez définir vos préférences de mémoire.
Certains programmes utilisent beaucoup de mémoire, comme Elasticsearch, essayez d’ajouter de la mémoire si vous utilisez ce type de programme gourmand en mémoire.
Je recevais des vidages de mémoire similaires lors de l'exécution de la même application Java sous Windows 10 et 8.1 (les deux 64 bits).
Windows 8.1
32 Go de RAM
i7-4790 3.60GHz CPU
Taille du fichier de pagination (fixe, 14 Go)
Windows 10
16 Go de RAM
i7-4790 3.60GHz CPU
Taille du fichier de pagination (automatiquement gérée, initialement fixée, 14 Go)
1er problème: avec un matériel identique (différence entre RAM et système d'exploitation uniquement), l'application sur Windwos 10 se bloquait presque instantanément . La chose la plus surprenante est que, dans le Gestionnaire des tâches, je ne voyais que 25% de RAM est utilisé.
Après avoir recherché des informations dans google, j'ai constaté que:
- Je dois définir un fichier de pagination géré automatiquement pour Windows 10.
- Windows 10 est plus gourmand en mémoire dédiée que les versions précédentes de Windows .
2ème numéro
Comme l'a mentionné @borjab
Java, par défaut, n'utilise pas toute la mémoire disponible.
Pour obtenir une aide sur les options non standard pour le type Java dans votre CMD:
Java -X
Sortie:
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
<size> peut être défini dans
G - Gigabytes
M - Megabytes
K - Kilobytes
La solution finale pour les deux OS était la suivante:
Java -Xmx15G -Xms15G -jar Selenium-server-standalone-3.4.0.jar
Ma version Java initiale
Version Java "1.8.0_91"
Environnement d'exécution Java SE (version 1.8.0_91-b14)
Serveur Java HotSpot (TM) 64 bits VM (version 25.91-b14, mode mixte)
Version Java mise à jour
Version Java "1.8.0_152"
Environnement d'exécution Java SE (version 1.8.0_152-b16)
Serveur Java HotSpot (TM) 64 bits VM (version 25.152-b16, mode mixte)
Par défaut, votre application n'utilise pas toute la mémoire système disponible (ou RAM). La limite dépend de la valeur xmx que vous avez définie.
Vous ne savez pas si l'option 64 bits est une option pour vous; si c'est le cas, cela vous permet d'augmenter votre xmx plus que la version 32 bits.