Hola gente!
Damian, pequenia gran pregunta: Tenes la declaración del XML Document? Digo, la línea donde esta declarada la variable. No se si al principio esta en Nothing, y el startup lo CREAS Y LLENAS, o si en la variable estatica lo creas con new, y en el startup LO LLENAS. Otra cosa: alguna pista en el Event Viewer? De reinicio de la aplicación? Si fuera por mi, no llenaría el XML Document en el startup, sino la primera vez que alguien lo pide (haciendo que su variable al comienzo este en Nothing, y controlando por Nothing cada vez que alguien lo pide). Y loguearia en algún lado cuando paso por esa rutina de llenado, para ir investigando cuando se llena de nuevo. Angel SeDispararaElStartup?EstaraElAssemblyDisponibleAlLlegarAlStartup? Lopez From: [email protected] [mailto:[email protected]] On Behalf Of Damián Herrera Sent: martes, 19 de marzo de 2013 11:57 a.m. To: [email protected] Cc: [email protected] Subject: [puntonet] Manejo de memoria en ambientes sobrecargados Hola Angel, jajaja bien, si, es correcta la pregunta. Tengo "cosas" que guardo en un cache propio para tener mejor eficiencia en las consulta a los mismos, pero no es así en todos los temas que escribi. Por ejemplo, el XMLDocument es un object static que se llena únicamente en el startup del webapp. Esto funciona bien, pero tengo este problema que debes en cuando se vacía Necesito este XMLDocument porque en el mismo almaceno XMLs que estan como recursos embebidos en un assembly, entonces para no recorrer ese assembly cada vez, lo hago únicamente al inicio y luego consulto contra este XMLDocument donde estan todos los XML unificados. Respondiendo a las preguntas en este caso: 1) En el objeto estatico. 2) Este punto no tiene httphandler. 3) Es un objeto estatico. 4) Me da un error provocado por mi, que al buscar a través de un XPath en el XMLDocument y no tener resultados, lanzo una excepcion directamente. El tema del Dictionary lo estoy debugeando todavía, porque no estoy seguro de si es el Dictionary el que me da "Object reference not set to an instance of an object" o un elemento dentro de él. Y por el tema de los javascript en cache, no te quiero aburrir, pero si, esa es una larga historia que empezó cuando pasamos de la version .Net 1.1 a la .Net 2.0 y el manejo de cache que hacia ASP.Net. Todo eso derivo en la creación de una suerte de cache propio llamado Workspaces que básicamente gestiona Cache y Session de una manera sencilla, pero con depuración automática de objetos sin uso y demás cosas propias de un cache. Para mi, tampoco es el GC el que esta molestando en este caso. Para mi, es algo más vinculado al SO o algo similar. Porque en el caso del XMLDocument no hay explicación. Y con el tema del Javascript tampoco. 6) Básicamente fue un cambio interior a partir de ver como evoluciona la tecnología, lo que hacen los departamentos de marketing y demás yerbas. La premisa que me dio la experiencia es que los objetos creados por uno (clases y objetos) siempre perduran a través de los cambios y evoluciones tecnológicas. En cambio un ASP.Net cache, un Dataset tipado y poniéndonos melancólicos un Recordset no son objetos que duren en el tiempo. Es más una filosofía a esta altura que un fundamento :) Saludos, Ing. Damián Herrera Director CIVINEXT Tel. / Fax: +54 (11) 3968-0039 [email protected] http://www.civinext.com <http://www.civinext.com/> <http://www.linkedin.com/company/civinext-s.a.> <http://www.facebook.com/groupware> <http://www.twitter.com/damianherrera> <http://www.youtube.com/user/damianherrera> <http://es.wikipedia.org/wiki/Civinext> El 19 de marzo de 2013 11:11, Carlos Salvatore <[email protected]> escribió: Damián, Me parece que si las referencias siguen vivas, no es un problema del GC. El GC no debería liberar memoria y dejar las referencias "vivas". Eso te podría pasar con un puntero pero no con una referencia en un entorno de memoria manejado. Si no entiendo mal, lo que vos describís sería lo siguiente. Vos tenés una serie de objetos estáticos. Esos objetos son consultados a través de una suerte de caché. ¿Hasta ahí es correcto? Entonces 1) Dónde las colecciones se truncan? En el caché o en objeto estático? 2) WWWWH vacía el caché? 3) Por qué el resguardo del caché es otro objeto en memoria? 4) Qué sucede cuando el caché no tiene la colección? La busca en la referencia estática? Verifica de algún modo que la referencia estática no sea nula? En algún punto de este proceso se dispara la carga de estas colecciones? (Podría pasar como resultado de la concurrencia que dos threads distintos manden a cargar las colecciones y el segundo trunque la carga del primero) 4B) ¿Existe la posibilidad de que algún try/catch te esté escondiendo una excepción de concurrencia? 5) Si la caché en memoria apunta a otro objeto en memoria, cómo se persisten estas colecciones (desde dónde se carga el contenido del objeto estático, si es que se hace en algún momento)? 6) Dado que ya sabemos que Aristóteles le criticó a Platón su solución de duplicar los objetos hace más de dos mil años, cuál sería la causa que justificaría que hagas lo mismo en tu aplicaición? (alerta de chicana, no tomar a mal). _____ Date: Tue, 19 Mar 2013 10:47:34 -0300 Subject: [puntonet] Manejo de memoria en ambientes sobrecargados From: [email protected] To: [email protected] Hola Angel, Gracias por tu respuesta. Si, los objectos son compartidos por todos los threads, son elementos static/shared de clases. En principio no habíamos configurado el recicle del App Pool, hace ya unos meses lo tenemos configurado para que todas las noches se recicle y eso hizo que se caiga menos veces. La infraestructura es un Win 2008 R2, 64 bits, App Pool en .Net 4 con el Managed Pipeline en Integrated mode. No es lo que dije originalmente, pero también tuve este tipo de problemas con Recursos embebidos en el assembly. Básicamente son archivos de javascript que cuando son pedidos a través de un HttpHandler se buscan en un cache interno (que termina consultando un Synchronized Hashtable y de vez en cuando, una vez por mes o cada tanto el javascript estaba roto, es decir, me devolvía las primeras 200 lineas y el resto no estaba :) Esto lo solucione poniéndole una marca al final del archivo para saber si lo que tenia en memoria estaba completo o debía ir a buscarlo de nuevo al assembly :s A partir de este caso pienso que hay veces que el proceso llega a un punto donde se "estresa" y limpia su memoria dejando algunas posiciones medio rotas. Se que suena a poco probable, el tema es que sucede cada tanto y no es algo que pueda repetir en un ambiente controlado. En general hago stress test de la webapp y funciona bien. No llego a tener estos problemas. Saludos, Ing. Damián Herrera Director CIVINEXT Tel. / Fax: +54 (11) 3968-0039 [email protected] http://www.civinext.com El 19 de marzo de 2013 07:43, Angel "Java" Lopez <[email protected]> escribió: Hola gente! Hmmm Damian, no tengo todo el contexto, pero vieron si es algun problema de concurrencia? Digo, estan ejecutando varios threads cuando tienen alto trafico? Y esos threads estan accediendo a esos objectos en memoria? Son compartidos entre los threads? Por lo que entendió, tenes objetos que VIVEN un tiempo en memoria (horas?), y son consultados o manejados durante el alto trafico por los clientes que llegan. En donde esta corriendo esto? En un IIS, en un servicio, en Azure, en un web farm? Reciclado de una instancia puede haber (a la Yoda ;-) Nos leemos! Angel Java Lopez @ajlopez De: [email protected] [mailto:[email protected]] En nombre de Damián Herrera Enviado el: Monday, March 18, 2013 5:54 PM Para: [email protected] Asunto: [puntonet] Manejo de memoria en ambientes sobrecargados Buenas, Espero que anden bien. Hace mucho que no escribo y buscando algo de info. me pareció que era algo para postear en la lista. Actualmente tenemos un problema en ambientes de alto trafico, básicamente manejamos Generic.Dictionary(string,string) y Xml.XmlDocument. Únicamente en ambientes de alto trafico, nos sucede de vez en cuando que desaparecen elementos del Dictionary o el XmlDocument queda vacío. Sospecho que el XMLDocument queda vacío porque hay momentos en los que no se utiliza porque hay una capa de cache que hace que se lo consulte poco, pero la referencia sigue activa dentro de una clase (esta declarado como private shared). Algo similar ocurre con el Dictionary, pero este se usa más que el XmlDocument. La consulta en si misma es, hay alguna forma de "marcar" o especificar que esas variables no deben ser recolectadas o alguna manera de que me entere cuando las recolectan? Es algo que estuve buscando y no encontré mucha info. y no estoy seguro que tenga que ver con el GC. Bueno, cualquier orientación se agradece. Saludos! Ing. Damián Herrera Director CIVINEXT Tel. / Fax: +54 (11) 3968-0039 [email protected] http://www.civinext.com
