PermGen problemas con ascensor y embarcadero

StackOverflow https://stackoverflow.com/questions/1451648

Pregunta

Estoy desarrollando en la plataforma de elevación estándar (experta y embarcadero). Estoy en repetidas ocasiones (una vez cada dos días) conseguir esto: 

Exception in thread "7048009@qtp-3179125-12" java.lang.OutOfMemoryError: PermGen space
2009-09-15 19:41:38.629::WARN:  handle failed
java.lang.OutOfMemoryError: PermGen space

Esto está en mi entorno de desarrollo. No es un problema porque puedo mantener reiniciar el servidor. En el despliegue no estoy teniendo estos problemas así que no es un problema real. Sólo por curiosidad.

No sé demasiado acerca de la JVM. Creo que estoy en lo cierto al pensar que la memoria permanente generación es para cosas como clases y cadenas internadas? Lo que recuerdo es un poco mezclado con el modelo de memoria de .NET ...

Cualquier razón por qué ocurre esto? Son los valores por defecto solo locamente bajo? ¿Tiene que ver con todos los objetos auxiliares que Scala tiene que crear los objetos de función y cosas similares FP? Cada vez que reinicio Embarcadero con el nuevo código escrito (cada pocos minutos) Me imagino que vuelve a cargar las clases etc. Pero aún así, no puede ser que muchos se puede? Y si no la JVM ser capaz de hacer frente a un gran número de clases?

Saludos

Joe

¿Fue útil?

Solución

este post :

  

Esta excepción se produjo por una simple razón:
   permgenspace es donde las propiedades de clase, tales como métodos, campos, anotaciones, y también variables estáticas, etc. se almacenan en la máquina virtual de Java, pero este espacio tiene la particularidad de no ser limpiado por el recolector de basura .   Así que si su aplicación web utiliza o crea una gran cantidad de clases (estoy pensando en las generaciones dinámicas de clases), es probable que se reunieron este problema.   Aquí están algunas de las soluciones que me ayudaron a deshacerse de esta excepción:

  • -XX:+CMSClassUnloadingEnabled: esta configuración permite la recolección de basura en el permgenspace
  • -XX:+CMSPermGenSweepingEnabled: permite que el recolector de basura para eliminar incluso las clases de la memoria
  • -XX:PermSize=64M -XX:MaxPermSize=128M: aumenta la cantidad de memoria asignada a la permgenspace

Puede ser que esto podría ayudar.

Editar julio de 2012 (casi 3 años después):

Ondra Žižka comentarios (y he actualizado la respuesta anterior):

  

JVM 1.6.0_27 dice: Por favor, utilice:

  • CMSClassUnloadingEnabled (Si la descarga clase habilitada cuando se utiliza CMS GC)
  • en lugar de CMSPermGenSweepingEnabled en el futuro

Vea la Hotspot Opciones de JVM. - El referencia completa para mroe

Otros consejos

Si ve este mvn jetty:run cuando se ejecuta, establecer el MAVEN_OPTS.

Para Linux: 

export MAVEN_OPTS="-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M"
mvn jetty:run

Para Windows: 

set "MAVEN_OPTS=-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M"
mvn jetty:run

En caso de estar bien ahora. Si no es así, aumentar la -XX:MaxPermSize.

También se puede poner éstos en forma permanente a su entorno.

Esto es debido a la recarga de clases como usted sugiere. Si está utilizando una gran cantidad de bibliotecas, etc. la suma de clases crecerá rápidamente para cada reinicio. Trate de monitorear la instancia embarcadero con VisualVM para obtener una visión general de consumo de memoria cuando se recarga.

La lista de correo ( http://groups.google.com/group/liftweb/) es el foro oficial de soporte de elevación, y donde usted será capaz de obtener una mejor respuesta. No sé los detalles de su configuración dev (no entrar en mucho detalle), pero supongo que está recargando su guerra en el embarcadero sin tener que reiniciarlo. Ascensor no realiza la generación dinámica de clase (como se sugiere por VonC arriba), pero Scala compila cada cierre como una clase separada. Si va a añadir y retirar los cierres de su código en el transcurso de varios días, es posible que muchas clases se están cargando y nunca descargada y ocupando un espacio permanente. Yo te sugeriría que habilita las opciones de JVM opciones mencionadas por VonC arriba y ver si ayudan.

La generación permanente es donde la JVM pone cosas que probablemente no será (basura) recogidos como cargadores de clases personalizados.

En función de lo que se va a implementar, el ajuste de generación permanente puede ser baja. Algunas aplicaciones y / o recipientes de combinación contienen algunas pérdidas de memoria, por lo que cuando una aplicación se pone a veces sin desplegar algunas cosas como cargadores de clases no se recogen, lo que resulta en que llena el espacio Perm generando así el error que está teniendo.

Por desgracia, en la actualidad la mejor opción en este caso es máximo el espacio permanente con la siguiente bandera JVM (por ejemplo Perm 192m tamaño): 

-XX:MaxPermSize=192M (or 256M)

La otra opción es asegurarse de que o bien el recipiente o el marco no se escapan de la memoria.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top