Java OutOfMemory excepción: error en el archivo de carga mmap postal

Question

corro mi aplicación en la producción de env (RHEL 5.2 x64, Oracle JRE 1.7_05, Tomcat 7.0.28) con argumentos de 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 

Después de varias veces i 've seguimiento de la pila ponía así:

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] 

Mirando a mi perfilador - Everthing está bien (en pilas y la memoria no utilizada para el montón 10%) y no tengo ni idea de dónde está el problema.

Este problema ocurre todos los días al mismo tiempo y no está conectado al tiempo de actividad de la aplicación. ¿Cuál es su causa problema?

Editado:

Nueva salida en el archivo de 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 

Pero tengo suficiente memoria: http://i.stack.imgur.com/K8VMx.jpg

Respuesta: problema en la versión de Java. Se describe aquí: https://forums.oracle.com/forums/thread.jspa?messageID=10369413

Answer 1

He visto estos errores antes cuando se están quedando sin recursos como quedarse sin espacio de intercambio o quedarse sin la asignación de memoria permitida. Eche un vistazo a sudo cat /proc/$PID/maps | wc -l en comparación con cat /proc/sys/vm/max_map_count

Consulte los comentarios a continuación.

---

También sugerí ....

Usted parece haber topado con un error con YourKit. Qué versión estás usando?

Reduciría la mayoría de sus opciones ya que son las predeterminadas y no hacen nada o podrían complicar las cosas.

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

me gustaría probar caer -XX:+UseG1GC, así como este es un fenómeno relativamente nuevo colector y no debería cambiar los resultados.

Answer 2

No estoy seguro de qué ha cambiado en Java 1.7, como recuerdo de Java 1.6 utilizamos las opciones de Xms como a continuación.

-Xms=512m -Xmx=512m 

Answer 3

intente estas opciones

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

Esto generará un archivo de volcado en la raíz de la aplicación. Luego puede analizar con HP Jmeter. Esto le dará una instantánea de lo que sucedió con sus 8Gigs de memoria. Puede ver los manuales de HP JMeter here.

Elija también sus opciones de Xrunhprof sabiamente. La opción anterior que mencioné generaría un gran archivo de volcado. De los manuales puedes encontrar las opciones adecuadas.

Answer 4

Algunos párrafos de la original blog article, esto explica cómo Java JAR/ZIP funciona:

error

La OOM se activa durante una llamada nativa (ZipFile.open (Método Nativo)) desde el JDK de Java para cargar ZipFile nuestro archivo EAR de aplicación. Esta operación JVM nativa requiere una memoria nativa adecuada y espacio de direcciones virtual disponible para ejecutar su operación de carga. La conclusión en este punto fue que nuestra Java VM 1.5 se estaba quedando sin memoria nativa/espacio de direcciones virtuales en el momento del despliegue.

archivos MMAP

Cuando se utiliza JDK 1.4/1.5, cualquier archivo JAR/ZIP cargado por la máquina virtual de Java de Sun Java VM memoria nativa y se les asignan por completo en un espacio de direcciones. Esto significa que cuantos más archivos EAR/JAR esté cargando en una sola JVM, mayor será la huella de memoria nativa de su proceso Java.

Esto también significa que cuanto mayor sea su espacio de Heap de Java y PermGen; la memoria más baja se deja para los espacios de su memoria nativa, como C-Heap y archivos MMAP, que definitivamente puede ser un problema si está implementando demasiadas aplicaciones separadas (archivos EAR) en un solo proceso de Java de 32 bits.

Tenga en cuenta que Sun presentó mejoras en JDK 1.6 (Mustang) y cambió el comportamiento para que el directorio central del archivo JAR todavía se mapee, pero las entradas se leen por separado; reduciendo el requisito de memoria nativa.

Le sugiero que revise el enlace de Sun Bug Id a continuación para obtener más detalles sobre dicha limitación JDK 1.4/1.5. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693