Understanding RAM management and use

[ubuysa]

Most experienced users know that RAM is where program code and data are stored on which the CPUs are currently operating. It's important to appreciate that the CPUs can only operate on program code and data that is already in RAM - any program code or data that is not in RAM is effectively invisible to the CPUs. If a CPU is ever asked to access program code or data that is not in RAM the thread currently executing will be suspended until the program code or data has been loaded into RAM by the operating system. Once that process has completed the thread will be marked as ready and it will be available for execution again.

Consequently the total amount of RAM installed is critical to overall performance. Too little RAM and threads will lose control very often, the time spent suspended whilst waiting for program code and data to be loaded into RAM results in sluggish performance. Too much RAM is not a performance issue but an economic one, there is no point paying for lots of expensive RAM to sit idle and empty.

How do you know whether you have too little RAM installed? The likely first clue will be sluggish performance, but there are may other things that can cause sluggish performance, and poor hard disk management is the most common - by far. RAM is expensive so you don't want to be installing more RAM unless you know that RAM starvation really is a problem for you.

You cannot simply look at the total RAM used figure, in fact the RAM used figures shown in the Task Manager can themselves be confusing, so lets start by examining these values. Start the Task Manager and click the Performance tab, on that tab click the Memory icon on the left to display the memory (RAM) values. The numbers we are interested in are at the bottom..

In use/(Compressed). There are two numbers shown under this heading, the first is the In Use value and the second (in parentheses) is the subset of that which is Compressed memory. In Use is the total amount of RAM currently being used (including Compressed memory), this is what is shown in the larger of the two graphs above. Compressed memory is used to store the contents of pages (a page is 4kB in size) that would ordinarily be written out to the pagefile (more on this later), by keeping the contents of these pages in RAM the later disk read to recover these pages can be avoided and by storing them compressed they take up less RAM. On most systems the compressed memory is only a few megabytes in size.

Available. This is RAM that is immediately available for use. If you add the In Use and Available figures they should come to the total amount of installed RAM (with some rounding errors). The total amount of installed RAM is shown at the top right of the larger of the two graphs above.

Committed. There are two numbers shown under this heading, the first is the total amount of RAM that Windows has given permission to be used. Not all of that RAM may currently be in use however (In Use is always less than or equal to this number) it is simply the amount of RAM that has been requested by processes which Windows has approved. The second number is the total amount of RAM that Windows can possibly give commit permission for on this system (the commit maximum). It is usually much larger than the amount of installed RAM because it includes the maximum size of the pagefile - pages can exist either in RAM or on the pagefile and the sum of RAM + pagefile_size is the commit maximum.

Cached. This is RAM that is being used as a cache, typically to avoid having to write it to disk, which would entail a later disk read and the delays involved in that. Cached memory is included in the Available count because Windows can use it if needed (and the cache would be flushed to disk). Cached memory is part of available memory known as Standby memory, this is RAM that contains caches and program code and data that is not being used by any processes. All of Standby memory could be used by Windows if needed, program code and data would be flushed to the pagefile if required (if the pages have changed since first use).

Paged Pool - Non-Paged Pool. Page pools are areas of storage from which processes allocate extra RAM, for use as workspace in executing threads for example. There are two main types of pool, paged - which can be written out to the pagefile, and non-paged - which must be kept in RAM. The numbers here are the amount of the two types of page pool currently being used. These values are included in the In Use value we saw earlier. As far as performance is concerned these numbers have no real impact because there is nothing a user can do to affect them (beyond ensuring there is enough RAM to contain them of course).

In the smaller of the two graphs above you have a map of RAM usage. If you hover the cursor over each field a popup tells you what it contains. You'll see In Use and Compressed first, followed possibly by Modified - this is Standby memory that must be flushed to disk before it can be used, and then a big region of Standby memory - this can all be immediately used if required (or returned to the In Use memory if the pages are referenced again by the owning process). You may have another region called Free - this is RAM that Windows is not using for anything at all (though it could if required).

If you see no Free memory then don't worry. This is far from a problem, it means you have plenty of RAM installed - for the workloads you are running right now at least.

If you see very little (or even no) Standby memory then don't panic. This isn't a problem (yet), it simply means that Windows is actively using all the RAM you have - but for the workloads you are running right now it doesn't need any more RAM. You have exactly enough - at the moment. You will also see the In Use figure at or very close to the maximum installed RAM. Using all the RAM you have is not in itself a problem, it's actually good economics (although given the variability of workloads you should never plan to run at maximum RAM use).

This Task Manager page does give you a lot of information about your RAM but it cannot really tell you whether you have too little.

[continued in next post]

 

[ubuysa]

Understanding RAM management and use [2/3]

