Memory information provided in Task Manager

  • Thread starter Thread starter Klaus Bonadt
  • Start date Start date
K

Klaus Bonadt

What does it mean "Available" in group "Physical Memory (K)" on tab
"Performance"?
It is not what is still available for other applications, i.e.
"PhysicalMemory.Total - CommitCharge.Total". Even if I start a program,
which allocates the whole amount of physical memory, I still have 1.5 GB
"available". Available for what?

Regards,
Klaus
 
Klaus said:
What does it mean "Available" in group "Physical Memory (K)" on tab
"Performance"?
It is not what is still available for other applications, i.e.
"PhysicalMemory.Total - CommitCharge.Total". Even if I start a
program, which allocates the whole amount of physical memory, I still
have 1.5 GB "available". Available for what?
Click to expand...

Use.
Windows is managing your memory by using virtual and physical - almost no
program will use all of your physical memeory, because there are parts of it
almost immediately moved to virtual spaces - because you aren't using them.
 
Shenan Stanley said:
Use.
Windows is managing your memory by using virtual and physical - almost no
program will use all of your physical memeory, because there are parts of it
almost immediately moved to virtual spaces - because you aren't using
Click to expand...
them.

Please explain how this fits into the following scenario:
My System: XP Professional, SP1. Physical Memory: 2GB, page file size from
1000MB until 1000MB, logged on as administrator
The following information is provided by System Information (available in
Start.Programs.Accessories.SystemTools) and Task Manager (Tab Performance):

i
Environment: System Information and Task Manager started, nothing else

Information System Information:
Total Physical Memory: 2048 MB
Available Physical Memory: 1.74 GB
Total Virtual Memory: 4.83 GB ???
Available Virtual Memory: 4.47 GB ???
Page File Space: 2.83 GB ???

Information Task Manager:
Physical Memory (K)
Physical Memory: 2096624 K
Available: 1824200 K
System Cache: 124400 K

Commit Charge (K):
Total: 109200 K
Limit: 2967712 K
Peak: 126552 K


ii
Environment:
Additionally a self-written program is started which allocates altogether
32344 x 64k = 2070016 KBytes (there is no 64k Block available anymore).

Information System Information:
Total Physical Memory: 2048 MB
Available Physical Memory: 1.49 GB ???
Total Virtual Memory: 4.83 GB ???
Available Virtual Memory: 2.23 GB ???
Page File Space: 2.83 GB ???

Information Task Manager:
Physical Memory
Physical Memory: 2096624 K
Available: 1561352 K ???
System Cache: 161400 K

Commit Charge:
Total: 2193216 K
Limit: 2967712 K
Peak: 2194508 K

I exptected that "Available physical memory" is free or available for other
processes to get allocated. But it seems that this information is available
only by calculating "PhysicalMemory.Total - CommitCharge.Total".
Could you explain the lines with three question marks?

Best regards,
Klaus
 
Hi,

A better way to look at how the system is handling memory and other
performance issues is to use Performance Monitor (perfmon.exe) to see
various memory, process, and system counters.
When an application allocates memory, it doesn't immediately take up actual
physical memory. Allocations are backed by the page file, and in most cases
very little physical memory is allocated by the system until the application
actually begins to use it. This prevents the very common scenario where an
application launches and immediately allocates X, but all they use is X-Y,
or they'll need X in the future but only Y right now. If Windows
immediately reserved physical memory for the entire allocation, the amount
of RAM not being used in that allocation would be wasted, and unavailable
for other uses (say another application is launched, or other applications
already running need to allocate additional RAM for immediate use). Since
the application did allocate X, however, the commit charge will increase by
(roughly) X, and that decreases the amount of virtual memory available until
the commit limit is reached, resulting in Windows expanding the pagefile, or
starting to throw out of virtual memory errors if it cannot expand the
pagefile.

I hope this clears up some of your questions.
 
When an application allocates memory, it doesn't immediately take up
actual
physical memory. Allocations are backed by the page file, and in most cases
very little physical memory is allocated by the system until the application
actually begins to use it. This prevents the very common scenario where an
application launches and immediately allocates X, but all they use is X-Y,
or they'll need X in the future but only Y right now. If Windows
immediately reserved physical memory for the entire allocation, the amount
of RAM not being used in that allocation would be wasted, and unavailable
for other uses (say another application is launched, or other applications
already running need to allocate additional RAM for immediate use). Since
the application did allocate X, however, the commit charge will increase by
(roughly) X, and that decreases the amount of virtual memory available until
the commit limit is reached, resulting in Windows expanding the pagefile, or
starting to throw out of virtual memory errors if it cannot expand the
pagefile.
Click to expand...

