Task manager showing incorrect value of available memory on Server 2003

On a Server 2003 x86 with 4GB, task manager showing a value of 700MB while the processes tab shows a count of 50 processes that the total WS used is about 1GB.

The available memory should be about 3GB. Why is it showing a low value while no process consum much memory?

Same values are showing in CMD tasklist and perfmon.
or1969Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

 
BeartlaoiCommented:
1. You dont get the entire 4GB on an x86 system unless you use /PAE
2. The Kernel can use up to 2GB depending on various factors, you can see the pool useages on the Task Manager performance tab but not the space used by driver images or PTEs or how much is actually reserved to the pools.  Use ProcExp - View system info after configuring symbols.
3. The system cache uses some, you can see this on the Task Manager performance tab
4. Make sure you are viewing all processes
5. Virtual address space usage (loaded dlls, exes and such) take up RAM too.
6. Pagefile usage can push some of these numbers out of whack

Bottom line is that Windows memory management is complicated, read Mark Russinovich's publications to get all the detail.
0
 
marsiliesCommented:
In Task Manager, on the performance tab, look at the Total Physical Memory. This is the total amount of memory Server 2003 x86 can access, which is going to be less than 4GB. How much less is dependent on your hardware.
http://support.microsoft.com/kb/283037
http://hardforum.com/showthread.php?t=1035670
http://www.sevenforums.com/general-discussion/53824-win-7-only-3-25-gb-ram.html#post493775


You shouldn't try to add up the "Mem usage" of all the processes in the processes tab. That only lists the memory in use by the processes, not the memory committed to the process. Instead, you should look at the Commit Charge in the performance tab.

http://www.dslreports.com/faq/7512
Now, the graphs and meters. Despite their headings, the PF Usage and Page File Usage History displays don't measure Page File Usage. They measure the total commit charge. The total commit count is sort of related to page file use; it's how much page file you'd use if everything that could possibly get written to the pages file, was in fact written to the page file. On Windows 2000, the same displays are called Mem Usage, leading people to think they measured physical memory use. That wasn't right either.

Commit charge: this measures the amount of 'committed virtual memory' (see the VM FAQ for background) in the system. This is all memory requested by processes that is not backed by some named file (for example, the program instructions are stored in the program.exe file and thus are not counted in the commit charge). One way to look at this is that the system has a certain budget for virtual memory, and each program request is charged against that budget.


Note that the commit charge is the total amount of memory requested by all processes, which is often going to be more than the total amount of memory currently in use by all processes.
0
 
or1969Author Commented:
I appreciate your answer's but my problem is not the understanding of task manager parameters and usage but a specific problem of missing information.

/PAE is already set in boot.ini. also, the PF is set to 6GB, and the limit commit charge shows 12GB and that is the correct result. (actually, the limit commit charge is basically the total VM. the sum of both WS and PF).

the mem usage in processes is the total WS used by the process including the shared WS. So usually in cases where there are many processes (like in terminal server) using a lot of WS, if you'll sum the WS of all processes you might get more then 100% of the total installed RAM. and that is normal od OK as you sum also the shared WS.

My problem in this case is that there are only 50 processes and ther sum is about 1GB so the actual RAM usage is even less. The available memory in this case should have bean aprox. 2.5-3GB BUT whay it shows on that specific server is about 0.7GB.

I was thinking of using RAMMAP to get information of what exactly in the system is consuming RAM including files that might be loaded to the memory and not shwon in the task manager but Sysinternals new RAMMAP version does not support anymore server 2003. only 2008 and above. so I have no way of monitoring the RAM accurately.
0
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

 
marsiliesCommented:
RAMMAp was released in 2010, so it never supported server 2003:
http://web.archive.org/web/20100522111342/http://technet.microsoft.com/en-us/sysinternals/ff700229.aspx

What's the Commit Charge Total? This is what's being used currently by the system.

Your Commit Charge Limit sounds off. This should be roughly the size of the page file + the Physical Memory (RAM), so 6GB + 4GB = 10GB.

Do you mean WS to mean Working Set? Where are you getting the Working Set from?
0
 
marsiliesCommented:
From
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
the commit limit is the sum of physical memory and the sizes of the paging files. In reality, not quite all of physical memory counts toward the commit limit since the operating system reserves part of physical memory for its own use.
0
 
or1969Author Commented:
In the attached images you can see what I mean
Both snaps was taken at the same time.

The total available memory value does not make any sense in regard to the number of running processes. btw, when opening more processes and closing them, the available memory stay low even after colosing the applications.

Performance Tab
Processes Tab
0
 
marsiliesCommented:
I see that you have Physical Memory of 4193492KB, and a Commit Charge of 4077448KB

4193492 - 4077448 = 116044KB (if all used memory was physical memory).

Since you have 795708KB left over, that means some of the comitted memory is paged out. So you actually have more free RAM that you could. Since you're already comitting more memory than is stored in physical memory, killing a few processes isn't going to free up physical memory, as Windows will just page back in memory that had been paged out to the page file.


Memory Usage for each process on the Processor tab doesn't actually grab all the memory used on the OS, so just adding that up isn't going to get you the total commit charge.

You may want to add the "VM Size" column to the Processes tab to get an idea of what other memory could be in play.
http://stackoverflow.com/questions/252597/mem-usage-higher-than-vm-size-in-winxp-task-manager
0
 
