How do I tell if my Windows server is swapping?

I'm using Process Explorer to monitor my windows server while it reconstructs some data. It's primarily a CPU intensive process, but I want to make sure it's not swapping. How can I tell if it is using Process Explorer? My initial guess is in the System Information window, it's Paging File Write Delta. Yes? No? I'm an idiot?

*Screenshot is not of the server... just an example.

alt text http://www.malwareinfo.org/bootcamp/img/ProcessExplorer2.jpg

Solution 1:

"Pages Input / sec is the counter to watch, but you shouldn't worry about it "swapping" as windows does not use the page file like *nixes do.

First you need to understand that windows pages in not out. I'm going to quote the relevent portion of Eric Lipperts blog post (lightly edited) since I can't say it any better myself:

"RAM can be seen as merely a performance optimization. Accessing data in RAM, where the information is stored in electric fields that propagate at close to the speed of light is much faster than accessing data on disk, where information is stored in enormous, heavy ferrous metal molecules

The operating system keeps track of what pages of storage from which processes are being accessed most frequently, and makes a copy of them in RAM, to get the speed increase. When a process accesses a pointer corresponding to a page that is not currently cached in RAM, the operating system does a “page fault”, goes out to the disk, and makes a copy of the page from disk to RAM, making the reasonable assumption that it’s about to be accessed again some time soon.

The operating system is also very smart about sharing read-only resources. If two processes both load the same page of code from the same DLL, then the operating system can share the RAM cache between the two processes. Since the code is presumably not going to be changed by either process, it's perfectly sensible to save the duplicate page of RAM by sharing it.

But even with clever sharing, eventually this caching system is going to run out of RAM. When that happens, the operating system makes a guess about which pages are least likely to be accessed again soon, writes them out to disk if they’ve changed, and frees up that RAM to read in something that is more likely to be accessed again soon.

When the operating system guesses incorrectly, or, more likely, when there simply is not enough RAM to store all the frequently-accessed pages in all the running processes, then the machine starts “thrashing”. The operating system spends all of its time writing and reading the expensive disk storage, the disk runs constantly, and you don’t get any work done.

This also means that "running out of RAM" seldom results in an “out of memory” error. Instead of an error, it results in bad performance because the full cost of the fact that storage is actually on disk suddenly becomes relevant.

Another way of looking at this is that the total amount of virtual memory your program consumes is really not hugely relevant to its performance. What is relevant is not the total amount of virtual memory consumed, but rather, (1) how much of that memory is not shared with other processes, (2) how big the "working set" of commonly-used pages is, and (3) whether the working sets of all active processes are larger than available RAM.

By now it should be clear why “out of memory” errors usually have nothing to do with how much physical memory you have, or how even how much storage is available. It’s almost always about the address space, which on 32 bit Windows is relatively small and easily fragmented. "

A few additional points:

1. dlls and program files are always only paged in, never out as they are already on disk ( and usually the first pages freed when physical ram gets low)
2. you are far more likley to run out of free page table entries or have heavily fragemented memory than any other memory issues (other than overall poor performance as already mentioned
3. even if you run with no page file you can still get page faults
4. generally speaking looking at commited memory is more telling of how a process uses memory

for a complete picture of how memory mannagement work in windows see

The Virtual-Memory Manager in Windows NT

if you think you have a memory issue I'd first suggest watching this presentation on troubleshooting windows memory

Here's a great explaination of why sometimes you get "out of memory" when you are not thanks to memory fragmentation:

See also Pushing the Limits of Windows: Physical Memory

More on Virtual Memory, Memory Fragmentation and Leaks, and WOW64

RAM, Virtual Memory, Pagefile and all that stuff (microsoft support)

Update:

Windows 10 does something a bit different with memory and, over time you will see a process called "System and compressed memory" Windows 10 adds a "compression store" to the paging out list. This ram is USER memory that is owned by system (typically system only had kernel memory) This memory is compressed in place for an average reduction to about 30%. This allows more pages to be stored in memory (for those of you doing the math that's 70% more space) Note that if the memory still has pressure then pages from the compression store (user mode System process space) can be placed on the modified list (compressed) which can then be written to the physical pagefile. The system will see they are from the system user mode space and compressed and won't try to put them back in the store. So on windows 10 systems it may look like system is inhaling ram but in fact it's just trying to be more efficient at using ram. Mac users have been using a similar feature since 2013, and newer versions of the Linux kernel employ a version of memory compression. This method of conserving memory is not only better, but already common among other operating systems.

Solution 2:

Yes, the paging deltas would give you a live indication of how much the server is paging (or "swapping"), but only at that moment. To watch this more closely, and to see a historical view, I would suggest using Performance Monitor (perfmon.exe) to chart or record those deltas (and any other performance counters of interest that may help to correlate specific events or activities with spikes in paging activity).

Solution 3:

Performance Monitor (perfmon) is your friend here. You're looking for hard page faults (that is, page faults when the memory page needed to fulfill the request must be read from disk), so monitoring both hard and soft page faults is sub-optimal.

Watch the "Pages Input / sec" counter in the "Memory" object using perfmon to get a feel for how many hard page faults are occurring.