To find out whether you have too little RAM you need to understand how Windows manages RAM using a technique called paging.

When a program is loaded all of the program code is loaded into RAM (that's not completely true but near enough for this explanation). Of that code the initialisation parts of the code will only be executed once and the error handling code may never be executed. Similarly, the termination parts of the code will only be executed once - and haven't been executed at all yet. Most of the time the program will be executing a small subset of code over and over again. There is thus no point in keeping the initialisation code in RAM once it's been executed, it's just a waste of RAM. In the same way, we don't need the termination code in RAM until the program ends. We may never need the error handling code in RAM (this is often the largest component of any program). All we actually need in RAM is the code the program is actually executing.

Notice that if we removed the initialisation code from RAM the program would never know - it's never going to execute it again. If we remove the termination code from RAM the program will never know - until it comes time to terminate. In fact the only code the program knows about is the code it's currently executing. Page stealing is the mechanism that Windows uses to remove pages from RAM that hold code (and data) that is not currently being used. The full details of the page steal mechanism are too detailed for inclusion here, but periodically Windows (with the assistance of the hardware Memory Management Unit) looks at every page of RAM to see whether it has been referenced (used) since the last time it looked, if it's not been used a (hardware) count in incremented. If Windows needs free RAM and there is no Free or Standby memory available, then Windows 'steals' those pages that are not being referenced (based on the hardware count) until it has enough RAM to satisfy the request (so it 'steals' the least recently referenced pages).

A page steal occurs so that Windows can use that page for something else. If the page contents have changed since being first loaded then the page is written out to the pagefile (the pagefile.sys disk file). If the page contents have not changed it's simply overwritten (because there is a copy of that page somewhere else). Note that the processes owning these pages (and it's probably many different processes) have no idea that their pages have been stolen because they're not currently using them. These stolen pages are now available pages and Windows will use them for some other process.

This system works well until a process references a page that has been stolen. When that happens a page fault occurs and the executing thread is placed in a wait. Windows then locates the page in the pagefile, finds a free RAM page (which may mean a steal of some other page), loads the page into RAM, and then retries the page faulted instruction. This process is called demand paging. The problem with demand paging is that the thread is waiting whilst the page-in happens and since the page-in is from disk it's a big performance hit.

You can see page fault rates per process in the Task Manager, but the numbers here will scare you to death! Start the Task Manager and click the Details tab. Right-click on one of the column headers and select 'Select Columns'. Make sure the Page Faults and PF Delta checkboxes are checked. The Page Faults value is the total number of page faults since the process started, the PF delta is the number of page faults since the last update (this depends on the Task Manager update speed in the View menu item). These numbers can be huge...!

This is because there are two kinds of page fault in Windows 10 (and 8/8.1); hard page faults and soft page faults. A hard page fault is where the page has to be paged-in from the pagefile - these are the ones that cause a performance hit. A soft page fault is where the page is found in Standby memory (ie. it never actually left RAM) and so no disk read is needed (and no performance hit is seen). The task Manager as you might have guessed shows both soft and hard page faults without distinguishing between the two.

You can see the current hard page fault rate in the Windows Resource Monitor. Start the Resource Monitor (type resmon in the Run box) and look at the Memory section. On the header bar you'll see the hard page fault rate in the Hard Faults/sec field. You could watch this for a time to gauge whether you are hard paging excessively. If you expand the Memory section and click on the Hard Faults/sec column header you'll sort the processes by hard page faults. The process(es) at the top are the ones paging the most.

Just one or two processes paging is not too much cause for concern (though you might want to investigate these processes memory use in case of a memory leak), but if many of your processes are paging you're likely to be short of RAM.

[continued in next post]

 

[ubuysa]

Understanding RAM management and use [3/3]

By far the best way to see whether you are paging (and thus short of RAM) is to use the Windows Performance Monitor. Start the Performance Monitor (type perfmon in the Run box). In the tree menu on the left click the Performance Monitor entry. The Performance Monitor starts with a %processor time counter already running, we don't need that so we'll remove it. Right-click anywhere in the graph display area and select Remove All Counters (click Ok when asked). Now we need to add a couple of performance counters, so right-click anywhere in the graph area again and select Add Counters. In the dialog listing the available counters scroll down to find the Memory entry and expand it (click the right down arrow). Scroll down in the Memory section to the Page Faults/sec and Page Reads/sec entries, highlight both and click the Add button to add these counters, then click Ok to close the dialog.

Below the graph you'll see the colours assigned to each counter (typically these are green and red). You'll see the page faults/sec value varying quite wildly and often being clipped at over 100, that's because this is showing both hard and soft page faults (the values we see in Task Manager). In a system with enough RAM the page reads/sec counter will barely shift off the bottom of the graph. If you see the page reads/sec counter shooting wildly up and down like the page faults/sec counter consistently and over long periods then you are most likely short of RAM (but check that the hard page faulting is system-wide and not just one process). Note that even on a system with plenty of spare RAM you may still see the odd few page-ins occasionally, this is perfectly normal and not at all a cause for concern.

