anonymous
Log in
Log out
Search
Recents:
v3.0
My subscriptions
My posts
My profile
gx-l
Tomcat - Liberar memoria no utilizada.
09/12/09 20:14
bernardolg
Replies:
4
Saludos. Al navegar páginas generadas a partir de web panels (java-web) el tomcat6.exe consume cierta cantidad de memoria (mostrado en el Administrador de tareas de Windows). Luego de salir de dichas páginas, la memoria queda como utilizada, limitando la cantidad de páginas y procedimientos a ejecutar antes que ocurra un error de memoria. Necesito liberar la memoria una vez que ya no es utilizada. ¿Qué método me recomiendan? Estoy utilizando: - GeneXus X Evolution 1 V. 10.1.25909 - jdk 6u14 - Apache Tomcat 6.0 ßernardo E. López García. ----------------------------------- ¡Olmo, dame peras! ----------------------------------------- Para Suscribirse/Desuscribirse: http://www.gxtechnical.com/cgi-bin/hforum.exe?2,3,30,1 Por consultas owner-gx-l@gxtech.com.uy
Saludos.
Al navegar páginas generadas a partir de web panels (java-web) el
tomcat6.exe consume cierta cantidad de memoria (mostrado en el
Administrador de tareas de Windows). Luego de salir de dichas páginas,
la memoria queda como utilizada, limitando la cantidad de páginas y
procedimientos a ejecutar antes que ocurra un error de memoria.
Necesito liberar la memoria una vez que ya no es utilizada. ¿Qué
método me recomiendan?
Estoy utilizando:
- GeneXus X Evolution 1 V. 10.1.25909
- jdk 6u14
- Apache Tomcat 6.0
ßernardo E. López García.
-----------------------------------
¡Olmo, dame peras!
-----------------------------------------
Para Suscribirse/Desuscribirse:
http://www.gxtechnical.com/cgi-bin/hforum.exe?2,3,30,1
Por consultas owner-gx-l@gxtech.com.uy
Replies
dgit cons02
10/12/09 14:12
Hola Bernardo Pablo me mandó este material al respecto, espero te sirva, a mi me ayudó con el problema del permgen, pero no he investigado al fondo lo del memory leak, a ver si en vacaciones me echo un clavado Hola, Tenés que usar algún Memory Profiler, no todos los Profilers sirven, porque algunos solo miden tiempos de ejecución pero no se ocupan de la memoria. En la Wiki de Genexus hay bastante información: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Monitoring+Memory+Management+with+JMX, Acá tenés un artículo sobre cómo encontrar leaks: http://unocerounocero.blogspot.com/2009/05/memory-leaks-en-java.html Te puedo adelantar algunas cosas: - PermGen: es muy común al recompilar y por lo tanto obligar al tomcat a levantar nuevas versiones de las clases. - OutOfMemory: es más probable que sea por algún leak. Los problemas que conozco son: - La propiedad "Execute in new LUW" deja memoria colgada. - Cuando se corre un proceso en modo submit (batch) los "msg" quedan colgados ocupando memoria. Suerte! Pablo Moleri
Hola Bernardo Pablo me mandó este material al respecto, espero te sirva, a mi me ayudó con el problema del permgen, pero no he investigado al fondo lo del memory leak, a ver si en vacaciones me echo un clavado Hola, Tenés que usar algún Memory Profiler, no todos los Profilers sirven, porque algunos solo miden tiempos de ejecución pero no se ocupan de la memoria. En la Wiki de Genexus hay bastante información: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Monitoring+Memory+Management+with+JMX, Acá tenés un artículo sobre cómo encontrar leaks: http://unocerounocero.blogspot.com/2009/05/memory-leaks-en-java.html Te puedo adelantar algunas cosas: - PermGen: es muy común al recompilar y por lo tanto obligar al tomcat a levantar nuevas versiones de las clases. - OutOfMemory: es más probable que sea por algún leak. Los problemas que conozco son: - La propiedad "Execute in new LUW" deja memoria colgada. - Cuando se corre un proceso en modo submit (batch) los "msg" quedan colgados ocupando memoria. Suerte! Pablo Moleri
bernardolg
11/12/09 11:29
Gracias dgit, voy a revisar el material. No importa cuánto suba el máximo de memoria Java, si quedan procesos ocupándola (aún sin estar siendo utilizados), en algún momento revienta. El día 10 de diciembre de 2009 12:41, dgit cons02 <dgit-cons02@semarnat.gob.mx>
Gracias dgit, voy a revisar el material. No importa cuánto suba el máximo de memoria Java, si quedan procesos ocupándola (aún sin estar siendo utilizados), en algún momento revienta. El día 10 de diciembre de 2009 12:41, dgit cons02
Silvio Quadri
11/12/09 12:05
El día 11 de diciembre de 2009 11:28, Bernardo López <bernardolg@gmail.com>
El día 11 de diciembre de 2009 11:28, Bernardo López
bernardolg
14/12/09 10:39
Saludos Silvio. Gracias por la sugerencia. Trabajo de igual forma, genero el .WAR y reinicio el Tomcat. No he probado el autodeploy aún (ni creo haberlo visto). Al parecer, aumentando el Xms y el Xmx no ha dado el mismo error (Java HEAP "Out of memory"), pero algunas horas después todo se torna TAN lento, que hay que reiniciar el Tomcat nuevamente. Voy a utiilzar el JConsole y el JavaMelody para tratar de identificar el problema. ¿Qué herramienta de monitoreo han utilizado? El día 11 de diciembre de 2009 10:33, Silvio Quadri <silvioq@gmail.com>
Saludos Silvio. Gracias por la sugerencia. Trabajo de igual forma, genero el .WAR y reinicio el Tomcat. No he probado el autodeploy aún (ni creo haberlo visto). Al parecer, aumentando el Xms y el Xmx no ha dado el mismo error (Java HEAP "Out of memory"), pero algunas horas después todo se torna TAN lento, que hay que reiniciar el Tomcat nuevamente. Voy a utiilzar el JConsole y el JavaMelody para tratar de identificar el problema. ¿Qué herramienta de monitoreo han utilizado? El día 11 de diciembre de 2009 10:33, Silvio Quadri
Back to gx-l