Checking how much memory is being used on a server


Urgent question but very easy :)

I have a Windows 2003 SP2 server and need to find out how much memory is actually being used.

If I go to Task Manager, I can see:

Physical Memory:
Total: x
Available: y
System Cache: z

Would I be correct in thinking that

x = total memory on system
y = memory available
x-y = memory being used

There is also a value for PF Usage which reflects how much of the PF is being used I guess.

Is there a 'safe' threshold for this?
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.

You can add some counters to monitor not only memory but other performance resources:
"...Because counters continually gather data on system performance, when you add counters, you are adding their displays in system monitor. Click Start, point to Programs, point to Administrative Tools and click Performance.
Right click the System Monitor details pane and then click Add Counters.
Click all counters or select counters from the list to choose individual counters.
If an object has instances, click all instances or select instances from the list to choose individual instances.
Click Add, and then click to Close the add counters dialog box.

After you add counters, you can view the data of your counters in real time. Display of data can be done in three ways. Histogram: Display data in a Bar chart.
Report: Display Numerical data in columns.
Chart: Display data in Line graph
Read more about it at :
Bits ...

Experts Exchange Solution brought to you by

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
As for the pagefile question it is standard practice to use 1.5 the amount of memory for the pagefile.
Bits ...
I never answered your question... Yes x-y= Used Memory.
This is a very brief description:

Physical Memory

Total:  Memory that is available to Windows. This may be less than that installed.

Available: Memory that can be assigned to a process without disk access. This does not mean that it is free. Most of "Available" memory is actually in use.

System Cache:  This is not just the file cache. This includes the file cache, paged pool, and system code. It also includes the standby list which is part of "Available" memory.

"PF Usage" is NOT actual pagefile usage. It is actually the same as the "Commit Charge". This is more like potential pagefile usage. If everything that was in memory that could be paged out actually was, this is the space that would be required. Actual pagefile usage will usually be much less.

To be safe the Commit Charge should never get close to the Commit Limit. This is particularly important if you have a fixed pagefile (not recommended) or no pagefile (even worse).

Interpreting Task Manager isn't nearly as simple as it may seem. Some labels are inconsistent with general industry terminology and other Microsoft utilities. Some aren't even consistent within Task Manager.
LMiller7/kam_uk... Yes. I totally agree.
However kam_uk stated his question was urgent and there really is no simple precise method to give and urgent fast answer and any answer you give is really at a point in time since it is constantly changing.
Otherwise, you need to start adding counters to performance monitor and start splitting hairs ...this is virtual, this is physical.... and so forth....adding up with a calculator a number that is constantly changing... X-Y= Approximated Used Memory works for a quick glance....
Fortunately Windows 7 gives you a counter where you can verify that x-y= approximately used. (see screenshot below).
The second screenshot gives you a very basic explanation of what each of the counters mean.
Now... if you really need to go in depth we would have had to go into details explaining all the below and it would never end up being a "brief description":
Memory Performance Counters
The following counters all have to do with the management of memory issues. In addition, there will counters that assist in the determination of whether the problem you are having is really a memory issue.
Memory : Page Faults/sec. This counter gives a general idea of how many times information being requested is not where the application (and VMM) expects it to be. The information must either be retrieved from another location in memory or from the pagefile. Recall that while a sustained value may indicate trouble here, you should be more concerned with hard page faults that represent actual reads or writes to the disk. Remember that the disk access is much slower than RAM.

Memory : Pages Input/sec. Use this counter in comparison with the Page Faults/sec counter to determine the percentage of the page faults that are hard page faults.
Thus, Pages Input/sec / Page Faults/sec = % Hard Page Faults. Sustained values surpassing 40% are generally indicative of memory shortages of some kind. While you might know at this point that there is memory shortage of some kind on the system, this is not necessarily an indication that the system is in need of an immediate memory upgrade.

