How are the numbers in the Windows XP Virtual Memory info to be interpreted? I am actually just interested in:

1) What is the total size that is free as in "untouched" physical RAM, so that the system is not going to swap at all

To experiment, I set up a Virtual Machine using Windows 7, running Windows XP, with memory of 768MB. To make it simpler, the virtual memory is set to "0" (Do not use any pagefile). The following is the system info and charts:

alt text

So is the 145MB (approx) the "untouched" physical RAM? There were actually a case that XP popped up a small balloon at the task bar saying "Not enough virtual memory" when this number was about 120MB. I believe the small app I am running should only be requesting a few MB only. So 120MB should be well enough. So I wonder why that is.

What about the other numbers?

145432 (listing here to make a complete list)



582MB (the bar for PF Usage)

and the horizontal line for "Page File Usage History"

Now, since the virtual memory is set to "Do Not Use Any Page File", so shouldn't the PF Usage be 0? And so the horizontal line for "Page File Usage History" should stay at 0 always? thanks.

Update: and let's say, if the pagefile is made to a fixed 256MB file size, and the info is also shown as the picture above, then how are those 10 numbers to be interpreted?

And in this case, if the "Available" went down slowly and now is still 120MB, then it should mean that the pagefile hasn't been used at all?


How do I interpret the Performance tab of Task Manager?

Firstly, let's talk about the numbers. They are in 4 groups, labelled Totals, Commit Charge, Physical Memory, and Kernel Memory.

Totals: tells you how many handles, processes, and threads there are allocated in the OS. The numbers are simple counters, but the words are quite tricky to explain, because they're basic programming concepts, and basic concepts are always tricky (try explaining the verb 'to be' some time).

Handles: the kernel supplies programs with 'objects' such as files, shared-memory sections, registry keys, and so on. A program uniformly manipulates an object by means of a handle, which is a temporary connection to the object. A handle is not the object; for example, if a file is opened for 17 different uses at the same time, it will have 17 different handles connected to it.

Processes: a process is an instance of a program in execution. If you're running Explorer 3 times, then there will be 3 processes running. See the difference? The program is the thing that persists - the program you had yesterday is the program you have today (unless you did something!). Processes come and go.

Threads: what actually runs in a process. Each process is made up of one or more threads, at the decision of the programmer. The threads execute in a more-or-less independent manner. If you had enough processors, they could all really execute at the same instant. Otherwise, they only appear to be all running at the same time.

None of these numbers have 'proper' values. Mostly, if they start increasing without limit, then it's time to suspect that something is going wrong. A program can cause a 'handle leak' by failing to close files, for example (though if you kill the process, all its handles will then be closed by the OS; this isn't DOS).

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.

The Total commit charge is the current in-use value; the Limit is the sum of the pagefile sizes and the physical memory that's available in principle for programs (i.e., not counting all the permanently-resident parts).

The Peak is simply the highest value recorded since boot.

Physical memory: this is easy. The total is the amount of memory that the OS detected, and the available amount is pretty much what you'd expect. The so-called system cache size is actually the size of the system 'working set' (i.e., the amount of physical memory used by the System process, pid 4, which is a process wired in to the kernel and which executes threads on behalf of the kernel and device drivers). The system file cache temporarily holds contents of files, to speed system performance, and is probably the largest consumer of memory in the System process, though, so it's a reasonable approximation.

Kernel memory: tells you how much memory is in use by the kernel and device drivers. I believe (but I could be wrong here) the numbers here are virtual memory counts. For non-paged memory, there's no difference: the virtual memory is always resident in physical memory. For paged memory, the size is virtual; the physical memory occupancy could be less.

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.

What do you expect from a program calling itself the "Task Manager" anyway? There is nothing called a "task" in the operating system kernel - the OS has "processes" and "threads". DOS had "tasks". The Intel hardware has "task" structures, but the OS doesn't use them because it's faster for it to do it itself. (Recently, a user mode program called the "task scheduler" has appeared, but the kernel knows nothing of those tasks either, and besides, that's a completely different use of "task").

The CPU Usage and CPU Usage History displays do in fact measure CPU use! That is to say, they count all CPU use except that which is used in the system idle loop at non-interrupt level. It's thus a pretty good picture of how busy your system really is.

On multiprocessor systems, I think the total is given in terms of the power of one CPU (they're always identical CPUs). Thus a two-CPU system has "200%" available to it. You can if you like show one graph per CPU. If someone would care to send me a two-CPU system, I will verify these claims.

The usual green line gives the total CPU use. You can optionally add a red line showing the time spent in kernel mode; this is sometimes handy for problem isolation, or perhaps it just looks nicer. Use Show Kernel Times in the View menu.

The bottom status line repeats CPU use, commit charge, and process totals.



You will get good notes and description at Mark Russinovich's blog post
Pushing the Limits of Windows: Handles and the 4 other older posts linked from there.

  1. Physical Memory
  2. Virtual Memory
  3. Paged and Nonpaged Pool
  4. Processes and Threads

Mark wrote the excellent SysInternals utilities and is now working with Microsoft.


A short answer: after a full day's (or week's) work with real (or even larger than average) workloads, look at the Peak Commit Charge. That's "the most 'memory' used at a given moment". Round up to the next half-GB and that's how much RAM you should have. If it's more than 3GB, consider upgrading to a 64-bit OS.

Then if you want, have 1GB or so of swap for "graceful degradation" (why is everything running so slow and the hard disk light blinking so much?). All the recommendations for 1.5X or 2X RAM is (mostly) nonsense.

The screenshot is suspicious because inside the box it says the "Total 25"; while in the status bar in the bottom right, it says "596564K", which matches the "582MB" in the graph.

  • the screenshot is genuine. it is by running Win 7's Virtual machine using the vhd image, if you google vhd you will find the Microsoft's website to download those. I am using the one for IE 8 and XP SP3. – nopole Jan 19 '10 at 6:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.