David, as I have written I have a pagefile with constant size of
approximately 1GB, thus XP can't expand this (at least this is my
understanding when I define initial size: 1000MB and maximum size: 1000MB.
Together with 2GB physical RAM I have in total 3GB memory.
My self-written program allocated blocks of 64k until the operating system
can't deliver a 64k block anymore. In total I was able to allocate 32344
blocks, which is 32344 x 64k = 2070016 KBytes. This is almost 2GB RAM. There
is not more than 3-2=1 GB memory left. However, Task Manager tells there is
still 1561352 K Bytes free.

Furthermore, I still do not understand why System Information tells more
than 4GB virtual memory?

I do understand from you, that XP try to use the virtual memory from the
very beginning in order to satisfy all memory claims, but I still do not
understand the actual values presented in Task Manager or System
Information.

I took a look to the variables "Commit Limit", "Comitted Bytes" and
"Available MBytes" in perfmon before and after I started my test program.
"Commit Limit" presents constant 3GB, which is exactly what I expect.
"Comitted Bytes" is the same as "Total" in group "Commit Charge" of Task
Manager. The value is exactly what I expect: The amount of allocated memory.
I proved this every 10000 allocated blocks.
"Available MBytes" is also the same as "Available" in group "Physical
Memory" of Task Manager. And I do not understand that values. After
allocating 2GB RAM, it still tells 1.5 GB RAM is available?

Best regards,
Klaus
 
Together with 2GB physical RAM I have in total 3GB memory.
My self-written program allocated blocks of 64k until the operating system
can't deliver a 64k block anymore. In total I was able to allocate 32344
blocks, which is 32344 x 64k = 2070016 KBytes. This is almost 2GB RAM. There
is not more than 3-2=1 GB memory left. However, Task Manager tells there is
still 1561352 K Bytes free.
Click to expand...

I'm sorry, I guess I misunderstood your question. There's a two-part answer
here.
Each process (on a 32-bit system) can access 4 GB of its own virtual address
space. Of this space, by default, 2 GB is available to the process itself,
and 2 GB is reserved for the system (mapping system dlls into the address
space among other things). The most you'll be able to access by default is
2 GB, hence why you couldn't allocate past that.
Note that in order for applications to take advantage of the extra user-mode
address space, they need to be built with a specific linker option.
That explains why you're only able to allocate 2 GB.

The Task Manager available question, is slightly different. It has to do
with how the Windows memory manager handles things internally, and the
following KB article describes that. The main point I was trying to make
earlier is that there's no guarantee that when an application calls to
allocate virtual memory, that allocation will actually be in physical RAM.
You're correct in that the commit limit minus the "Available" number in Task
Manager is not "How much memory is free". In addition to the below KB,
you can click the "Explain" button on the different counters available in
Performance Monitor for a brief description of what they mean.

312628 - Description of What the Available Bytes in Task Manager Represents
http://support.microsoft.com/default.aspx?scid=kb;en-us;312628&Product=winxp

I'm not exactly sure why System Information is reporting the information it
is, it may be getting incorrect information from somewhere - the best place
for realtime data of that sort is generally Performance Monitor.

I hope this clears up your questions!
 
Thanks, David.
address space, they need to be built with a specific linker option.
That explains why you're only able to allocate 2 GB.
Click to expand...

Do you know the option for VC++ version 6 and Visual Studio .Net?
...
I hope this clears up your questions!
Click to expand...

To be honest, what I have learned from the article is just that "Available
memory" is something internal, which might be roughly translated to "file
cache".
I have further learned to ignore the information provided in "system
information". However, the important information for me is
1.
"Commit Limit" in perfmon or "Limit" in group "Commit Charge" of Task
Manager.
2.
"Comitted Bytes" in perfmon or "Total" in group "Commit Charge" of Task
Manager.

Performing the calculation "Limit" - "Total" I have "still available memory
for applications", which is the most important point for me.

Best regards,
Klaus
 
Back
Top