Tracing Program Memory Usage

  • Thread starter Thread starter Stewart Berman
  • Start date Start date
S

Stewart Berman

Windows XP SP3 32bit with all patches
..Net 2.0 with all patches
VS 2005 with all patches.

I am trying to track the memory use of an application. I put the following code in a function that
is called every 45 minutes:
process = process.GetCurrentProcess()
lMemoryInUse = process.VirtualMemorySize64
lMemoryInUsePeak = process.PeakVirtualMemorySize64
process.Dispose()
process = Nothing
TraceWriteLine(Format$(Now(), "yyyyMMdd HH:mm:ss.fff: ") & "Memory in use: " &
lMemoryInUse.ToString() & ", Peak Memory in use: " & lMemoryInUsePeak.ToString())

The trace output has:
20090719 17:49:18.375: Memory in use: 150937600, Peak Memory in use: 166055936

However, Task Manager shows the following for the application:
Mem Usage: 5,980 K
Peak Mem Usage: 65,060 K
VM Size: 18,912 K

Why is the memory usage obtained from the process so much larger than what Task Manager shows?
 
Hi,

You need to change what you are using in your code:

Task Manager "Mem Usage" column = WorkingSet64
Task Manager "Peak Mem Usage" column = PeakWorkingSet64
Task Manager "VM Size" column = PrivateMemorySize64
 
| Hi,
|
| You need to change what you are using in your code:
|
| Task Manager "Mem Usage" column = WorkingSet64
| Task Manager "Peak Mem Usage" column = PeakWorkingSet64
| Task Manager "VM Size" column = PrivateMemorySize64

John is right.

The value returned by the VirtualMemorySize64 property represents the
current size of virtual memory used by the process. The operating system
maps the virtual address space for each process either to pages loaded in
physical memory, or to pages stored in the virtual memory paging file on
disk. It looks normal in the size that you showed.

To get the physical memory in use, the WorkingSet64 property is the right
way to go.

Reference:
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.virtualme
morysize64.aspx
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.workingse
t64.aspx

Regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
The value returned by the VirtualMemorySize64 property represents the
current size of virtual memory used by the process. The operating system
Click to expand...

According to the Task Manager help:
Virtual Memory Size
In Task Manager, the amount of virtual memory, or address
space, committed to a process.

PrivateMemorySize64 is defined as:
The value returned by this property represents the current size of memory used by the process that
cannot be shared with other processes.

The two items appear to be the same as you and John stated.

VirtualMemorySize64 is defined as:
The value returned by this property represents the current size of virtual memory used by the
process. The operating system maps the virtual address space for each process either to pages loaded
in physical memory, or to pages stored in the virtual memory paging file on disk.

Does the difference between VirtualMemorySize64 and PrivateMemorySize64 represent shared code that
is mapped into more than one address space? What if my process is the only one that is using code
that can be shared? Where does that show up?
 
The value returned by the VirtualMemorySize64 property represents the
current size of virtual memory used by the process. The operating system
Click to expand...

Actually, as described, I would be interested in the VirtualMemorySize64 value as the working set
size would not necessarily show a memory leak since the leak would probably not be referenced and
thus would be paged out.
 
Does the difference between VirtualMemorySize64 and PrivateMemorySize64
represent shared code that is mapped into more than one address space?
Click to expand...

Not only code, could also be data.
What if my process is the only one that is using code that can be shared?
Click to expand...

I don't think it's possible. Are there any processes don't use Windows
kernel DLLs which are typical code that is shared across all processes?

There are two books explains the memory story quite well: Windows via C/C++
(Jeffrey Richter and Christophe Nasarre) and Windows Internals (Mark
Russinovich). It will take some time to read through, but definitely worth
the time.

Regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Yes, you're right.

However, a growing value of VirtualMemorySize64 can't tell if there is a
leak or not. Especially you're now in the world of CLR, where the memroy
usage is mostly managed automatcially.

To detect a managed leak, we'll need to use some tools, this blog post is a
good starting point:
http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

Regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for the reference. I haven't really looked at memory management since my C/C++ days. Of
course I do have scars that itch if I don't manually release -- close, dispose, set to nothing --
any objects before they go out of scope. Many of them were acquired using VB6 (and earlier) and VBA
in Access before it stopped using its own VB engine.
 
Stewart Berman said:
According to the Task Manager help:
Virtual Memory Size
In Task Manager, the amount of virtual memory, or address
space, committed to a process.

PrivateMemorySize64 is defined as:
The value returned by this property represents the current size of memory
used by the process that
cannot be shared with other processes.

The two items appear to be the same as you and John stated.

VirtualMemorySize64 is defined as:
The value returned by this property represents the current size of virtual
memory used by the
process. The operating system maps the virtual address space for each
process either to pages loaded
in physical memory, or to pages stored in the virtual memory paging file
on disk.

Does the difference between VirtualMemorySize64 and PrivateMemorySize64
represent shared code that
is mapped into more than one address space? What if my process is the
only one that is using code
that can be shared? Where does that show up?
Click to expand...

No. VirtualMemorySize64 is the current reserved bytes for the
process. FYI: This number is not available in Task Manager, but
is available in Performance Monitor as Process: Virtual Bytes.

Please see Chapter 7: Reserving and Committing Pages in
Microsoft Windows Internals, Fourth Edition for more info.

Generally you would track Private bytes (PrivateMemorySize64),
over time to see if it is increasing.

[snip]

Take a look at .NET Memory Profiler for troubleshooting leaks:

http://memprofiler.com

Also CLR Profiler as well as any tools/info that Jie Wang
mentioned.
 
Back
Top