Before we end this brief overview of RAM management there are some other values you can display on a per process basis in Task Manager (and in Performance Monitor if you want to monitor them over time)...

Working Set. This is the total amount of RAM currently being used by this process (in kB). It's made up of two parts; the Private working set which are pages that only this process can use, and the Shareable working set which are pages being shared with other processes (typically DLLs).

Commit Size. This is RAM that the process has requested for private pages and which Windows has approved, though the process may not have used (referenced) all of it at the moment. Windows will commit memory only if there are enough pages in RAM and/or the pagefile to hold every committed page.

You can sort the processes on any of these fields by clicking on that header. If you click on the Working Set header those processes at the top are the ones using most RAM (your browser is probably the top one).

I didn't actually intend to write this much when I started, but I hope it helps some of you. In particular you now know how to be sure that more RAM will make a difference to you performance problems.

Let me finish with this though - the overwhelming majority of performance problems in a PC based only on an HDD are poor management of that HDD. If your system is sluggish and you only have an HDD then clean that up first - it's the most likely cause of your problems.

 

[polycrac]

Thi is a great guide, it really helped me to understand more about RAM - thank you! It got me using the resource monitor and performance monitor which I'd mostly ignored before. I hope you don't mind me adding the links for easy moves through it.

 

[Tony1044]

Related to this, I recommend the deep dive into memory and particularly how Windows uses the page file from the founder of Sysinternals, Dr Mark Russinovich.

Sysinternals became famous in certain circles within IT/systems management for their superb tools. Indeed, I've relied on them heavily over the years to troubleshoot issues.

Microsoft bought them out eventually, and Mark is now a fellow in their research team.

This isn't the lightest read on the planet, though Mark makes a good fist of not being too heavily technical (and boring) that makes it an impenetrable read: https://blogs.technet.microsoft.com...pushing-the-limits-of-windows-virtual-memory/

 

[ubuysa]

Related to this, I recommend the deep dive into memory and particularly how Windows uses the page file from the founder of Sysinternals, Dr Mark Russinovich.

Sysinternals became famous in certain circles within IT/systems management for their superb tools. Indeed, I've relied on them heavily over the years to troubleshoot issues.

Microsoft bought them out eventually, and Mark is now a fellow in their research team.

This isn't the lightest read on the planet, though Mark makes a good fist of not being too heavily technical (and boring) that makes it an impenetrable read: https://blogs.technet.microsoft.com...pushing-the-limits-of-windows-virtual-memory/

Mark Russinovich is one of the authors of the superb book Windows Internals, it's required reading for those who really want to know how Windows works. It's in two parts and they're not cheap books either, nor are they for the novice, you need to be a techie to get the most from them (I'm fortunate in having spent years working with MVS internals - IBM's mainframe operating system - so many of the concepts are familiar). The 7th edition (to which I've recently upgraded) covers Windows 10 (up to 1607 - the Anniversary Update). Only part 1 is available now, part 2 of the 7th edition is due out next year. A great deal of the book uses the Sysinternals tools that Mark wrote to illustrate the details of WIndows internal operation.

 

[Tony1044]

Mark Russinovich is one of the authors of the superb book Windows Internals, it's required reading for those who really want to know how Windows works. It's in two parts and they're not cheap books either, nor are they for the novice, you need to be a techie to get the most from them (I'm fortunate in having spent years working with MVS internals - IBM's mainframe operating system - so many of the concepts are familiar). The 7th edition (to which I've recently upgraded) covers Windows 10 (up to 1607 - the Anniversary Update). Only part 1 is available now, part 2 of the 7th edition is due out next year. A great deal of the book uses the Sysinternals tools that Mark wrote to illustrate the details of WIndows internal operation.

Ah yes. First got it when it was in its second edition for NT4 but didn't really get into it properly until the third edition covering Windows 2000.

It was fundamental in helping me pass my 2000 MCSE, back when such things still meant something

Edit: I am sure Mark didn't write the first one or two?

Ahh yes - the history of it is here: https://docs.microsoft.com/en-us/sysinternals/learn/windows-internals and indeed, Mark was involved from the third edition onwards.

 

[Oussebon]

off topic but I was wondering if it might make sense to merge these 3 threads into 1?

 

[Tony1044]

It'd be a long 'un but it might do.

 

[ubuysa]

off topic but I was wondering if it might make sense to merge these 3 threads into 1?

That would be sensible of course. I did it this way simply because it was too big for one post. Now merged into one.