java - por - permgen space tomcat

Uso de memoria y JVM: ¿el servidor JRun no utiliza la asignación completa de PSPermGen? (3)

Estoy tratando de entender por qué el servidor de ColdFusion 9 (JRun) arroja el siguiente error:

java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?

Los argumentos de JVM son los siguientes:

-server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -

Tenía jconsole ejecutándose cuando sucedió el volcado y estoy tratando de conciliar algunos números con la -XX:MaxPermSize=192m anterior. Cuando JRun murió, tenía el siguiente uso de memoria:

Heap PSYoungGen total 136960K, used 60012K [0x5f180000, 0x67e30000, 0x68d00000) eden space 130624K, 45% used [0x5f180000,0x62c1b178,0x67110000) from space 6336K, 0% used [0x67800000,0x67800000,0x67e30000) to space 6720K, 0% used [0x67110000,0x67110000,0x677a0000) PSOldGen total 405696K, used 241824K [0x11500000, 0x2a130000, 0x5f180000) object space 405696K, 59% used [0x11500000,0x20128360,0x2a130000) PSPermGen total 77440K, used 77070K [0x05500000, 0x0a0a0000, 0x11500000) object space 77440K, 99% used [0x05500000,0x0a043af0,0x0a0a0000)

Mi primera pregunta es que el volcado muestra que el problema es PSPermGen, dice que el total es 77440K, pero debería ser 196608K (basado en mi argumento JVM de 192m), ¿verdad? ¿Que me estoy perdiendo aqui? ¿Tiene esto algo que ver con el otro grupo que no es de almacenamiento dinámico? ¿El caché de código?

Me estoy ejecutando en una máquina de 32 bits, Windows Server 2008 Standard. Estaba pensando en aumentar el argumento de JVM de PSPermGen , pero quiero entender por qué no parece estar usando su asignación actual.

¡Gracias por adelantado!

"ChunkPool :: allocate. Out of swap space" significa generalmente que el proceso de JVM no ha podido asignar memoria para su procesamiento interno.

Por lo general, esto no está directamente relacionado con el uso de su pila, ya que es el proceso de JVM el que se ha quedado sin memoria. Verifique el tamaño del proceso de JVM dentro de Windows. Puede haber alcanzado un límite superior allí.

Este informe de error también da una explicación. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5004956

Esto generalmente es causado por objetos nativos, no java no lanzados por su aplicación en lugar de objetos java en el montón.

Algunas causas de ejemplo son:

Tamaño de pila de subprocesos grande, o muchos subprocesos que se generan y no se limpian correctamente. Las pilas de hilos viven en memoria nativa "C" en lugar de en el montón de Java. He visto este yo mismo.
Las ventanas Swing / AWT se crean programáticamente y no se eliminan cuando ya no se usan. Los widgets nativos detrás de AWT no viven en el montón también.
Los búferes directos de nio no se liberan. Los datos para el búfer directo se asignan a la memoria de proceso nativa, no al montón de Java.
La memoria se filtra en las invocaciones jni.
Muchos archivos se abrieron y no se cerraron.

Encontré este blog útil cuando diagnosticaba un problema similar. http://www.codingthearchitecture.com/2008/01/14/jvm_lies_the_outofmemory_myth.html

Un OOME "fuera del espacio de intercambio" ocurre cuando la JVM solicitó más memoria al sistema operativo y el sistema operativo no pudo cumplir con la solicitud porque ya se asignó todo el espacio de intercambio (disco). Básicamente, ha alcanzado un límite estricto en todo el sistema de la cantidad de memoria virtual disponible.

Esto puede suceder sin culpa de su aplicación, o la JVM. O podría ser una consecuencia de aumentar -Xmx etc. más allá de la capacidad de tu sistema para soportarlo.

Hay tres enfoques para abordar esto:

Agregue más memoria física al sistema.
Aumente la cantidad de espacio de intercambio disponible en el sistema; por ejemplo, en Linux mira la entrada manual para swapon y amigos. (Pero tenga cuidado de que la relación entre la memoria virtual activa y la memoria física no sea demasiado grande ... o que su sistema sea susceptible de "agitar", y el rendimiento disminuirá en el piso).
Reduzca el número y el tamaño de los procesos que se están ejecutando en el sistema.

Si se metió en esta situación porque ha estado aumentando -Xmx para combatir otras OOMEs, entonces ahora sería un buen momento para rastrear las (probables) pérdidas de memoria que son la causa de sus problemas.

Verifique su archivo setDomainEnv.cmd (.sh). Habrá tres condiciones diferentes en PermSize -XX: MaxPermSize = xxxm -XX: PermSize = xxxm. Cambiar en todas partes