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.
Source
Your problem is with Virtual Memory.
Applications ask windows to commit a certain amount of virtual memory to it. This does not mean the application will use all the memory committed, only that Windows promises to make it available if need be. When you look at memory usage only memory actually being used is show, not how much virtual memory has been committed to the process.
The commit limit of windows is RAM plus pagefile, because windows won't make a commitment it can't keep. So you have a commit limit of 12.4GB. Since committed virtual memory that isn't actually used does not occupy any physical space anywhere, applications aren't afraid to ask for large commitments. So it is quite common to have the virtual memory usage a lot larger than the actual memory usage.
As you I've shrunk my pagefile to make more room on my SSD. I set the initial size to 512, but the maximum size to 8GB, just so that windows can grow it if need be. Currently it is 1.4GB so the initial 8.5GB of virtual memory I had hasn't been quite enough.
You can also go hunting down the application that is using all the virtual memory. In task manager set it to show you the commit size of the running processes.
As an example: Catalyst Control Center has a Private Working Set (memory usage) on my machine of 3MB but a Commit Size of 112MB.
Best Answer
First, you have a fundamental confusion about what virtual memory is. Virtual memory is something that looks like memory. It is not the same thing as a paging or swap file. (People got this confused because adjusting the paging file is the only virtual memory setting available in the standard Windows GUI, so people started thinking they were the same thing. They are not.)
Second, "paged memory" is memory that is part of the paged pool. You want as much of your memory to be paged as possible because paged memory can be managed flexibly. Only very few things need to be non-paged.
The non-paged pool contains only memory that cannot be paged because it must remain locked in physical memory. Only data that might be needed in a context in which paging is not possible counts towards the non-paged pool. (For example, the buffers used to communicate with the hard drive controller obviously cannot be paged!) Less confusing terms would be "pageable" and "non-pageable".
Second: The vast majority of your memory is used. The only memory that's not being used is memory that's free. The usage percentage is the percentage of memory used for essential purposes. It's really only helpful to help you measure whether you might need more memory or whether memory demand is unusual. It's saying you don't need more memory and Windows doesn't need most of the memory you have, but it's using it to improve performance.
That's how it should be.
There are only two rational reasons to move your page file from an SSD to a hard drive. One would be if you need the space on your SSD. The other would be if you have an older SSD with very limited write lifetime. There's really no reason not to keep a page file on a modern SSD if you have the space. That way, if you do encounter unusually high memory demand, performance won't drop as much as it would if it had to write to a hard drive.