Using GC.Collect() in a timer

[Guest]

Hello,

I am wondering if it is a good idea to use GC.Collect() in a timer. For
example, timer is fired every 5 minutes and calls GC.Collect().

In our server app the memory goes to 600MB and stays there. The memory
hardly goes down. When I disconnect the client and the connect it again the
memory could reclaim to 400MB. But it could go down to 50 MB.


The reason that the memory goes that much high is that has to fill the
dataset with huge data.

thanks,

Mike

 

[Peter Duniho]

Hello,

I am wondering if it is a good idea to use GC.Collect() in a timer.
For example, timer is fired every 5 minutes and calls GC.Collect().

It's not even a good idea to use GC.Collect() without a timer.

In our server app the memory goes to 600MB and stays there. The
memory hardly goes down. When I disconnect the client and the connect
it again the memory could reclaim to 400MB. But it could go down to
50 MB.

But does it need to? Even assuming you're monitoring memory usage
correctly, the fact that there appears to be such a large amount of
memory being held is not necessarily a problem. Assuming that if and
when you actually need to _use_ that memory, you get it as necessary,
there's nothing to worry about.

Pete

 

[Nicholas Paldino [.NET/C# MVP]]

There are some very specific instances where it is a good idea to make a
manual call to Collect, but in a server environment, it's rare (because
those instacnes are when you have a non-recurring or rarely occuring event,
which is unlikely in a server environment). See Rico Mariani's blog entry
on the matter for more information:

http://blogs.msdn.com/ricom/archive/2004/11/29/271829.aspx

Specifically, Rule #2. I do agree that generally, Rule #1 is pretty
much always the standard, and I personally haven't found a reason to use
GC.Collect in code I've written yet.

I definitely don't see anything in the post here that says that Rule #2
should be applied here.

I also completely agree with the statement about it not mattering if
your memory consumption is high on the server. Referring the blog entry
above, you want the server to get into that sweet spot where the GC is tuned
correctly to the behavior of your app, and constantly shifting memory
consumption isn't going to help that.

If I had to guess (and I could be wrong) as well, I agree with you that
the OP is probably looking at the working set in Task Manager, and not the
actual performance counters. And as we all know, the working set in Task
Manager <> memory consumption.

 

[Guest]

I am wondering if it is a good idea to use GC.Collect() in a timer. For
example, timer is fired every 5 minutes and calls GC.Collect().

In our server app the memory goes to 600MB and stays there. The memory
hardly goes down. When I disconnect the client and the connect it again the
memory could reclaim to 400MB. But it could go down to 50 MB.

The reason that the memory goes that much high is that has to fill the
dataset with huge data.

Generally extra GC's will:
- decrease overall throughput
- reduce differences in throughput over time

But once every 5 minutes sounds as a complete waste of time.

Arne

 

[Guest]

What if we call GC.Collect() once every 30 minutes?

I have found that it reduces the memory from 500MB to 200MB in the task
manager.

 

[Peter Duniho]

What if we call GC.Collect() once every 30 minutes?

I have found that it reduces the memory from 500MB to 200MB in the
task manager.

But why do you care what the memory usage shown in Task Manager is?

Unless there is some demonstrable performance issue that you're trying
to solve, you should not be messing with GC.Collect(). It's a waste
of time and can actually interfere with the normal, reliable,
efficient operation of the garbage collector.

Just let the garbage collector decide when and how to manage the
memory. That's its job, and in the vast majority of situations it
knows how to do that job much better than you or I do.

Pete

 

[Guest]

Yes, I do not need to care. Iwas just wondering.

But, what about the UI? The ListView is loaded with millions of items and
the memory goes to more than 1GB, but when I close the form, it is not
reclaimed. So, is GC a good idea in a timer in the UI client?

 

[Peter Duniho]

Yes, I do not need to care. Iwas just wondering.

But, what about the UI? The ListView is loaded with millions of
items and the memory goes to more than 1GB, but when I close the
form, it is not reclaimed.

Define "reclaimed". Are you seeing some genuine performance problem?

If not, then don't worry. If you are, then there's almost certainly a
better way to deal with it than calling GC.Collect().

So, is GC a good idea in a timer in the UI
client?

No.

Pete

 

[Nicholas Paldino [.NET/C# MVP]]

Mike,

With all due respect, one million items is a ridiculous amount of items
to have in the ListView. I strongly suggest finding a different way of
presenting the information to the user, as being able to process one million
items at once is a challenge for anyone.

Additionally, if you must use that many items in the ListView, are you
at least virtualizing it, instead of creating one million ListViewItems?

 

[Chris Dunaway]

Yes, I do not need to care. Iwas just wondering.

But, what about the UI? The ListView is loaded with millions of items and
the memory goes to more than 1GB, but when I close the form, it is not
reclaimed. So, is GC a good idea in a timer in the UI client?
--

I don't know what your UI is presenting, but IMO, if you have a
million (or more) items in a ListView, you have a flawed design. A
user could spend hours trying wade through a million items in a
listview.

Chris