How can I tell the application total memory usage?

G

Guest

I have a .NET application written in C# running on a WinXP professional with
2GByte RAM.
The limit for this kind of application is 1.2 MBytes.
I need to know how much memory the application consumes.
So I opened the Windows task manager on the Processes tab that has the 'Mem
Usage' and 'VM Size'.

Does the application consume the 'Mem Usage' + 'VM Size' ?

If my .NET application memory limit is 1.2 MBytes, how can I see the amount
of memory my application is consuming concerning this limit? I mean; how can
I tell if my application is close or not close to that limit?
 
G

Guest

Data stored in Virtual Memory is not consuming any RAM. Virtual Memory is an
area of memory on your hard disk that can be used to look like extra RAM so
that programs can seem to use more RAM that the computer physically has.
Normally pages of process data are paged in and out of virtual memory as they
are needed.

You can get this kind of information for your application from the
System.Diagnostics.Process object. In your code you can write something like:

//Get the applications process
Process myProcess = System.Diagnostics.Process.GetCurrentProcess();

//There are a number of properties, the two shown below
//return the number of bytes consumed by the process
int intTotalMainMemoryUsage = myProcess.WorkingSet;
int intTotalVirtualMemory = myProcess.VirtualMemorySize;

Then do something based upon the values you retrieve.

Hope that helps
Mark R Dawson.

BTW -> a limit of 1.2MB of RAM for an app when you have 2GB to spare might
be a bit restricting for a .Net application. I think you may have problems
fitting a .Net app in 1.2MB of Main Memory, but I could be wrong.
 
G

Guest

Thanks Mark,

You did help.

I have started a discussion about a .NET application memory limit
http://msdn.microsoft.com/newsgroup...harp&mid=8f0e5dcc-5c58-4252-9ff6-bbb312b99d35

And now I wish to know if my application does get to the 1.2 GBytes limit or
not. So for that I tried to use the Windows Task Manager.
Yes, I familiar with how the VM works, But I'm not sure how to read the
Windows Task Manager to determine how much memory my application consumes and
if does or doesn't reach the 1.2 GBytes limit.

Does you suggestion of:
Process myProcess = System.Diagnostics.Process.GetCurrentProcess();
int intTotalMainMemoryUsage = myProcess.WorkingSet;

Now, is the intTotalMainMemoryUsage is the application memory usage? So if
it gets close to 1.2 GBytes, will throw an OutOfMemory exception?
 
G

Guest

Process myProcess = System.Diagnostics.Process.GetCurrentProcess();
int intTotalMainMemoryUsage = myProcess.WorkingSet;

Now, is the intTotalMainMemoryUsage is the application memory usage? So if
it gets close to 1.2 GBytes, will throw an OutOfMemory exception?

Yes - intTotalMainMemoryUsage is the amount of main memory used by your
applications process.

Now, is the intTotalMainMemoryUsage is the application memory usage? So if
it gets close to 1.2 GBytes, will throw an OutOfMemory exception?

Well - looking at the other thread you mentioned in your post, depending on
the type of objects you are creating (such as Arrays, arraylists) you might
get that exception before you reach the 1.2GB point. I am not sure you can
exactly determine when this exception will be thrown and try to stop it
happening.
 
G

Guest

Ok, that's good.

But what about the Windows Task Manager? Can I or can't I learn how much
memeory the application is consumimg? is it the 'Meme Usage' column? is the
'Meme Usage' + 'VM Size' columns?
 
S

S. Senthil Kumar

No, it's not. Mem Usage is the working set size i.e the number of pages
currently in memory. VM Size, IIRC, is the number of private
(non-shared) bytes that your application is using.

To get a true measure of the virtual address space your app is using,
I'd recommend using perfmon and the "Virtual bytes" performance
counter.

Regards
Senthil
 
W

Willy Denoyette [MVP]

Sharon said:
Ok, that's good.

But what about the Windows Task Manager? Can I or can't I learn how much
memeory the application is consumimg? is it the 'Meme Usage' column? is
the
'Meme Usage' + 'VM Size' columns?

