Hola Carlos, Gracias por responder. Muy buena. Vamos a ver que pasa y que info. consigo.
Saludos, Ing. Damián Herrera Director CIVINEXT Tel. / Fax: +54 (11) 3968-0039 [email protected] 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 12:21, Carlos Salvatore <[email protected] > escribió: > Una alternativa para investigar el problema puede ser suscribirte a algún > evento del objeto XML (XmlDocument o lo que sea) de los que te chantan que > el objeto fue modificado (por ejemplo cuando se remueve un nodo) y tratar > de capturar alguna información útil (por ejemplo el stack trace para saber > cuál es la secuencia de instrucciones que te llevó hasta ese punto). Así > podés saber cuándo se vacía y, con suerte, aproximarte al por qué. > > > > ------------------------------ > Date: Tue, 19 Mar 2013 11:57:08 -0300 > > Subject: [puntonet] Manejo de memoria en ambientes sobrecargados > From: [email protected] > To: [email protected] > CC: [email protected] > > > 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 <#13d833d9c3670ca8_> > [email protected] > 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 > <#13d833d9c3670ca8_><#13d833d9c3670ca8_13d82fd31c45d795_> > [email protected] > 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 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 > <#13d833d9c3670ca8_><#13d833d9c3670ca8_13d82fd31c45d795_> > [email protected] > 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>**** > ** ** > > > >
