Identifying if your computers are already swapping or about to swap

Introduction

The goal of this paper is to explain in a simple way certain things about RAM management and to help you find if your system is swapping or about to swap, which may then cause some performance issues. I am not going to explain you all of the intricacies of the memory (there are awesome documentation sets for that, linked at the end of this document).
I was asked lately to intervene on a problem and thought about the memory management and the fact that the problem could have been caused by memory being swapped in.
In order to have a better understanding of it, I then begun to dig around a bit and found interesting things I'd like to share with you.
We'll have a look to :
1.      Top level View of the RAM management
2.      Fast facts about windows' pagefile.sys management
3.      Finding out the good info about swapping
4.      DIY (Do It Yourself - hands on lab)
5.      Conclusion

1.      Theorical View of the RAM management
In Windows, the RAM is processed through a cycle. This foundation is important to know because it will help you to better grasp how windows is managing it's memory.
Windows has an "on demand" RAM management system. Thus, if a process has need of RAM, it will ask the memory management to allocate RAM to it.
The RAM is managed by pool which is often called "paged lists". To make it simple, we'll say there are five of them (in fact, there are a few more, but we'll put them aside) :
When your computer starts, all the RAM you have is marked by the system as "free" (thus going into the free page list). As soon as the RAM is marked as free, the thread we'll call the "zero thread" will happily fulfil its life goal : to zero it (fill it with zeros). The memory will then pass from the free page list to zero page list, which means it can now be used by the system to be allocated or assigned to processes.

Once the RAM has been zeroed, when a process needs RAM, the memory management system will take it from the zero page list and put it in the process working set. The Working set is the RAM allocated to a process and there's one working set per process.
Once it gets out of the working set, it can go to the modified pages list or, if you close your application, it will go in the standby pages list (waiting for you to call it back for later use).
You'll understand more about the StandBy Pages list in the Section where we will do some exercises (refere to the exercise named "let's do some hacking").

One thing that I found interesting is that Windows is an "on demand" memory allocation type of system. That simply means that, when the process needs more of memory, the memory manager will give it more memory, because the process so nicely asked for it...