No you can't simply add these two to calculate the amount of memory your
application is consuming, and you can't actually calculate the exact amount
of memory taken by a process using the performance counters but you can get
an estimate, but before we go and have a look at it, I would suggest you to
forget about Taskman and use perfmon.exe instead. The reason is that taskman
only tells you part of the story and the names of the counters are a bit
confusing; what is called "Mem Usage" in taskman is the "Process -
Workingset" size in perfmon, and "VM Size" is perfmon's "Process - Private
bytes" counter, the values of these counters in taskman are correct but they
might be misleading.
The "WorkingSet" of a process is the amount of RAM actually occupied by the
pages of a process, however, while this includes pages private to the
process it also consists of pages shared with other processes (the shared
pages).
The "Private bytes" represents the total of the pages, private to the
process, that have been committed (and possibly modified) by the program and
as such have been reserved on the paging file (Private bytes == Page File
bytes in perfmon). Part of it can be in the WS while the remaining pages are
effectively paged-out. Note that the GC heap memory is strictly private and
as such part of "private bytes", also the space taken by the assemblies
loaded and the JIT'd code is part of the "private bytes".
So, while it's obvious that you can't add the WS and Private bytes to
calculate the real amount of memory ACTUALLY committed by the process,
because you don't know exactly how much private bytes are part of the WS,
you can get a pretty good idea about your actual memory consumption by
looking at the "Virtual Bytes" counter.
But there is more, even if you have sufficient VM (that is FREE RAM + FREE
page file space) to accomdate the 2GB maximum of user space (or 3GB on 32
bit windows with PAE), it doesn't mean that you can (nor should) allocate
all free process space for managed objects, the reason is 'memory
fragmentation'.
When the CLR is loaded and ready to execute program code, you are left with
~1.6 GB free VM space (your milleage may vary depending on OS and CLR
version) and you can use almost all of it for small objects (<85Kb), but
with Large Objects things might go wrong because this 1.6Gb space is
fragmented. For instance while it might be possible to create 16 instances
of a say an array of 100MB , it's just impossible to create 2 objects of
800MB or 3 objects of 500MB. Note that here I'm talking about a simple pure
managed application, things might get worse when you have to deal with
unmanaged code in your application (COM or PInvoke interop). Unmanaged code
can also allocate memory from the free (process) heap space and this
allocation can further fragment the heap such that there might be less space
left in a contigious block to store large objects.

Conclusion, while it's hard to calculate the exact amount of memory consumed
by a process, it's nearly impossible to say how much memory there is left in
a contiguous block, and that's the point that troubles a lot of people, just
because they don't know/care about the hidden cost associated with some of
the container classes in a highly virtualized frameworks like (but not
limited to) .NET and Java, they just create Dataset with tons tables and
rows comming from SQL like stores and they are supprised that they run out
of memory (not to mention the disastrous performance because of paging).
So while might be important to keep an eye at your memory consumption, the
question to know exactly how much there is free might be moot in the
presence of large objects. So I would suggest you apply a good design that
is based mainly on small classes and watch out for things like ArrayLists
and (worse) highly sophisticated things like DataSets (they have a large
hidden cost!) that get larger than a few megabyte. Watch out for Interop
scenarios, be careful with third party ActiveX controls or .NET controls ,
most of them are simple AX wrappers and some are real crap some are simply
not usable in your scenario (STA objects in a windows service or webservice
for instance). Be careful using PInvoke interop to call third party (free
stuff or public domain), some libraries assume they can allocate all memory
they want not to mention their weird base addresses (the address where they
load in VAS) so they further fragment the available memory.



Willy.
 
S

S. Senthil Kumar

So private bytes plus the address space required for mapping exe, dll
and memory mapped files will be equal to the virtual bytes counter?

Regards
Senthil
 
W

Willy Denoyette [MVP]

S. Senthil Kumar said:
So private bytes plus the address space required for mapping exe, dll
and memory mapped files will be equal to the virtual bytes counter?

Regards
Senthil

No, the "Virtual bytes" are the VAS (Virtual Address Space) pages actually
allocated to the process, these consist of what's more or less mentioned
above plus the Virtual allocated memory that's been reserved but not yet
committed.
For instance when the CLR initializes, it allocates 2 segments of 32MB each
from the VAS for the GC heap, so you will see the "Virtual bytes" value grow
by 64 MB when this is done.
At the start of the EE only 2 pages are committed from this 64MB so the
"Private bytes" don't increase at this point, however, when the program
starts executing managed code and objects are getting loaded in the GC heap,
the number of committed pages start to increase, and obviously you'll see
the "Private bytes" (and Page file bytes) increase accordingly.
The number of committed (GC heap) bytes from this "initial heap" never
decreases, additional segments allocated during runtime might get returned
to the OS when they are no longer needed by the CLR, so it's possible to see
the Private bytes decrease, but only if they come from additional segments
that are getting retuned to the OS.

Willy.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top