Memory usage. ( H E L P ! ! )

[George Gre]

Hi,

I wrote a c# programme that listens to incoming TCP requests and services
them. This programme is meant to be running as long as the server its
installed on is running. So we assume for ever(!). My problem is that I have
it running for 2 days now on my pc (win2Ksp3 P4 2GHz,512MB Ram - framework
v1.0.3705) and the taskmanager reports that this process takes 97MB ram/130
VMemory and it looks that its eating up more ram(!!).

To help out the garbage collector I tried to use as much stacked based
variables. Also for the objects created if they had a dispose() method I am
calling it when I am done with the object. If the objects dont have a
dispose() method, I am setting the refference to null. I am using ADODB to
get a recordset from a VB DLL. What is the best way to tell the GC that I am
done with the object, since the ADODB.RecordClass does not have a dispose
method?

Do they suffice?? Do you have links to relevant articles??

Any help will be much appreciated,
-George.

 

[Jon Skeet]

I am not using GC.Collect(), because of some MSDN articles suggesting to
leave the GC alone to figure things out about the mem usage on the app. If
you want I can send you these articles.

No, I quite agree that for the most part you should let the GC get on
with it. However, when diagnosing problems, you should consider calling
GC.Collect() periodically and seeing whether or not it reduces the
memory. If it does, then the effect you're seeing is just the GC not
being terribly aggressive. If it doesn't, you've probably got a leak
somewhere.

My app works on async calls on the TCP and I dont have a main thread. Should
I call gc.collect() every time I finish servicing a tcp message?

Certainly not every message. If the GC is being much too timid, you
could *consider* calling it every half hour, say - or possibly if the
total memory is above a certain level.

 

[George Gre]

OK. I will try it and see what happens.

I got another question:
When using COM+ dll was is the best option of activation new() or
server.CreateObject()?
When done with the object just nulling the refference will gc know that the
object is to be collected? The object does not have a Dispose() method..

George

 

[George Gre]

I have added the GC.Collect() (for testing only) after I am done servicing
tcp request, as Jon suggested .

I am running my service for 1 hour now and the mem usage now varies between
14.3MB to 15MB and VM 7.5MB and stays there!!!

So it looks that I dont have a memory leak, its just that the gc was not
proporly collecting the objects.
Maybe because I am usinginterop, since I call a COM+ vb dll during servicing
the tcp requests. Or maybe because I use very small byte arrays (<50bytes)
and the gc never decides to free them.

It looks that the framework has a problem. Now I am thinking that I need to
upgrade to framework 1.1 (I got 1.0.3705).

Jon many thanks for your suggestion.

George.

 

[Chris Torgerson]

Also, take a look at The ReleaseComObject call on the
system.runtime.interopservices.marshal class. It should address some of
your COM disposal.

chris torgerson

OK. I will try it and see what happens.

I got another question:
When using COM+ dll was is the best option of activation new() or
server.CreateObject()?
When done with the object just nulling the refference will gc know that the
object is to be collected? The object does not have a Dispose() method..

George
app.

 

[Mark Pearce]

Hi George,

When you measure memory usage of your process, are you measuring the memory
allocated or the memory actually used? If you're measuring the memory
allocated, it's not a problem as that memory will be re-allocated if other
apps need it.

I would be very wary of calling GC.Collect on a regular basis in a
production app. The GC has a good understanding of the local environment,
and usually a much better understanding of GC-related memory and performance
issues than the developer.

Regards,

Mark
--
Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128


I have added the GC.Collect() (for testing only) after I am done servicing
tcp request, as Jon suggested .

I am running my service for 1 hour now and the mem usage now varies between
14.3MB to 15MB and VM 7.5MB and stays there!!!

So it looks that I dont have a memory leak, its just that the gc was not
proporly collecting the objects.
Maybe because I am usinginterop, since I call a COM+ vb dll during servicing
the tcp requests. Or maybe because I use very small byte arrays (<50bytes)
and the gc never decides to free them.

It looks that the framework has a problem. Now I am thinking that I need to
upgrade to framework 1.1 (I got 1.0.3705).

Jon many thanks for your suggestion.

George.

 

[George Gre]

For anyone still interested:

I have apllied the SP2 for the .NET framework and re-run my test. I left my
service running for almost 4 days(!) and it looks
like that the SP2 did the trick. The service does not look to have any
memory leaks and the service is behaving fine!

-George.

The GC:Collect() was only used to prove that my code does not leak memory.
Also using the profiler from systech.com I could
see that equal number of objects created where destroyed, but task manager
still reported that the apps memory usage was always going
upwards. Also the DLLHOST.exe that was hosting my COM+ app was leaking
memory (mem usage was going upwards..).I suppose the gc was not releasing
the
references on the COM+ objects.

After using GC.Collect and ReleasCOMRef, I was able to prove that atleast my
code was not behaving that bad!!!

Today I will apply the SP on the framework and rerun my testing with out the
GC.Collect() and ReleaseCOMRef, and see what happens.

- George

 

[Chris Hornberger]

If you're using a very tight loop in your program and have to idle
time, GC may *never* run or may not run until the system absolutely
deems it 100% necessary. Too many people do something like:

for(;{
CheckForConnections();
}

and wonder why things are having problems. Is something like this in
effect in your program?