It seems the "#Bytes in all Heaps" perfmon counter (from category .NET CLR Memory) is heavily impacted by the use of MemProfiler, and not in the expected direction:
When launching our application from MemProfiler, I get following perfmon counts:
PrivateBytes = 677 Mb
# Bytes in all Heaps = 52 Mb
When doing the same thing without MemProfiler, I get:
PrivateBytes = 336 Mb
# Bytes in all Heaps = 192 Mb !!!
I expected the privatebytes count to be smaller, by I can not understand why the MemProfiler reduces so much the Gc Heap !
The strange thing is that MemProfiler do not "see" the 192 Mb. Most of the memory is placed under "Kernel VirtualMemory", and the .NET share is reduced to 38 Mb, which is more or less consistent with 52 Mb from perfmon. This led to miss that a fonctionnality of our software has a big memory footprint.
Can you provide some more information about your application? Is it a server application or a desktop application?
You mentioned that the profiler doesn't "see" the 192 MB, except as "Kernel VirtualMemory". But the 192MB "Bytes in all Heaps" occurred when not running under the profiler. How was the profiler able to see this memory when not profiling?
SciTech Software AB
The native C++ part includes the STLPORT implementation of STL, as well as the dlmalloc memory allocator. (Actually, the memory allocated through calls to "malloc" is still allocated by microsoft's default one, but it represents a small subset of our native memory)
About the 192 Mb, what I mean is that the application normally uses 192Mb of managed memory according to perfmon.
When ran under MemProfiler, this values falls to 52 Mb under same experimental conditions. In my previous post, I've made the assumption that
1. The 52 Mb do not really cover the whole Managed heap
2. The missing part of Managed heap is put under "Kernel virtual memory"
May be is this assumption wrong, but then I can not understand these values?
When are you reading the performance counter numbers? Have you collected a snapshot in the profiler before reading them?
What values do you get from the Native memory view? Do they correspond to the performance counter numbers?
SciTech Software AB
The values are those which are obtained at the end of the scenario applied in our software. When profiling, a single snapshot is taken at the end of the scenario (before reading the perfmon value). In both cases the perfmon curve remains flat at the end of scenario.
In order to reply properly to your native view question, I'll redo an experiment next week. Could you precise which corresponding values you would like to have?
Users browsing this forum: No registered users and 19 guests