Memory Managment and Garbage Collection

  • Thread starter Thread starter Greg Merideth
  • Start date Start date
G

Greg Merideth

An app that I'm working on literally went from 4mb of ram usage (using
process manager to view it) to 22mb of ram to run by adding two new
forms. As I've been running my apps I've noticed a larger memory usage
although I can't quite pin down what causes it.
 
I was following this kind of thread for months and months.



Nobody could give a coerent answer.



I did a medium App and it takes between 60 and 120MB when is running. I
cannot think what the heck is taking all the memory.



..Net consume ALL THE MEMORY THAT IT CAN, I read A LOT about the garbage
collector, and if windows has memory free not used by anybody, then the
framework is going to take it, when the garbage collector "think" is time to
clean up, he will do it.

If another app require memory, the GC is going to free it.



My entire conclusion when to that path.



I love .Net environment (C#). I think is the best language ever. But the
memory management SUCKS, I bought 3 profilers, and it still it produce
memory leaks, with the events references specially, I think still is a young
environment and need more tools.



Conclusion, Right now you will come crazy to know what the hell is doing
with the memory and none tool is going to tell you who is using it.



My profilers show 8 MB taken, and the Task Manager is almost 96MB, so.......
I'm still wondering if somebody knows how to open the REAL memory taken to
see what is inside. (Some .Net Guru outside???)



Regards,

Gustavo
 
This only proves you should learn how to use your tools, if a profiler shows
8MB managed memory consumption, but the task manager shows 96 MB, it means
that most memory is non managed (code and data), and therefore cannot be
collected by the GC.
Another point is that most people use Taskmanager to look at memory counters
while they should use Perfmon to watch managed/unmanaged memory count, you
should know exactly what counters to look at and have some good knowledge of
the internal workings of the OS memory manager and the GC (and NO the GC is
not a memory manager its a users heap manager).

Willy.
 
There's a lot of good information on GC in .NET on newsgroups already, if
you want to search groups.google.com for GC, WorkingSet Forms etc. where
folks more knowledgeable than I have explained it at length.

For an app that shrinks it's working set regularly, see my "self-shrinking
working set" sample here:
http://blogs.geekdojo.net/richard/posts/338.aspx

Richard
 
Richard,

While there is nothing wrong with the sample, this is something you should
consider whit care, it's not up to a user process to take over the task of
the memory manager.
The OS (WS manager) knows exactly when/what pages should be removed from the
processes WS when it sees fit.
When tuning the WS of a running (active) process when there is enough free
memory is available, you will only:
- induce IO overhead as you move pages to the paging file (IO) and
- induce (initially unnecessary) page faults and associated IO when
reloading the needed pages.
When the OS trims working sets it will try to remove non active pages from
ALL process first until enough free pages are available to honor the memory
request.

Willy.
 
I agree with you, definately. I should probably put a strong warning on
that sample (in fact I think I will!); I wrote it after reading a bunch of
"my client thinks .NET is a hog because my WinForm app takes up so much
memory" posts - since people are probably going to call the GC class
directly at any rate. There's no doubt that it *should* be left up to the
OS.

Thanks,
Richard

--
C#, .NET and Complex Adaptive Systems:
http://blogs.geekdojo.net/Richard
Willy Denoyette said:
Richard,

While there is nothing wrong with the sample, this is something you should
consider whit care, it's not up to a user process to take over the task of
the memory manager.
The OS (WS manager) knows exactly when/what pages should be removed from the
processes WS when it sees fit.
When tuning the WS of a running (active) process when there is enough free
memory is available, you will only:
- induce IO overhead as you move pages to the paging file (IO) and
- induce (initially unnecessary) page faults and associated IO when
reloading the needed pages.
When the OS trims working sets it will try to remove non active pages from
ALL process first until enough free pages are available to honor the memory
request.

Willy.
Click to expand...
 
I've been noticing that all of my .NET apps seem to progressivly use more
and more memory. Even after several reworks of the code I can only manage
to slow the growth. Is there some Garbage Collection caveat that's holding
old data into higher generations accidentlly? Has anyone else noticed this?
 
Richard A. Lowe said:
I agree with you, definately. I should probably put a strong warning on
that sample (in fact I think I will!);
Click to expand...

Great idea.
Whats great when using such samples, is that you show how things work, but
also that you can warn for the side effects and show how to perform things
like page IO and page fault accounting, which is much MORE important than
trying to trim working sets when there is no need for it.

Willy.
 
Back
Top