Memory : Pages Output/sec. As memory becomes more in demand, you can expect to see that the amount of information being removed from memory is increasing. This may even begin to occur prior to the hard page faults becoming a problem. As memory begins to run short, the system will attempt to first start reducing the applications to their minimum working set. This means moving more information out to the pagefiles and disk. Thus, if your system is on the verge of being truly strained for memory you may begin to see this value climb. Often the first pages to be removed from memory are data pages. The code pages experience more repetitive reuse.

Memory : Pages/sec. This value is often confused with Page Faults/sec. The Pages/sec counter is a combination of Pages Input/sec and Pages Output/sec counters. Recall that Page Faults/sec is a combination of hard page faults and soft page faults. This counter, however, is a general indicator of how often the system is using the hard drive to store or retrieve memory associated data.

Memory : Page Reads/sec. This counter is probably the best indicator of a memory shortage because it indicates how often the system is reading from disk because of hard page faults. The system is always using the pagefile even if there is enough RAM to support all of the applications. Thus, some number of page reads will always be encountered. However, a sustained value over 5 Page Reads/sec is often a strong indicator of a memory shortage. You must be careful about viewing these counters to understand what they are telling you. This counter again indicates the number of reads from the disk that were done to satisfy page faults. The amount of pages read each time the system went to the disk may indeed vary. This will be a function of the application and the proximity of the data on the hard drive. Irrelevant of these facts, a sustained value of over 5 is still a strong indicator of a memory problem. Remember the importance of "sustained." System operations often fluctuate, sometimes widely. So, just because the system has a Page Reads/sec of 24 for a couple of seconds does not mean you have a memory shortage.

Memory : Page Writes/sec. Much like the Page Reads/sec, this counter indicates how many times the disk was written to in an effort to clear unused items out of memory. Again, the numbers of pages per read may change. Increasing values in this counter often indicate a building tension in the battle for memory resources.

Memory : Available Memory. This counter indicates the amount of memory that is left after nonpaged pool allocations, paged pool allocations, process' working sets, and the file system cache have all taken their piece. In general, NT attempts to keep this value around 4 MB. Should it drop below this for a sustained period, on the order of minutes at a time, there may be a memory shortage. Of course, you must always keep an eye out for those times when you are simply attempting to perform memory intensive tasks or large file transfers.

Memory : Nonpageable memory pool bytes. This counter provides an indication of how NT has divided up the physical memory resource. An uncontrolled increase in this value would be indicative of a memory leak in a Kernel level service or driver.

Memory : Pageable memory pool bytes. An uncontrolled increase in this counter, with the corresponding decrease in the available memory, would be indicative of a process taking more memory than it should and not giving it back.

Memory : Committed Bytes. This counter indicates the total amount of memory that has been committed for the exclusive use of any of the services or processes on Windows NT. Should this value approach the committed limit, you will be facing a memory shortage of unknown cause, but of certain severe consequence.

Process : Page Faults/sec. This is an indication of the number of page faults that occurred due to requests from this particular process. Excessive page faults from a particular process are an indication usually of bad coding practices. Either the functions and DLLs are not organized correctly, or the data set that the application is using is being called in a less than efficient manner.

Process : Pool Paged Bytes. This is the amount of memory that the process is using in the pageable memory region. This information can be paged out from physical RAM to the pagefile on the hard drive.

Process : Pool NonPaged Bytes. This is the amount of memory that the process is using that cannot be moved out to the pagefile and thus will remain in physical RAM. Most processes do not use this, however, some real-time applications may find it necessary to keep some DLLs and functions readily available in order to function at the real-time mode.

Process : Working Set. This is the current size of the memory area that the process is utilizing for code, threads, and data. The size of the working set will grow and shrink as the VMM can permit. When memory is becoming scarce the working sets of the applications will be trimmed. When memory is plentiful the working sets are allowed to grow. Larger working sets mean more code and data in memory making the overall performance of the applications increase. However, a large working set that does not shrink appropriately is usually an indication of a memory leak.

Bits ...

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.