[Gvsig_desarrolladores] Memoria JAVA monitorizada
Daniel L.S.
pumukovic en hotmail.com
Vie Jun 10 14:24:19 CEST 2011
Gracias por las respuestas. Sigo a la espera de alguien que aporte algo de claridad a todo este asunto.
Andres, probare las herramientas q comentas, gracias. Y la extension en principio esta muy cerrada a la estructura de datos de nuestro proyecto actual, no es nada genérica. Si en un momento dado se dispone de una herramienta generica para poder utilizarla lo comento.
Un saludo
Date: Fri, 10 Jun 2011 12:09:35 +0200
From: nachouve en gmail.com
To: gvsig_desarrolladores en listserv.gva.es
Subject: Re: [Gvsig_desarrolladores] Memoria JAVA monitorizada
Hace tiempo estuvimos enfrentándonos a algunos problemas con eso de la memoria. Uno de los puntos que recuerdo que daban problemas es cuando cargas una capa y luego la eliminas del ToC. Parece que nunca se libera esa memoria, aunque hagas close() en los objetos.
No llegamos a encontrar la manera de solucionarlo. Supongo que esta es de las cosas que con la 2.0 se mejorará.
Un saludo,
Nacho V
2011/6/10 Andrés Maneiro <amaneiro en icarto.es>
Hola Daniel,
On 09/06/11 19:14, Daniel L.S. wrote:
> Hola. Se que alguna vez se ha hablado del tema, pero no se muy bien las
> soluciones que se aportaron. Tengo una extensión que genera mapas
> imprimibles configurables. Al configurar un mapa con varias "ventanas"
> con imagenes de diefrentes servicios wms me encuentro con un aumento muy
> elevado del uso de memoria de java. Está claro que se puede asignar más
> memoria al proceso gvSIG en el gvSIG.ini pero eso solo retrasa un poco
> el hava heap space error. Pues es cuestion de un par de mapas impresos
> para saturar la memoria. Adjunto una imagen en la que muestra el monitor
> de mi memoria y los hilos. Los dos "escalones" cosiderables en el uso de
> memria son causados al imprimir un mapa con 5 ventanas con informacion
> de 5 servicios WMS. Como veis no se libera nunca esa memoria. Si alguien
> tiene alguna solucion, por favor que me la comente.
>
por un lado se me ocurre que puedes configurar la jvm que lanza gvsig
con ciertos parámetros que mejoren la recolección de objetos. Aquí
algunos enlaces que usé yo para tunear un geoserver:
http://www.petefreitag.com/articles/gctuning/
http://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generation
Bueno, y seguro que googleando encuentras alguno mejor.
Por otro lado, como dices, esto sólo retrasará el error. Lo que ocurre
es que hay memory leaks. Para ver dónde están, puedes usar algunas de
las herramientas de java, por ejemplo, jmap:
http://docs.geoserver.org/stable/en/user/production/troubleshooting.html#jmap
Saludos,
Andrés
_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores en listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
--
Juan Ignacio Varela García
_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores en listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20110610/c8add4c3/attachment.htm
Más información sobre la lista de distribución gvSIG_desarrolladores