Problema de espacio PermGen con Glassfish/Hibernate

Estoy ejecutando una aplicación GWT + Hibernate en Glassfish 3.1. Después de unas horas, me quedo sin espacio en Permgen. Esto es sin ninguna recarga de webapp. Me estoy ejecutando con –XX:MaxPermSize=256m –XmX1024m.Problema de espacio PermGen con Glassfish/Hibernate

Tomé el consejo de this page, y descubrí que gano muchísimas clases: todos mis modelos Hibernate y todos mis proxies GWT RequestFactory.

La guía mencionada anteriormente dice "inspeccionar las cadenas, localizar la referencia accidental y corregir el código". Es más fácil decirlo que hacerlo.

El cargador de clases siempre señala una instancia de org.glassfish.web.loader.WebappClassLoader. Profundizando más, encuentro muchas referencias de $Proxy135 y objetos con nombres similares. Pero no sé cómo seguirlo.

Fuente

2011-04-01 George Armhold

Intente utilizar estos argumentos: '-XX: + UseConcMarkSweepGC -XX: + CMSPermGenSweepingEnabled -XX: + CMSClassUnloadingEnabled -XX: MaxPermSize = 256m' –

I "resuelto" esto mediante el movimiento de Tomcat.

Fuente

2012-10-21 01:44:07

Los objetos de nueva clase se colocan en el PermGen y ocupan así una cantidad de espacio cada vez mayor. Independientemente de cuán grande sea el espacio PermGen, inevitablemente se completará después de suficientes implementaciones. Lo que debe hacer es tomar medidas para lavar el PermGen para que pueda estabilizar su tamaño. Hay dos indicadores JVM que manejan esta limpieza:

-XX:+CMSPermGenSweepingEnabled

Esta configuración incluye el PermGen en un plazo de recolección de basura. Por defecto, el espacio PermGen nunca se incluye en la recolección de basura (y por lo tanto crece sin límites).

-XX:+CMSClassUnloadingEnabled

Esta configuración le dice al barrido de recolección de basura PermGen que tome medidas en los objetos de la clase. Por defecto, los objetos de la clase obtienen una exención, incluso cuando se visita el espacio PermGen durante una colección de garabage.

Fuente

2011-04-01 05:25:12

Pero veo que esto ocurre después de una sola implementación. ¿Por qué todos los proxies de hibernación/GWT siguen siendo referenciados por el servidor de la aplicación? –

Hola, todavía tengo una pregunta, ¿dónde debería agregar estos comandos? – Minutis

En Glassfish 3, edite glassfish/domain_folder/config/domain.xml, en la etiqueta 'java-config' ya debería haber configuraciones similares, simplemente agregue nuevos elementos' jvm-options' – Jacopofar

(no puedo ver el enlace que ya ha proporcionado ya que está bloqueado por websense por lo que si estoy repitiendo nada me disculpo)

Parece que usted tiene una fuga cargador de clases. Estos son difíciles de localizar, añadir estas opciones a las opciones de JVM en la configuración de la instancia

-XX:+PrintGCDetails 
-XX:+TraceClassUnloading 
-XX:+TraceClassLoading

Ahora al ejecutar la aplicación, se puede ver en la jvm.log encuentra en su carpeta de dominio/logs y ver lo que hay carga y descarga. Lo más probable es que veas la (s) misma (s) clase (s) cargando una y otra vez.

Un buen culpable es JAXB, especialmente si está creando un nuevo JAXBContext una y otra vez.

Fuente

2011-04-06 22:30:26 Preston

Hay algunas herramientas OK para ayudar con esto, aunque nunca lo sabrías. El JDK (1.6 u1 y superior) se envía con jhat y jmap. Estas herramientas serán de gran ayuda, especialmente si usa el soporte de consultas JavaScript jhat.

Ver:

http://blog.ringerc.id.au/2011/06/java-ee-application-servers-learning.html

http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java

http://www.mhaller.de/archives/140-Memory-leaks-et-alii.html

http://blogs.oracle.com/sundararajan/entry/jhat_s_javascript_interface

Fuente

2011-06-26 11:17:38