"Claire" <as*******@ntlworld.com> wrote in message
news:eO**************@TK2MSFTNGP09.phx.gbl...
Im sat here watching task manager and the memory consumption of my
application rising second by second.
What tools are there out there for me to use to find where it's all going
please?
(I wish we were able to do garbage collection ourselves. Excruciatingly
poor idea microsoft. That's been the most annoying part of dotnet)
Ive looked at some web pages talking about using the gc class to force
garbage collection. Is this something that can break your application? I
am doing realtime data collection and need to keep creating and destroying
objects quickly.
thanks
Claire
Before you start measuring, you should have a good understanding on how the
Windows memory manager works, how and what kind memory gets allocated, this
is necessary because the managed heap is nothing else than a private Process
heap who's internal allocations are managed by the CLR/GC.
Read as much as you can about the GC and it's inner workings, don't take any
action before you perfectly understand all issues, don't think you can do
better than the GC itself, you won't.
A good start to learn about managed memory, are these Blogs, authored by the
CLR architects at MS.
http://blogs.msdn.com/maoni/archive/category/5507.aspx http://blogs.msdn.com/maoni/archive/...03/148029.aspx http://blogs.msdn.com/ricom/archive/category/2050.aspx http://msdn.microsoft.com/library/de...anagedcode.asp
And do as Rico suggests here:
http://blogs.msdn.com/ricom/archive/...29/271829.aspx
and here:
http://blogs.msdn.com/ricom/archive/.../02/40780.aspx
Don't use GC.Collect().
The garbage collector is self-tuning. By programmatically forcing a
collection with this method, the chances are you hinder rather than improve
performance.
To measure you have to use the right tools:
Start with the performance monitor and watch the:
- CLR's Memory (GC) performance counters.
Watch the sizes of the Gen0, 1, 2 and the LH heap, pay attention to
the GC collections/sec for each of the generations.
- Process memory counters.
Watch the private heap size and Working Set.
If it looks like a GC issue, that is GC memory consumption tends to climb
without returning.
Use a profiler to investigate how your application interacts with the
managed heap.
There exists an number of memory profilers for .NET, some are free other are
not, start with this one
http://download.microsoft.com/downlo...filer.exe.just to get an idea of what you can expect.Check this for a list of available profilers:
http://blogs.msdn.com/brada/archive/...398060.aspxbut also take a look at this and don't start measuring the wrong thing.
http://blogs.msdn.com/ricom/archive/...7/74659.aspxIf you think you got memory leaks you can't find using 1 and/or 2, you willhave to use some other tools.The first one I can think of is Windbghttp://www.microsoft.com/whdc/devtools/debugging/default.mspx, asophisticated debugger, that, when used with the sos.dll extension, allowsyou to peek at the internals of the CLR.Another tools is vadump included with the platform SDK or available fordownload from:
http://www.microsoft.com/windows2000...ump-o.aspWilly.