Share via

PerfGuide: Low available physical memory (RAM)

  • Article

If you have arrived here, then you have identified a low available physical memory condition on your Windows computer. If this is not correct, then return to the Start of the Performance Guide.

Available physical memory concepts

When the counter \Memory\Available MBytes has a value less than 10% of the physical memory installed, then it increases the system's dependence on the disk subsystem. If the disk subsystem is overwhelmed, then system-wide delays can occur.

The Available MBytes counter is the sum of all free, zero (a page of memory with all zeroes written to it), and standby pages of physical memory. Generally, if 10% or more of physical memory is available, then it is considered good because that allows up to 10% of it to be used for disk cache. The more disk cache (standby list) a system has, the greater chance it has to avoid disk IO. Disks are dramatically slower than physical memory, so a large disk cache (standby list) is desirable.

Keep in mind that low "free" memory is fine, but it is not fine to be low on "available" memory.

Troubleshooting

If Available MBytes is less than 10% of physical memory installed, then it is important to determine which resources are consuming physical memory. The following is a list of common "suspects":

  1. Process working sets: The “Working Set” of a process is the amount of physical memory in use by a process. Look at \Process(*)\Working Set to see which processes are consuming the most physical memory and which are on an increasing trend. Keep in mind that Working Set is only the amount of physical memory usage of a process and does not show memory that has been paged out.
  2. System Cache: \Memory\System Cache Resident Bytes is the size, in bytes, of the portion of the system file cache which is currently resident and active in physical memory. This is the "working set" of the system cache and like process working sets, it uses physical memory. Investigate disk and network IO if system cache has a significant amount of memory usage.
  3. Kernel pool memory: \Memory\Pool Nonpaged Bytes and \Memory\Pool Paged Resident Bytes are driver memory pools that consume physical memory. If either one of these are significantly high, then use kernel pool tools such as Poolmon.exe or Windows Performance Recorder with Pool Usage enabled to investigate the driver tags.
  4. Address Windowing Extensions (AWE): AWE is uses large memory pages to "lock" physical memory. Process memory related counters do not accurately track AWE memory usage. AWE is commonly used by Microsoft SQL Server. Use the "Active" column in RAMMap to detect AWE memory usage.
  5. Driver locked: This is physical memory that has been locked by a driver and commonly used by a virtualization software such as Microsoft Hyper-V to lock physical memory for a virtual machine. There is no performance counter to directly measure driver-locked memory. This is also commonly used by VMWare to “balloon” physical memory within a virtual machine. Use the "Active" column in RAMMap to detect "Driver Locked" memory usage.

Treating the Symptoms

If all of the above troubleshooting steps have been exhausted, then the symptoms of low available RAM can be treated with one or more of the following:

  1. Add physical memory: More physical memory will increase the amount available to the system.

Note: Adding or increasing a page file to a system only effects system committed memory which is a different topic. 

References

Chapter 8: Physical Memory of the Windows Performance Analysis Field Guide by Clint Huffman

More Information

Vital Signs Workshop: Microsoft Services offers an instructor led workshop called, "Vital Signs", which goes in depth into Windows architectured focused on Windows performance analysis. If you are interested, then contact your Microsoft Technical Account Manager (TAM). If you do not have a Microsoft Premier Support contract, then consider the great benefits of having one by going to our Microsoft Services Premier Support web site at: http://www.microsoft.com/microsoftservices/en/us/support_premier.aspx

Special Thanks and Contributors

Shane Creamer for originally creating the Vital Signs workshop and inspiring us all with making performance analysis a science.