I have an application here that seems to be using way more memory than it should. A memory snapshot just after a large operation shows roughly 138 megabytes of managed instances, and 78 megabytes of unmanaged instances. However, the private bytes performance counter shows over 820 megabytes usage. There is also (in the native memory tab) a large amount of memory under Private->Other Data-><Other>, in both the Physical and Commited windows.
Is there anyway to determine what this <Other> field is talking about?
I'm afraid that I cannot find a good explanation for the large amount of private bytes used by your application. The resource tracker should track all memory allocations performed by the application, so you should at least see a lot of memory presented as "VirtualMemory".
It seems like the resource tracker fails to track some memory allocations in your application, or it maybe wrongly identifies it as managed heap memory (VirtualMemory used for the managed heaps are not presented by the resource tracker).
We will do additional testing on the resource tracker before releasing a beta, but we have currently not experienced a problem like yours. Is there any possibility to provide us with an application that causes this problem? If there is, please contact us at email@example.com.
SciTech Software AB
managed heap: 20M
private other: 40M
win32 heap: 28M
potentially shared other: 157M
managed heap: 4M
private other: 22M
win32 heap: 16M
potentially shared other: 308K
Virtual memory: 20M
Total native: 23M
So, resource tracker seems to show only a small part of all unmanaged allocations?
Event in physical memory case, WinHeap+Other gives about 40M, but tracker shows only 20M of virtual allocations.
E.g. if a call to HeapAlloc for 100 bytes causes a larger memory block to be allocated, say a 1MB VirtualAlloc memory block, then the memory allocated by VirtualAlloc will not be presented in the snapshot views.
We decided to present the memory this way, since such "nested" memory is more of a side effect of memory allocation algorithms. However, we still keep records of all memory allocated, and it was our intention to use information collected by the resources tracker to provide more detailed information in the native memory view. Unfortunately, due to time-constraints this information was never used in the v3.0 release. We're working on it, and the v3.1 release will have more detailed native memory information.
You can also read about the native memory view in my blog post "The â€œOther dataâ€“> <Other>â€ node".
SciTech Software AB
Users browsing this forum: No registered users and 14 guests