or1969Author Commented:
Can you send a snapshot of your machine (or any other machine for that matter) that will show the same behavior similar to the one I presented here?
0
 
marsiliesCommented:
Here's one screenshot:

Process Tab
As you can see, adding up the mem usage doesn't equal the commit charge.
0
 
or1969Author Commented:
can you send a snap of the 'Performance' tab?
0
 
marsiliesCommented:
Performance Tab
0
 
or1969Author Commented:
According the these captures, if you'll sum the WS (mem usage) of the processes you'll get about 240MB. With the value of 248MB of available memory, this is the correct result.

Now, when you open an application that consume memory or open same application several times the available memory will decrease.

When you'll close the application you've just opened, the memory used by the closed application will be released back to the system and the available memory will about 240-250MB.

Can you confirm that this happens on you system?
0
 
marsiliesCommented:
The pics weren't taken at the same time. These two were taking much closer together.


Process Tab
Performance Tab
Adding up the processes Mem Usage:
32668 + 32252 + 25676 + 24024 + 20152 + 12556 + 7388 + 5744 + 5308 + 4768 + 4120 + 3808 + 3440 + 3108 + 2968 + 2572 + 2540 + 2208 + 1932 + 1904 + 1756 + 1624 + 1520 + 1420 + 1168 + 852 + 128 + 88 + 56 + 32 + 16 = 207796 KB

According to the Perfomance tab,
Physical Memory Total 519724 KB
Physical Memory Available 250528 KB
Commit Charge 299196 KB

519724 - 207796 = 311928 KB, which doesn't match up with the actual available, meaning there's 61400 KB of Physical memory usage not accounted for.

On the other hand,
519724 - 299196 = 220528 KB, which means I have more physical memory available than if the entire commit charge total was stored in physical memory.


Also, look at the VM Size on the process tab, especially for the process fmaonsite.exe. The VM Size is nearly twice as big as Mem Usage, so Mem Usage doesn't actually measure all the memory in use by a process.
0
 
or1969Author Commented:
The values in the images are making sense.
Now, if you'll open an application, for example Acrobat Reader and open a document, and then close it, what will the performance tabs show after the close of Acrobat Reader?

My guess it should be about the same as it was before opening the Acrobat Reader. Am I correct?
0
 
marsiliesCommented:
I don't have Adobe Reader installed on this system, and anyway it would be inexact, especially since my system isn't quite as taxed as yours in terms of memory usage.

So, instead, I used a memory allocation tool, MemAlloc:
http://www.softpedia.com/get/Tweak/Memory-Tweak/MemAlloc.shtml

In this first image, I allocated 256MB in one process in order to get the commit charge total near the Physical Memory total. In fact, the commited memory total is over the physical memory total, requiring that some of the memory is paged out.
256MB AllocatedThe physical available memory is 76,952 KB, so adding 250,000 KB of memory usage to my system didn't wipe out the RAM.

Next, I allocated another 256MB in a separate process:
Another 256MB allocated, 512MB totalThis brought the physical available memory to 19,988 KB, so in this case adding another 250,000 KB of memory usage only reduced the available physical memory by 47,964 KB.

Then, I deallocated the 256MB from the second process:
256 MB deallocated, 256MB Total allocated.This freed up a significant chunk of physical memory, bringing physical available memory to 166,848 KB, more than before I had allocated that second amount of 256MB. Still, it only freed up 146,860 KB, so unallocating 256MB doesn't necessarily free up an equivalent amount of RAM.

You can see by the jumps in the Total Commit Charge that the memory was allocatted, it was just allocated to a mix of RAM and Page File.

On a less taxed system, sure, opening a program may allocate nearly all of its memory to RAM, and free it all up when that program is closed. However, your system is taxed, with a commit charge total very near to the amount of RAM it has, so Windows is going to be doing a lot of paging on it, which means that new programs opened may use a greater mix of RAM and page file, and thus closing it isn't going to free up an equivalent amount of RAM.
0
 
or1969Author Commented:
Exactly! and this is how the OS should work.

Now, my problem on the machine I'm referring to is that NON of the memory allocated by a closed application is returned to the system. NOTHING IS RETURNED!

The snapshots I've attached are showing the system memory state AFTER closing applications. And every time I'll open an application and close it, it will return NOTHING to the system eventually no available memory is left. (about 50-80MB available memory is left while the PF usage is about 2-3%).

This is an old machine hat started showing this problem about a week ago.
It does not happen on any other machine we have.
0
 
marsiliesCommented:
Does the total commit charge change? Can you show screenshots of both before, after opening, and after closing a program?
0

Experts Exchange Solution brought to you by ConnectWise

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
 
or1969Author Commented:
Yes, but only on Wednesday. I'll upload them after I'll have them.
0
 
or1969Author Commented:
Sorry for the late delay but as we didn't find any solution we've transferred the entire server operation to Server 2008 R2 VM. The problem did not show again.

I appreciate your efforts to assist.

Thanks.
0
 
or1969Author Commented:
solution not provided. The points awarded for the effort.
0
 
marsiliesCommented:
It's hard to provide a solution when you stopped providing requested information. Thank you for providing points for my attempt though.

Does the new VM have more than 4GB RAM allocated to it?
0
 
or1969Author Commented:
The VM have 4GB. Working just fine.

Thanks for the support.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.