Private bytes vs bytes allocated by .NET heaps

m_peretz

We just got ANTS.NET to find out why our application is taking over 150M of private bytes. According to the profiler, only 20M of memory is used for all managed heaps. At that point, I am stuck wondering where the other 120M are allocated. We are using dispose everywhere and we made sure there is no leak. But… the memory is still over a 150M. Using SetProcessWorkingSet is just a hack and does not solve the problem; it simply swaps the memory to disk, but does not free anything. I need to know why the unmanaged memory is so high. We are not using non-managed DLLs, and we are not using any COM.

Brian Donahue

Hello,

How do you determine how many private bytes are being used? When I use the performance counter # of bytes in all heaps in perfmon for the one .net application that I happen to be profiling and compare this to profiler's information, it matches very closely.

Are you comparing ANTS Profiler results to data gathered from Perfmon? If so, which counters do you compare it against?

m_peretz

The private bytes is performace counter under the process title. That counter is far greater then CLR Memory # of bytes in all heaps.

Brian Donahue

Hello there,

This performance counter is a bit misleading. It includes the .NET runtime and some other things. I happened across this blog entry that seems to explain why this is probably the wrong counter to use:

http://www.itwriting.com/dotnetmem.php

Note: we are not affiliated with the people who happen to run this site...

m_peretz

My problem is that our target machine is a mchine with no virtual memory. Therefore private bytes is the right counter to use, it indicates exactly how many bytes are used by the process. The BLOG you sent me confirms this

So what are these Private Bytes? This is memory allocated to the process that cannot be shared by other processes. It is probably the most useful single figure when you want to know “How much memory does my app use?” It still needs qualification. As we’ve seen, the Private Bytes may not all be in physical memory. If they are swapped to disk, and the user isn’t actively using the application, then they aren’t having much impact on other applications

It is the working set size that is misleasing.

so at the end, I am looking at huge private bytes count compare to the managed heap count, and with no way to understand why it is so high.

Brian Donahue

Hi,

You're probably not going to get this information from a memory profiler. Our profiler is only concerned with tracking the objects that have been allocated in code and is unaware of the internal machinations of the .NET Framework, for the most part.

The private bytes, I'd assume, include all of the resources compiled into the program and the program code itself.