Java OutOfMemory eccezione: Errore di mmap il caricamento del file zip

Question

eseguo il mio app sul ENV produzione (RHEL 5.2 x64, Oracle JRE 1.7_05, Tomcat 7.0.28) con argomenti JVM:

-Xms8192m -Xmx8192m -XX:MaxPermSize=1024m 
-Doracle.net.tns_admin=/var/ora_net -XX:ReservedCodeCacheSize=512m -XX:+AggressiveOpts -XX:+UseFastAccessorMethods 
-XX:+UseStringCache -XX:+OptimizeStringConcat -XX:+UseCompressedOops -XX:+UseG1GC -Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=9026 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false 

Dopo diverso tempo i 've ottenuto traccia dello stack del genere:

Java HotSpot(TM) 64-Bit Server VM warning: Attempt to deallocate stack guard pages failed. 
Java HotSpot(TM) 64-Bit Server VM warning: Attempt to allocate stack guard pages failed. 
mmap failed for CEN and END part of zip file 
[...] 
Caused by: java.lang.OutOfMemoryError: null 
    at java.util.zip.ZipFile.$$YJP$$open(Native Method) ~[na:1.7.0_05] 
    at java.util.zip.ZipFile.open(Unknown Source) ~[na:1.7.0_05] 
    at java.util.zip.ZipFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at java.util.zip.ZipFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at java.util.jar.JarFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at java.util.jar.JarFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.URLJarFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source) ~[na:1.7.0_05] 
    at java.net.URL.openStream(Unknown Source) ~[na:1.7.0_05] 
    at org.apache.catalina.loader.WebappClassLoader.findLoadedResource(WebappClassLoader.java:3279) ~[na:na] 
    at org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1478) ~[na:na] 
    at org.apache.http.util.VersionInfo.loadVersionInfo(VersionInfo.java:242) ~[httpcore-4.2.jar:4.2] 
    at org.apache.http.impl.client.DefaultHttpClient.setDefaultHttpParams(DefaultHttpClient.java:180) ~[httpclient-4.2.jar:4.2] 
    at org.apache.http.impl.client.DefaultHttpClient.createHttpParams(DefaultHttpClient.java:158) ~[httpclient-4.2.jar:4.2] 
    at org.apache.http.impl.client.AbstractHttpClient.getParams(AbstractHttpClient.java:448) ~[httpclient-4.2.jar:4.2] 

Guardando al mio profiler - everthing è ok (heap e memoria non heap utilizzata per il 10%) e non ho idea di dove sia il problema.

Questo problema si verifica ogni giorno alla stessa ora e non è collegato al tempo di attività dell'applicazione. Qual è la causa del problema?

Modificato:

Nuova uscita nel file di registro:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. 
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= 
Code Cache [0x00002aaaab790000, 0x00002aaaad240000, 0x00002aaacb790000) 
total_blobs=4223 nmethods=3457 adapters=707 free_code_cache=497085Kb largest_free_block=508887936 

ma ho abbastanza memoria: http://i.stack.imgur.com/K8VMx.jpg

Risposta: problema nella versione java. Descritto qui: https://forums.oracle.com/forums/thread.jspa?messageID=10369413

Answer 1

ho visto questi errori prima, quando a corto di risorse come l'esaurimento dello spazio di swap o in esecuzione di mappatura della memoria permesso. Date un'occhiata a sudo cat /proc/$PID/maps | wc -l rispetto a cat /proc/sys/vm/max_map_count

Vedere i commenti di seguito.

---

Ho anche suggerito ....

È sembrano aver incontrato un bug con YourKit. Che versione stai usando?

Vorrei ridurre la maggior parte delle opzioni in quanto sono predefinite e non fanno nulla o potrebbero complicare le cose.

-mx8g -XX:MaxPermSize=1g -Doracle.net.tns_admin=/var/ora_net 
-XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -Dcom.sun.management.jmxremote.port=9026 

Vorrei provare cadere -XX:+UseG1GC così come questo è un relativamente nuovo collettore e non dovrebbe cambiare i risultati.

Answer 2

Non so cosa è cambiato in Java 1.7 come ricordo da Java 1.6 usiamo le opzioni Xms come di seguito.

-Xms=512m -Xmx=512m 

Answer 3

provare queste opzioni

-Xrunhprof:heap=all,depth=12,cutoff=0 

Questo genererà un file di immagine nella radice dell'applicazione. Successivamente è possibile analizzare con HP Jmeter. Questo darà uno scatto istantaneo di quello che è successo ai tuoi 8Gig di memoria. È possibile consultare i manuali HP JMeter here.

Inoltre, ha scelto saggiamente le opzioni Xrunhprof. L'opzione sopra menzionata genererebbe un enorme file di dump. Dai manuali puoi trovare le opzioni adatte.

Answer 4

Alcuni paragrafi del original blog article, questo spiega come vaso java/zip funziona:

errore

L'OOM viene attivato durante una chiamata nativa (ZipFile.open (Native Method)) dal Java JDK ZipFile per caricare il nostro file EAR dell'applicazione. Questa operazione JVM nativa richiede l'adeguata memoria nativa e lo spazio di indirizzi virtuali disponibili per eseguire l'operazione di caricamento. La conclusione a questo punto era che la nostra Java VM 1.5 stava esaurendo la memoria nativa/spazio di indirizzamento virtuale al momento della distribuzione.

file mmap

Quando si utilizza JDK 1.4/1.5, qualsiasi file JAR/ZIP caricato dal Java VM Sun Java VM di memoria nativa e vengono mappati del tutto in uno spazio di indirizzi. Ciò significa che più file EAR/JAR vengono caricati su una singola JVM, maggiore è l'impronta di memoria nativa del processo Java.

Ciò significa anche che maggiore è lo spazio Java Heap e PermGen; la memoria inferiore è lasciata per gli spazi di memoria nativi come C-Heap e MMAP Files, che può sicuramente rappresentare un problema se si distribuiscono troppe applicazioni separate (file EAR) in un singolo processo Java a 32 bit.

Si noti che Sun ha apportato miglioramenti a JDK 1.6 (Mustang) e ha modificato il comportamento in modo che la directory centrale del file JAR sia ancora mappata, ma le voci stesse vengono lette separatamente; riducendo il requisito di memoria nativa.

Suggerisco di esaminare il link ID Bug Sun sotto per maggiori dettagli su tale limitazione JDK 1.4/1.5. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693