By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,900 Members | 1,078 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,900 IT Pros & Developers. It's quick & easy.

Memory usage. ( H E L P ! ! )

P: n/a
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.
Nov 13 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
George Gre <Gi*****@totalise.co.uk> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Nov 13 '05 #2

P: n/a
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
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP***********************@news.microsoft.com. ..
George Gre <Gi*****@totalise.co.uk> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Nov 13 '05 #3

P: n/a
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.

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP***********************@news.microsoft.com. ..
George Gre <Gi*****@totalise.co.uk> wrote:
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()?


That I don't know much about, I'm afraid - I try to avoid COM wherever
possible!
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..


You don't need to null the reference variable if it's either a local
variable which is going to fall out of scope or not be used for the
rest of the method, or if it's an instance variable but the whole
object itself is going to become eligible for collection soon.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Nov 13 '05 #4

P: n/a
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

"George Gre" <Gi*****@totalise.co.uk> wrote in message
news:uK**************@tk2msftngp13.phx.gbl...
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
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP***********************@news.microsoft.com. ..
George Gre <Gi*****@totalise.co.uk> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too


Nov 13 '05 #5

P: n/a
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
"George Gre" <Gi*****@totalise.co.uk> wrote in message
news:uQ**************@tk2msftngp13.phx.gbl...
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.

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP***********************@news.microsoft.com. ..
George Gre <Gi*****@totalise.co.uk> wrote:
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()?


That I don't know much about, I'm afraid - I try to avoid COM wherever
possible!
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..


You don't need to null the reference variable if it's either a local
variable which is going to fall out of scope or not be used for the
rest of the method, or if it's an instance variable but the whole
object itself is going to become eligible for collection soon.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too


Nov 13 '05 #6

P: n/a
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.
"Nostromo" <bo***@bogus.com> wrote in message
news:OE**************@tk2msftngp13.phx.gbl...
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

"Mark Pearce" <ev**@bay.com> wrote in message
news:e6**************@tk2msftngp13.phx.gbl...
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
"George Gre" <Gi*****@totalise.co.uk> wrote in message
news:uQ**************@tk2msftngp13.phx.gbl...
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.

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP***********************@news.microsoft.com. ..
George Gre <Gi*****@totalise.co.uk> wrote:
> 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()?

That I don't know much about, I'm afraid - I try to avoid COM wherever
possible!

> 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..
You don't need to null the reference variable if it's either a local
variable which is going to fall out of scope or not be used for the
rest of the method, or if it's an instance variable but the whole
object itself is going to become eligible for collection soon.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too



Nov 13 '05 #7

P: n/a
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?

"George Gre" <Gi*****@totalise.co.uk> wrote in message news:<uC**************@TK2MSFTNGP10.phx.gbl>...
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.

Nov 13 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.