How do I tell if my Windows server is swapping?

Question

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.

Answer 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)

Answer 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).

Answer 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.

Answer 4

A good rule of thumb is that if your commit charge is higher than your physical memory, you are definitely paging something, but if your app uses a single fixed data buffer that is always being kept in-use, it generally won't be paged out at all. There may be some delay at startup while other memory is paged out to make space for this.