Knowing that the allocation of the memory for your processes is on demand, Windows will face a problem: at some point, it will run out of available physical memory. In order to manage this limit, Windows will use a swap file (pagefile.sys) where Windows dumps into the pagefile.sys file any older data (the data within ram you're less frequently using) and swap them out on the process's demand. This makes it possible to increase the limit of your system's useable memory without having to buy new RAM and stop the system to upgrade the old good hardware. It allows you to have a system that continues to run even if all its physical memory is used (I'm not speaking of performance here, but just that your system won't BOSD when its physical memory limit is reached).

The memory limit of your system is then defined by the amount of physical memory Windows can use plus the amount of data it can put in the pagefile.sys file (the size of the file). If you face a memory shortage problem, you'll then have two ways of solving it: add some more physical RAM into your system or expand the pagefile.sys file.

This has advantages and disadvantages. Because the pagefile.sys is written onto a hard drive, swapping data in or out takes more time than reading it into or out of the RAM. This is why the less used data in memory is swapped in. You can manage the size of the swap file yourself, ask to Windows to not use a swap file or let Windows manage it for you. I think that Microsoft has much bigger brains than mine, so I usually let Windows manage the pagefile.sys' size by itself.

There's still a paradigm left: How can Windows manage a limited set of physical memory efficiently if the processes are asking for the memory in an "on demand" manner ?

In fact, in order to do more with less, Windows is managing its memory in two ways: the virtual memory management and the physical memory management.

When your process asks for memory, Windows will do a kind of double allocation. First in virtual memory, Windows will permit the process to reserve memory for later use, to have memory allocations that will seem contiguous (because it's virtually contiguous). You can then face memory fragmentation in the virtual memory.
But If you look to the same process's allocations in the physical memory, you'll find that Windows has consolidated the memory's allocations. They're not especially contiguous in the physical RAM, but they're not fragmented. By this method, windows is consolidating as much as possible the usage that's made of the physical memory.

Now that we have a better understanding of how windows is managing the memory, we'll quickly take a look at the system's architecture. Because there are two different commonly used architectures these days (x86 and x64), the limitations in term of memory usage are not the same.
To make things simple, Windows is taking the maximum amount of physical memory that the architecture can use and splitting it in half. The first part is the maximum amount of virtual memory a process running in kernel mode can ask for. The second half is the maximum amount of virtual memory a process running in user mode can ask for.

Let's take an example :

On a computer with 32 bit Windows and 4 GB of RAM (maximum amount managed by a 32 bit system), you'll have 2 GB of Virtual memory for processes running in user mode and 2 GB of RAM for processes running in the system mode (approximately 2^31 bytes). This is the default setting. But you can tweak your system to make it use 3 GB for user mode processes and 1 GB for kernel mode processes.

On a computer with a 64 bit Windows and 4 GB of RAM, each process (whether it's running in user mode or system mode) will have a 8 TB of Virtual Memory at its disposal. "But Wait," you might say. "64 bits makes something like 16 Hexa Bytes and not 8 TBytes...". And you're right. The fact is that Windows, in 64 bit systems, only makes use of 44 bits for its memory allocations. This computes to 16 TB. Split it in half and you get 8 TB by process per mode. It permits windows to virtually allocate more memory that it physically have and to manage it as we explained earlier.

2.      Fast facts about Windows' RAM management
You'll find in this section the default size of the pagefile.sys file for each amount of RAM i measured in my lab.

Windows XP (32 bit) :

Amount of RAM (Physical Memory)                  Pagefile.sys Size
8 GB                                                           3071 MB
4 GB                                                           3071 MB
2 GB                                                           2047 MB
1.5 GB                                                     1535 MB
1 GB                                                           1535 MB
768 MB                                                     1151 MB
512 MB                                                     767 MB

By looking at this data, you might ask why the pagefile.sys would only be 3071 MB large. In fact, Windows cannot handle 4 GB of memory for a process. If you tweak your 32 bit system, you'll only be able to get it to go to 3 GB of memory for its use. But if you do that, the downside is that the system mode processes will only have 1 GB of memory allocated to each one of them. Windows is thus translating the maximum amount of memory a user mode process can handle into the size of the pagefile.sys.

When you reach a size Windows can handle per user mode process (3071 MB), Windows will give to the pagefile.sys the same size you have in Physical memory (minus 1 MB)
If you reach the 1 GB limit, you'll then have the pagefile.sys that takes 1.5 times the amount of physical memory you have (RAM) minus 1 MB.

Windows 7 (32 bit) :

Windows 7 will look very similar:

Amount of RAM (Physical Memory)                  Pagefile.sys Size
4 GB                                                           3071 MB
2 GB                                                           2047 MB
1.5 GB                                                     1535 MB
1 GB                                                           1024 MB
768 MB                                                     1024 MB
512 MB                                                     1024 MB

The difference will be when you reach the 1 GB limit of RAM (Physical memory). If you go under this amount of memory, the pagefile.sys will automatically be of 1024 MB (1 GB).

64 Bit Windows (7 and 2008-R2):

Amount of RAM (Physical Memory)                  Pagefile.sys Size
8 GB                                                             8191 MB
4 GB                                                             4095 MB
2 GB                                                           2047 MB
1.5 GB                                                     1535 MB
1 GB                                                           1024 MB
768 MB                                                     1024 MB
512 MB                                                     1024 MB

We can conclude that, in 64 bit Windows 7 and 2008-R2, unless you reach the limit of 1 GB of RAM (physical memory) on your system, you'll have, for a starter, the same amount of size available through the pagefile.sys file.

As I've mentioned before, Windows will take the swap file into account and add it to the RAM you have in your computer. This will become the memory limit. If Windows manages the pagefile.sys' size, it will continue to grow as long as you have available space on your hard drive. When you'll reach this limit, your computer will just cease to operate effectively (which is a funny thing to see in a lab, but when a user get this kind of bug, it's not fun anymore).

Note : By the Way, This is an advantage of the use of SSD drives. When you're using the pagefile.Sys, you're not going to see a lot of impact on your system's performances.

Now that we have a broader view of Windows RAM management, let's make a quick stop to summarize what we've seen so far :
We'll now have a look to indicators. This will lead us to understand and find out how to monitor our computers to see if they need to have memory added.

3.      Finding the good infos about the swap in

Since I began to work in IT, I've seen that the first thing a lot of IT Pros do when troubleshooting performance issues is to open the Task Manager and have a look there to find out if the computer is using all its memory. It's common to think that your RAM usage counter in the Task Manager is telling you all there is to know about your RAM usage and to think that Windows will only swap if the system is using all the RAM it has (which you could eventually find in the performance counter in the Task Manager).

I have bad news for you: The Task Manager doesn't tell you if your physical memory is exhausted and if your system is swapping. If you don't believe me, please, keep reading and do the testing for yourself (DIY  part at the end). You'll find that the results are stunning!

To make my point, open the Task Manager and go into the processes details. Right click on the headers of the columns and choose to select a column. You'll find that you can select to see more details and have more insights into Windows memory usage indicators than just by default.

Then, go to www.sysinternals.com and download the whole suite. These are great tools for troubleshooting and testing windows systems and we'll make some use of them.

Once you've copied and unzipped the sysinternals tools, open process explorer and have a look the the memory indicators you can find by just double clicking on the graph (top of the windows, under the menu). You'll find that there is a commit charge, and it's not indicating the same amount of memory used that your performance window is showing you in the Task Manager.

In general terms, sysinternals' Process is more accurate than the Task Manager when you look at the "commit charge" indicators. If you go in the list of your processes and right click on the column headers, you'll find that you can (as in the Task Manager) choose what columns you want it to display.
Though Process explorer is a great tool to find info about the usage my systems had on its memory, I needed to identify more clearly when my systems were about to swap and when they were already swapping. So I used one of the other great tools Microsoft has offered us in Windows : the WMI tools (Windows Management Instrumentation).

We'll first see how we can use them to find if our pagefile.sys' size is managed by windows and then we'll see how they will help us to see if our computers are swapping or about to swap (ideally, the answer would be "neither").
You have some WMI objects and classes you can work with to find if your pagefile.sys size is managed by your system, has a minimum and a maximum that was given to the system (handy management) or is non-existent.
By having a look at the Win32_pagefilesetting class, you'll find that if the maximumsize and the initialsize are equal to 0 when Windows is managing it by itself. If there's no pagefile.sys, then windows will return "no available instance". If the pagefile.sys size is entered manually, then the two objects will return the respectively manually entered sizes.
To find it in Powershell, enter

gwmi win32_pagefilesetting | fl *

Select all Open in new window

In the Windows command line, enter

wmic pagefileset

Select all Open in new window

If you want more information about your pagefile.sys file, you can try the win32_pagefile class, but you'll only get the size of your pagefile, which is, to be honest, not enough intel...

So, in order to find more additional info, let's have a look to another class :

Win32_OperatingSystem (gwmi win32_operatingsystem | fl *)

Select all Open in new window

It will give us some good insights, but remember : The insights you'll get won't be the same on a Windows XP machine compared to one with Windows 7.

In the win32_operatingsystem class, you'll find yet more objects which will help us better understand if our system is swapping. The indicators we'll look at are:
By taking a look at the size of my page file (wmic pagefile) and the free space in my page file (wmic os get freespaceinpagingfiles), I noticed that even if my machine has free memory, it is swapping a bit (generally, a few megs). This is the normal behavior from my system. Usually, Windows will always use a bit of space in the pagefile.sys to store some data, but it's only a minimal amount of data that is swapped in.

So, armed with all of this information,how will this help us ?
In a Windows XP system (this test has not been run under 2003, but the technology isn't so far from windows XP's), you'll find that looking at the win32_operatingsystem class and using the FreeSpaceInPagingFiles and SizeStoredInPagingFiles will let you know if you are swapping. When freespaceinpagingfiles goes under something around one-tenth of the freevirtualmemory (it can vary a bit), the pagefile.sys grows.
Thus we can calculate it this way :
IF ( (freevirtualmemory / 10) - freespaceinpagingfiles ) ~<= 0  THEN pagefile.sys grows

In Windows 7 and 2008-R2 systems, the calculation is a bit different (This works as well for Windows 8 64-bit). You'll have to take a look the the FreeVirtualMemory object instead of the freeSpaceInPagingFiles Object. We'll take the sizestoredinpagingfiles and divide it by 10. We multiply the result by 1.5 and we have the virtual memory threshold. If we break this threshold, the pagefile.sys size will grow (the system will thus swap in).

Thus, we can calculate it this way :
IF ( (SizeStoredinPagingFile / 10 * 1.5) -FreeVirtualMemoryObject ~<=0 THEN pagefile.sys grows

We now have an good indicator that will permit us to monitor if our systems are about to swap : if the result approaches zero, you know that there is an increasing probability that your system will make its pagefile.Sys file grow.

Do you remember how I've talked earlier about the memory growth of a system? It's either the physical memory or the pagefile.sys file size that grow, making the whole TotalVirtualMemory grow. We can then conclude that if your system is usually near the calculated limits we found earlier, it's time for you to add more physical memory.
We just saw that windows has thresholds to make your pagefile.sys file grow and that it's usefull to see in a proactive manner if it's time to add some RAM to your systems. But, if you don't have the possibility to capture the evolution of the memory usage in a "live" way, it could be usefull for you to monitor if your systems are already swapping.
so, here's the thing : you can use the same indicators to find out the "true" memory usage of your systems.

On windows Xp :

You can use the win32_operating system class, and especially the freespaceinpagingfiles object and compare it to the SizeStoredInpagingFiles object to know the real memory usage that is made on your system. Once you know that, simply compare it to the physical amount of memory you have (the TotalVisibleMemorySize object) and that will show you if your system is using more RAM that it really have.
You can in parallel monitor the pagefile.sys file size through the win32_pagefile class and monitor the AllocatedBaseSize object. If it doesn't correspond to the default pagefile.sys size, then you'll know your system has augmented the size of the pagefile.sys file.

On Windows 7 / Windows 2008 R2 :

To monitor if your pagefile.sys will be used, you can simply monitor the totalvirtualmemorysize and substract to it the freevirtualmemorysize object. You'll then have the "real" usage of your memory and know by comparing this result to the totalvisiblememory object if you need to add RAM.
You can as well monitor the AllocatedBaseSize object of the win32_pagefileusage object to see if it's size corresponds to the measurement that i've given to you before.
Thus, to have better performance, you'll now be able to monitor your whole system with some good indicators.

4.      DIY (Do It Yourself)

For this "hands on lab", you can create a virtual machine per OS and test the different values. I worked with Windows XP, Windows 7 and Windows Server 2008-R2 in a testing lab. You'll need to download the whole sysinternals suite from www.sysinternals.com. You'll need as well to download testlimit from the Windows internals tools.

1.

Let's begin with finding if our system is managing the size of the pagefile.sys file by itself, or not at all, or if the size of the page file is manually entered. To do this, simply open a command prompt and enter

wmic pagefileset get initialsize,maximumsize

Select all Open in new window

If "no instance available" is shown, you don't have a pagefile.sys used by Windows.
If the result is 0 in both objects, then, Windows is automatically handling it.
If the result is a different value, then you'll find that there were manually entered.

2. On Windows 7 (part 1)

Let's now have a look to the swap indicators I talked about earlier :

3. On Windows 7 (part 2)

Now, we'll need to do a bit more of maths. If you're working on x86 system, do you remember the virtual memory allocation by process limit? You're right, 2048 MB.

So, if you try to allocate 2048 MB through testlimit, it will not work. Thus, to compensate, take the free virtual memory result we calculated earlier and divide it by 1024. Now, open as many command prompt as the integer part of this division tells you and launch this command

testlimit -m 1024 -c 1

Select all Open in new window

If you're working on x64 systems, the virtual memory allocation by process limit being 8 TB, you don't need to worry about this little workaround. Notice how the pagefile.sys file has grown ?

4. On Windows XP (32 bit)

Growing the Pagefile.sys on XP

Do you remember how I explained earlier that the WMI objects used in XP are different? Let's take a look: Has the pagefile.sys file grown ?

5. Fun with the Swap

Now we'll have a bit more of fun by pushing the limits to their maximum.

6.

On x64 systems:
Let's now try to launch testlimit -m 1 on a x64 system (try it with the three page file management options of Windows). You'll see your pagefile growing and growing. The fun part is the behavior of the system after a while. It'll soon become unresponsive and if you let it go to the end, it will crash...

7. the standby memory

Finally, let's do some hacking:
do you remember as i talked about the standby memory in the first part ? Here's the thing :
when you open & close documents, windows will put them in the standby memory. They'll be stored in it until you restart your computer.
So, it's possible to use this to hack some datas :

5.      Conclusion
As we've seen, you will need a bit of hands-on management to monitor if your system is using its pagefile.sys file in an abnormal way (meaning that it's not your usual system's swap in which is taking place). Windows is always swapping a bit, but you need to use some indicators to monitor it.
If you want to find which process exactly is causing the machine to go dingo on swap in, then, you can use great tools as VirtualMap and process explorer. The get-process commandlet in powershell will take you close of the truth if you're adding the PrivateMemorySize and the Workingset of the process (use the 64-bit version of them if you're working in a x64 architectured system).
Finally, it doesn't matter if windows is using your whole physical RAM or not before it swaps in and out datas in it's pagefile.sys file. The fact and the matter is for you to be able monitor if the file is growing, thus hurting performances and the available space on your disk...
When you see that your system is adding datas into your paging file, you have the choice to leave it "as is", or to add the totalVirtualMemorySize object of your system (in windows 7 / 2008R2) or the SizeStoredInpagingFiles object (windows xp) by adding more RAM.
You can find some great materials at www.sysinternals.com. You can find in a good bookstore the book about sysinternals tools. One of the great resources that helped me to better understand swapping was the "Windows Internal" book (ISBN: 978-0-7356-6587-3) and the teched videos from Mark Russinovich that you can find on Channel9's website; search for "Mysteries of Memory Management Revealed Mark Russinovich TechEd North America 2011" and you'll find it quickly.
      
If this article helped you, please, let me know by posting your comments.