Red Gate forums :: View topic - Unmanaged memory but perfmon result differs
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
ANTS Memory Profiler 7
ANTS Memory Profiler 7 forum

Unmanaged memory but perfmon result differs

Search in ANTS Memory Profiler 7 forum
Post new topic   Reply to topic
Jump to:  
Author Message
ngodugu



Joined: 31 Jan 2011
Posts: 6

PostPosted: Tue Feb 15, 2011 9:04 pm    Post subject: Unmanaged memory but perfmon result differs Reply with quote

Hi All,

I used the red gate memory profiler to profile my app and Redgate showed about 1.3GB in unmanaged memory. That is huge.

After going nowhere with redgate as it was unmanaged memory, I used perfmon to track the following counters on my app.

Total Bytes in all heaps (.NET CLR Memory)
and
Private Bytes(Process)

This showed that in fact it was Total Bytes in all heaps that was growing and from what I have read this indicates a managed memory leak.

What gives with the unmanaged memory being shown in the redgate tool?

How should I proceeed?

Thanks in advance
Neelima
Back to top
View user's profile Send private message AIM Address
AndrewH



Joined: 17 Aug 2006
Posts: 137

PostPosted: Wed Feb 16, 2011 3:21 pm    Post subject: Reply with quote

The report on unmanaged memory in ANTS Profiler is all memory that is private, committed and not allocated to .NET. When added to the .NET memory usage, it will correspond roughly to the private bytes performance counter.

.NET 1.1 doesn't report the amount of unused memory in the heaps it is using to the profiler, so unused .NET memory will be reported as unmanaged in this version of .NET as the profiler can't distinguish it (in .NET 2.0 and later, this is reported as 'free' memory and properly subtracted from the 'unmanaged' measurement).

I think that the # bytes in all heaps counter does include unused heap memory in .NET 1.1, so you can still work out the amount of free memory from that. A high proportion of free to used memory is a classic sign that your application is suffering from issues caused by heap fragmentation.

Note that the # bytes in all heaps performance counter is misleading and often doesn't report an accurate value as it's only updated after a garbage collection. Most commonly, it reads too low but there do seem to be circumstances where .NET will release memory without updating the counter, which causes it to read too high. Taking a snapshot performs a full garbage collection, so will force this counter to update to the correct value.
_________________
Andrew Hunter
Software Developer
Red Gate Software Ltd.
Back to top
View user's profile Send private message
ngodugu



Joined: 31 Jan 2011
Posts: 6

PostPosted: Wed Feb 16, 2011 11:05 pm    Post subject: Reply with quote

Andrew,

Thanks for the prompt and detailed reply. How do we proceed from here using red gate profiler to figure out if there is a memory leak. As the unmanaged memory is not accounted for the in the class list.

Thanks
Neelima
Back to top
View user's profile Send private message AIM Address
AndrewH



Joined: 17 Aug 2006
Posts: 137

PostPosted: Mon Feb 21, 2011 12:29 pm    Post subject: Reply with quote

Hi,

It really depends on what you think the problem is. If you're running on .NET 1.1 and you suspect fragmentation, you should probably start by reading this article, which describes how the situation arises:

http://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/

If you can get your application running on .NET 2.0 for the purposes of profiling, you will have an easier time of debugging this issue as the profiler can provide more information.

Fixing these problems tends to be rather involved. You can find which objects are on the large object heap using the filter panel: almost certainly this will be some arrays. You will need to either change the order in which these are allocated so that all the long-lived arrays are allocated early on in the program's lifetime, or work out how to substitute arrays that don't end up on the large object heap.

If the problem is actual unmanaged memory usage, the memory profiler won't be able to help if the component with the leak is itself unmanaged. If you aren't using your own or any third-party unmanaged components, this is fairly unlikely, however. If the problem is .NET components that reference unmanaged objects, you just need to find the leaked .NET components and fix them to reduce the unmanaged memory usage. You can do this by looking at the instance counts. I posted a possible strategy for this here:

http://www.red-gate.com/MessageBoard/viewtopic.php?t=12658
_________________
Andrew Hunter
Software Developer
Red Gate Software Ltd.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group