App uses 5MB of managed memory but 150MB of operating system

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
Dave Gibson
Posts: 5
Joined: Thu May 17, 2007 4:24 pm

App uses 5MB of managed memory but 150MB of operating system

Post by Dave Gibson » Thu May 17, 2007 5:40 pm

Our C# app collects and analyzes data from sql server that it then displays using third party (Developer Express) grid controls.

Windows Task manager shows the memory usage to be 150MB when the app is not being profiled.

Memory Profiler v3.0.114.C shows the managed memory used by the app to be 5MB, and the unmanaged memory to be 45MB.

We're a little concerned that there is 145MB of operating system memory being taken up that doesn't appear to be due to the objects we have created in our app.

Is this a reasonable/normal overhead to expect, or is there anywhere we should be looking to reduce this overhead?

Thanks,

Dave.

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Fri May 18, 2007 12:22 pm

Having a memory usage of 150MB in a process that only uses 5 MB of managed data does not seem reasonable, especially when the resource tracker is only able to identify 45 MB of memory. What information do you get from the Native memory view? Do you have a lot of memory usage under the Other data-><Other> node?
Best regards,

Andreas Suurkuusk
SciTech Software AB

Dave Gibson
Posts: 5
Joined: Thu May 17, 2007 4:24 pm

Post by Dave Gibson » Fri May 18, 2007 1:04 pm

I'm looking at the Native Memory tab, Show Memory of snapshot, Physical Memory:

Private: 185,896
Managed Heaps: 12,860
Normal heap: 4,684
Large heap: 276
Overhead: 7,900
Code: 45,882
...
<Other>: 43,662
JIT: 2,562
Win32 heaps: 82,660
Other data: 40,932
...
<Other>: 40,032
Shared: 5,632
Managed heaps: 0
Code: 4,580
Win32 heaps: 8
Other data: 1,044
Potentially Shared: 31,528
Managed heaps: 0
Code: 30,728
Other data: 800

It looks like the majority of the unclassified memory is in:
Private > Win32 heaps and
Private > Other data > <Other>

Dave.

Dave Gibson
Posts: 5
Joined: Thu May 17, 2007 4:24 pm

Post by Dave Gibson » Fri May 18, 2007 1:10 pm

All of the formatting appears to have been removed on my previous post. I had intended to present the data from the Native memory tab as:

Private: 185,896
...Managed Heaps: 12,860
......Normal heap: 4,684
......Large heap: 276
......Overhead: 7,900
...Code: 45,882
......<Other>: 43,662
...JIT: 2,562
...Win32 heaps: 82,660
...Other data: 40,932
......<Other>: 40,032
Shared: 5,632
...Managed heaps: 0
...Code: 4,580
...Win32 heaps: 8
...Other data: 1,044
Potentially Shared: 31,528
...Managed heaps: 0
...Code: 30,728
...Other data: 800

Dave.

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Sun May 20, 2007 9:31 pm

Your numbers from the native memory view does look at little odd, but the profiler does affect these numbers when profiling an application, especially when the resource tracker is enabled. Have you tried examining the native memory without enabling the resource tracker?

If you attach to a process you will get as accurate numbers as possible, especially for the first snapshot (a snapshot will affect the physical memory usage, since investigating the memory will force pages to be loaded into physical memory). You can also try to enable low impact profiling (using the Tools->Options dialog). This will also provide less information about managed allocations, but the native memory information will be more accurate.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Dave Gibson
Posts: 5
Joined: Thu May 17, 2007 4:24 pm

Post by Dave Gibson » Mon May 21, 2007 8:59 am

I have tried running the profiling as you suggest. This still appears to show the majority (80 - 90 MB) of data used by the Win32 heap and Other data -> <Other>. Here is what I am seeing:

Low impact profiling set. Starting the process with the unmanaged resource tracker disabled:

Private: 139,540
...Managed Heaps: 13,940
......Normal heap: 5,478
......Large heap: 260
......Overhead: 8,202
...Code: 26,743
......<Other>: 23,731
...JIT: 2,245
...Win32 heaps: 58,416
...Other data: 38,196
......<Other>: 37,224
Shared: 6,268
...Managed heaps: 0
...Code: 5,216
...Win32 heaps: 8
Other data: 1,044
Potentially Shared: 21,068
...Managed heaps: 0
...Code: 19,407
...JIT: 929
...Other data: 732


Low impact profiling set. Attaching to the process:

Private: 121,956
...Managed Heaps: 7,963
......Normal heap: 7,695
......Large heap: 268
......Overhead: 0
...Code: 30,040
......<Other>: 27,108
...Runtime heap: 24
...Other data: 80,245
......<Other>: 79,429
System: 3,684
Shared: 6,020
...Managed heaps: 0
...Code: 4,916
...Other data: 908
System: 196
Potentially Shared: 20,172
...Managed heaps: 0
...Code: 19,124
...Other data: 484
...System: 564

Dave.

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Mon May 21, 2007 8:17 pm

I'm afraid that I don't have a good explanation for these numbers. They seem a bit high but I don't know whether they indicate a memory problem in your application or not.

You have a lot of Private code which is not associated with any file, which is a bit strange. Normally code is either (potentially) shared code which is part of a DLL (e.g. unmanaged Windows libraries), or JITted .NET code. Unidentified private code indicates generated code of some sort.

The resource tracker should be able to most of the Win32 heap memory that was allocated after the profiler was initialized, but it will only show actually allocated instances, not all memory that is committed for the heaps.

We are working on improving the way memory is presented under the Native memory view. The improvements will be included in the v3.1 release, and hopefully they will provide better information in a situation like yours.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Dave Gibson
Posts: 5
Joined: Thu May 17, 2007 4:24 pm

Post by Dave Gibson » Tue May 22, 2007 8:36 am

Ok, the memory usage isn't a showstopper at the moment - just something we were interested/concerned about. We'll give it some more thought and maybe come back to it at a future date.

Thanks,

Dave.

Post Reply

Who is online

Users browsing this forum: No registered users and 24 guests