[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