How do I know how much swap is used on Windows 7?

Question

Apparently, as per Commit charge is 100% full but physical memory is just 60% when using no page file and http://brandonlive.com/2010/02/21/measuring-memory-usage-in-windows-7/, the Commit numbers in Windows 7 Windows Task Manager include both the physical and the swap memory, and count the virtual memory that has been allocated, but not necessarily has ever been used yet (i.e. not necessarily backed up by any physical source).

As such, is there a way to know the actual swap usage on the system? Simply subtracting physical memory from the Commit numbers won't work, as it apparently includes this unused-but-allocated space, too.

I mean, Windows 7 is supposedly a modern operating system; surely it must have the functionality to see how much of the swap space is actually presently being utilised, right?

Solution

The Performance Monitor (perfmon.exe) has counters for the page file usage.

1. Load it up by either running "perfmon" on a command line, or by selecting "Performance Monitor" under Administrative Tools.
2. Expand "Monitoring Tools" in the left column and select "Performance Monitor."
3. Right-click on the graph to the right and select, "Add Counters."
4. Scroll down the list of available counters to "Paging File."
5. Click on the down-arrow icon to the right of "Paging File."
6. Click on "% Usage" under "Paging File" and then click the "Add" button to put the counter under the "Added counters" list on the right.
7. Click the "OK" button.

The graph will now contain a line for the page file utilization percentage.

Comments

[magicandre1981]

run ProcessHacker (processhacker.sourceforge.net), go to Tools->Pagefiles. Here you see the current and peak usage.

[Jamie Hanrahan]

If you don't have a pagefile then clearly NO "swap" space is being used.

[Memitim]

Sorry, forgot to add that you can also get numeric results and add to scripts by using PowerShell: Get-Counter '\Paging File(*)\% Usage'

[Memitim]

Should be actual usage. "Should" because it is a black box check, so no way to verify the source, but it appears accurate in testing. As for getting a numeric quantity, either multiply the % usage by the page file size or get total page file usage of all processes in bytes: get-counter '\Process(_total)\Page File Bytes'

[cnst]

Where do I input the code as you provide? Also, what kind of testing did you do -- did you try to allocate several gigs of RAM, to see Commit grow by said number (and exceed physical memory), but the Paging File counter remain the same?

[Memitim]

You can either open a PowerShell command window and run the commands, or you can open a regular command window, type "powershell", and then type the command; i.e. powershell 'get-counter '\Process(*)\Page File Bytes'. You can also just type "powershell" by itself and hit enter to have the command window change to the PowerShell shell.

[Memitim]

As for testing, pretty much. Loaded up a few VMs to max memory usage and then loaded a couple more of known size.

[cnst]

So, do you confirm these counters don't just relate to the Commit size?

[Jamie Hanrahan]

@cnst: You can't "allocate RAM", at all. You allocate virtual address space.

[Jamie Hanrahan]

@cnst The \Paging File(*)\% Usage counter reflects the actual amount written to the pagefile, not the commit charge. But \Process(*)\Page File Bytes is the commit charge for the process, NOT that process's actual pagefile usage. In fact it is a duplicate of the Private Bytes counter (also the commit charge). (Yet another example of inconsistent and even misleading nomenclature in this area.)

[cnst]

@JamieHanrahan, I completely lost track of the comments here, and the novelty of your last comment; if you think it's significant, and potentially answers the question in a better way, feel free to post it as a new answer instead!

[Jamie Hanrahan]

@cnst The actual answer here is fine. (Perfmon's %usage counter shows actual pagefile usage, i.e. how much has been written to the pagefile. Yes, it shows it as a percentage of the pf's current size, but oh well.) However the Process\Page File Bytes counter shows a process' commit charge, which is more or less its maximum potential pf usage. Since the original answer is correct, and commit charge is not part of the question, i don't think another answer would say anything different from this one.