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)
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) :
Free Page List
Zero Page List
Modified Memory Page List
Standby Memory Page List
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).
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 :
When your computer starts, the Memory cycle starts: first the memory is marked as free, then zeroed. The memory manager places some of it in a process's working set when asked for memory by the process and the memory goes then in the modified page list or in the standby page list before being reused by the system.
If the processes need more memory than what's physically available, Windows will put the less used of the data in the pagefile.sys file. This frees some RAM and your system will keep working (nobody likes the BSOD these days...)
The memory is managed in 2 steps : first in the virtual memory allocations. It's then consolidated and put into physical memory.
Windows is working to make the most out of limited resources so the size of the pagefile.sys, by default, has some logic behind it.
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 *
In the Windows command line, enter
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 *)
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:
FreePhysicalMemory: indicates if there's some free physical memory (at least theoretically)
FreeSpaceInPagingFiles: Windows 7 and 2008R2 : used to calculate the used space in the Pagefile.sys - Windows XP : indicates the true usage of your memory (compare it to the sizestoredinpagingfiles object
FreeVirtualMemory: one of the most interesting indicator
TotalVirtualMemorySize: is the size of the Physical Memory + the PagingFile size
TotalVisibleMemorySize: is the size of the physical memory
SizeStoredInPagingFiles: in Windows 7 and 2008-R2 : indicates the size of the paging file - in Windows XP : Indicates the total amount of memory you have (physical memory + pagefile.sys file)
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
will let you know if you are swapping.
freespaceinpagingfiles: indicates what's left to use before pagefile.sys' size grows
sizestoredinpagingfiles: indicates the size of the pagefile.sys file
freevirtualmemory / 10: indicates the limit.
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
. You'll need as well to download testlimit from the Windows internals tools.
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
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 :
Copy and unzip your sysinternals and windows internals suites files on your windows 7 and 2008 R2 VMs
open a powershell prompt and enter: gwmi win32_operatingsystem | select FreePhysicalMemory,FreeSpaceInPagingFiles,FreeVirtualMemory,TotalVirtualMemorySize,TotalVisibleMemorySize,SizeStoredInPagingFiles
take a look to the SizeStoredinPagingFile and FreeVirtualMemory Objects
do some maths : SizeStoredInPagingFile / 10 * 1.5
calculate FreeVirtualMemory - the result of the preceding line and divide it all by 1024 (changing the result from KB to MB) which will give use the free virtual memory before swapping of the system
open a command prompt and go into the directory where you've unzipped the systinternal suite
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
Recheck the "freevirtualmemory" left and calculate again the "FreeVirtualMemory"
SizeStoredInPagingFile / 10 * 1.5 - this will give you what's left over before your system begins to swap
open a new command prompt and launch testlimit -m <the leftover> -c 1
in a PowerShell window, relaunch the gwmi win32_operatingsystem | select FreePhysicalMemory,FreeSpaceInPagingFiles,FreeVirtualMemory,TotalVirtualMemorySize,TotalVisibleMemorySize,SizeStoredInPagingFiles
you'll notice that your "sizestoredinpagingfiles" have changed and is bigger; your machine has begun to make your pagefile.sys file grow...
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.
Just open a command prompt
launch testlimit -m <free virtual memory before swapping> -c 1
go back into your PowerShell window and launch the gwmi win32_operatingsystem command (you'll find it a few lines up from here)
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:
open a command prompt
enter the command pagefile: this will give you the pagefile.sys size
enter the command os get freevirtualmemory,freespaceinpagingfiles
now, calculate (freespaceinpagingfiles - (freevirtualmemory / 10) ) /1024
This leftover is the memory charge left before your systems begin to make the pagefile.sys grow. So, open a command prompt and lauch testlimit.exe -m <your leftover> -c 1
enter the command pagefile : this will give you the pagefile.sys size
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.
In each of your 32 bits VMs, launch a command prompt and launch "testlimit -m 1". This will allocate 1MB at a time the memory until the process cannot obtain more memory.
Then, launch multiple instances of the command prompt with testlimit. After some time, your machine will begin to act in a weird way...
Now, try the same experience but, before that, Go into the advanced system properties to Tell windows to not use a swap file.
Calculate the freevirtualmemory and launch a command prompt with testlimit to make that your system just have 10 MB left over.
Once this is done, let's have some fun by launching processexplorer.
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 :
install the Windows SDK on your Windows 7 system
place the livekd.exe from the sysinternal suite in the same directory as KD.exe in the SDK directories
once this is done, enter a new session on your computer. Create a .txt file on the desktop
encrypt it with EFS
open it and type some text
save it and close the windows' session
enter an admin session on your computer without restarting it
open rammap.exe and go into the "file details" tab
hit ctrl+F to find the text you've created on the other user's session desktop. That's right, you'll find it in memory (in the standby memory)
now open a command prompt
go into the directory where you'll find the livekd.exe and the kd.exe of the windows SDK
launch livekd.exe in the command prompt
in rammap, in the file details tab, click on the little "+" sign at the left of the encrypted file you've created earlier and found in the standby memory
in the command prompt, once the livekd is launched, enter !DB <physical address from rammap of your file>
hit enter in the command prompt and you'll see the text you've saved in your encrypted file appears
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.