COM+ y VB.NET

Yo no soy un experto en COM+, pero puedo decirte que en general para liberar
objetos COM, debes utilizar Marhsal.ReleaseComObject. Pero respecto a lo que
decías, GC.Collect debería hacer lo mismo aunque de forma más costosa. La
asignación a nothing, no te va a servir de nada, excepto en las variables
que no hayan salido de ámbito antes de invocar al GC.

Por otro lado, nunca me canso de decir que cuando se analiza el consumo de
memoria, tanto de .net como del propio windows, hay que pensar que muchas
veces las apariencias no son reales. .Net está optimizado para no liberar la
memoria innecesariamente, puesto que es un proceso costoso. Si ninguna otra
aplicación, el consumo de memoria "aparente" seguirá creciendo. En
aplicaciones winforms, se comrpueba que en cuanto se minimiza y restaura la
aplicación, el supuesto consumo de memoria se reduce de forma radical, lo
mismo ocurrirá con tu servicio, con la diferencia de que en estos no es
fácil hacer lo mismo. Solo se podrá comprobar el consumo real de memoria,
cuando esta realmente empiece a faltar. Si se observa que el servicio sigue
consumiendo más, una vez consumida la memoria física, entonces si deberías
buscar el lugar donde se estén perdiendo recursos.

Juan Carlos Badiola
MVP - C#

Hola,

¿Consumir un giga de memoria era demasiado no? Aunque sea costoso liberar
memoria más costoso es el swap y otra aplicación requiere memoria...Digo yo :P

He conseguido reducir el uso de memoria evitanto instanciar un objeto cada
vez que hace falta y eliminarlo. Solo se instancia una vez en la ejecucion
del servicio y el consumo se ha reducido radicalmente pero sigue creciendo.
Ahora está en pruebas y veré si con 500 faxes no se come tanto. Ahora parece
mantenerse alrededor de 50 megas...

La verdad es que estas historias que se trae con la memoria no me hace
ninguna gracia pero

Gracias por la información de .NET.

Saludos




"Tristan" escribió:

Yo no soy un experto en COM+, pero puedo decirte que en general para liberar
objetos COM, debes utilizar Marhsal.ReleaseComObject. Pero respecto a lo que
decías, GC.Collect debería hacer lo mismo aunque de forma más costosa. La
asignación a nothing, no te va a servir de nada, excepto en las variables
que no hayan salido de ámbito antes de invocar al GC.

Por otro lado, nunca me canso de decir que cuando se analiza el consumo de
memoria, tanto de .net como del propio windows, hay que pensar que muchas
veces las apariencias no son reales. .Net está optimizado para no liberar la
memoria innecesariamente, puesto que es un proceso costoso. Si ninguna otra
aplicación, el consumo de memoria "aparente" seguirá creciendo. En
aplicaciones winforms, se comrpueba que en cuanto se minimiza y restaura la
aplicación, el supuesto consumo de memoria se reduce de forma radical, lo
mismo ocurrirá con tu servicio, con la diferencia de que en estos no es
fácil hacer lo mismo. Solo se podrá comprobar el consumo real de memoria,
cuando esta realmente empiece a faltar. Si se observa que el servicio sigue
consumiendo más, una vez consumida la memoria física, entonces si deberías
buscar el lugar donde se estén perdiendo recursos.

Juan Carlos Badiola
MVP - C#

¿Consumir un giga de memoria era demasiado no?

Pues depende, puesto que todo es relativo, no hace tanto 64 KB eran
demasiado. Todo va en función de cuanta sea la memoria física de esa
máquina. Es demasiado si se necesita para otras cosas, y demasiado poco si
no se necesita para nada más.

Aunque sea costoso liberar memoria más costoso es el swap y otra
aplicación requiere memoria...Digo yo :P

Pero es que ese es el error. No va a realizarse swap. Como te digo, si
realmente se empieza a agotar la memoria física, si se va a liberar. No vas
a llegar al punto en que sea necesario trabajar con memoria virtual.
Realmente, yo comprobaría el consumo en un equipo saturado, o con menos
memoria. En un equipo con mucha memoria ese tipo de comprobaciones no tiene
sentido.

Por otro lado, ¿Has probado lo que te he dicho del Marshal.ReleaseComObject?

Juan Carlos Badiola
MVP - C#

Pues lo he probado y... OOOOOOOOOOKKK

Entre un invento que me he montado compartiendo el objeto entre las
distintas clases en lugar de instanciar cada vez y lo que me has dicho del
marshal he conseguido estabilizarlo en 17 megas de consumo tratanto 150 faxes.

Muchas gracias.. con lo de marshal he aprendido muchas cosas

Muchas gracias

"Tristan" escribió:

>
> ¿Consumir un giga de memoria era demasiado no?

Pues depende, puesto que todo es relativo, no hace tanto 64 KB eran
demasiado. Todo va en función de cuanta sea la memoria física de esa
máquina. Es demasiado si se necesita para otras cosas, y demasiado poco si
no se necesita para nada más.

> Aunque sea costoso liberar memoria más costoso es el swap y otra
> aplicación requiere memoria...Digo yo :P

Pero es que ese es el error. No va a realizarse swap. Como te digo, si
realmente se empieza a agotar la memoria física, si se va a liberar. No vas
a llegar al punto en que sea necesario trabajar con memoria virtual.
Realmente, yo comprobaría el consumo en un equipo saturado, o con menos
memoria. En un equipo con mucha memoria ese tipo de comprobaciones no tiene
sentido.

Por otro lado, ¿Has probado lo que te he dicho del Marshal.ReleaseComObject?

Juan Carlos Badiola
MVP - C#