2010-08-19 16 views
21

Parece queTomcat en el servidor de producción, PermGen y vuelve a desplegar

MemoryError: PermGen space 
java.lang.OutOfMemoryError: PermGen space 

es un problema común. Puede aumentar el tamaño de su espacio permanente, pero después de 100 o 200 redesplegar estará lleno. Seguir las fugas de memoria de ClassLoader es casi imposible.

¿Cuáles son sus métodos para Tomcat (u otro simple servlet container - Jetty?) En el servidor de producción? ¿Se reinicia el servidor después de cada implementación de una solución?

¿Utiliza un Tomcat para muchas aplicaciones?

Tal vez debería usar muchos servidores Jetty en diferentes puertos (o un Jetty incrustado) y anular la implementación/reiniciar/implementar cada vez?

+0

¿Ha intentado aumentar el tamaño del montón? – vsingh

+0

No es un problema de tamaño de pila, sino un problema de descarga de código de clases. Dicen que las clases no se descargan en JVM y el espacio de PermGen no se barre. –

Respuesta

6

Dejé de usar el administrador de tomcat y ahora siempre cierro tomcat para redesplegar.

Ejecutamos dos tomcats en el mismo servidor y usamos apache webserver con mod_proxy_ajp para que los usuarios puedan acceder a ambas aplicaciones a través del mismo puerto 80. Esto también es bueno porque los usuarios ven la página Apache Service Unavailable cuando el tomcat está inactivo.

+1

Usamos dos tomcat en diferentes puertos detrás de HAProxy para proporcionar una solución de despliegue azul-verde. El servidor "Azul" se apaga cuando "Verde" está encendido y funcionando, entonces HAProxy cambia a "Verde". El siguiente despliegue va a "Azul" entonces. –

2

Sí, de hecho, esto es un problema. Estamos ejecutando tres aplicaciones web en un servidor Tomcat: No. 1 utiliza un marco de aplicaciones web, Hibernate y muchos otros archivos JAR, no. 2 usa Hibernate y algunos JAR y no. 3 es básicamente una aplicación JSP muy simple.

Cuando desplegamos no. 1, siempre reiniciamos Tomcat. De lo contrario, un error de espacio PermGen nos morderá pronto. No. 2 a veces se puede implementar sin problema, pero ya que a menudo cambia cuando no. 1 también lo hace, un reinicio está programado de todos modos. El n. ° 3 no plantea ningún problema y puede implementarse tantas veces como sea necesario sin problema.

Por lo tanto, sí, usualmente reiniciamos Tomcat. Pero también esperamos con ansias Tomcat 7, que se supone que maneja muchos problemas de cargador de memoria/clase que están incluidos en diferentes JAR y frameworks de terceros.

3

Usted puede tratar de añadir estas opciones de Java:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled 

Esto permite la recolección de basura en el espacio PermGen (desactivado por defecto) y permite que el GC para descargar las clases. Además, debe usar -XX: PermSize = 64m -XX: MaxPermSize = 128m mencionado en otro lugar para aumentar la cantidad de PermGen disponible.

+2

¿Cómo se supone que ayudan? – vsingh

1

Debe habilitar la recolección de basura PermGen. Por defecto, Hotspot VM NO recoge basura PermGen, lo que significa que todos los archivos de clase cargados permanecen en la memoria para siempre. Cada nueva implementación carga un nuevo conjunto de archivos de clase, lo que significa que eventualmente se queda sin espacio PermGen.

+0

Según lo notado por @Soundlink, los parámetros para activar GC en PermGen son "-XX: + CMSClassUnloadingEnabled -XX: + CMSPermGenSweepingEnabled". En Ubuntu, debe agregar estos a JAVA_OPTS en/etc/default/tomcat6. – werkshy

2

Los conmutadores PermGen en HotSpot solo retrasan el problema, y ​​eventualmente obtendrás el OutOfMemoryError de todos modos.

Hemos tenido este problema durante mucho tiempo, y la única solución que he encontrado hasta ahora es usar JRockit en su lugar. No tiene un PermGen, por lo que el problema simplemente desaparece. Estamos evaluando en nuestros servidores de prueba ahora, y no hemos tenido un problema de PermGen desde el cambio. También intenté redistribuir más de 20 veces en mi máquina local con una aplicación que obtiene este error en la primera redistribución, y todo transcurrió maravillosamente.

JRockit está destinado a integrarse en OpenJDK, por lo que es posible que este problema también desaparezca para el stock de Java en el futuro.

http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

Y es gratis, bajo la misma licencia que HotSpot:

https://blogs.oracle.com/henrik/entry/jrockit_is_now_free_and

+0

Pensé que JRockit mantiene las definiciones de clase en montón. ¿No crece tu montón después de cada redistribución? ¿Qué muestra "JRockit Mission Control" sobre el tamaño del montón? –

+0

El montón permanece en el mismo tamaño después de cada redistribución, hasta donde puedo ver. Intenté de nuevo con aproximadamente 10 redespliegues en este momento. –

1

¿Qué versión de Tomcat está usando? Tomcat 7 y 6.0.30 tienen muchas características para evitar estas filtraciones, o al menos advertirle sobre su causa.

This presentation por Mark Thomas de SpringSource (y cometer por mucho tiempo Tomcat) sobre este tema es muy interesante.

+0

La pregunta fue hecha en 2010. Tomcat 7 estaba en planes en ese momento. Nuestra solución fue una aplicación que apagó tomcat, copió WAR viejo para respaldar dir, descargó WAR nuevo de Hudson, inicia Tomcat. Usamos dos tomcat y un patrón de despliegue azul-verde. –

1

Solo como referencia, existe una nueva versión de la herramienta Plumbr, que también puede monitorear y detectar fugas de Generación permanente.

Cuestiones relacionadas