The best single indicator of a real memory (RAM) shortage is Available Bytes. This Counter reports the current number of pages (in bytes – there are 4096 bytes in a page) in the Zero, Free, and Standby Lists that the Memory Manager maintains. This pool of available memory is used to resolve page faults quickly. So long as there is a cushion of Available Bytes that is at least 5-10% of the size of RAM, you probably have sufficient memory to run your workload.
It is also important to monitor Available Bytes to see if it remains at or near a threshold value of 4 MB. When Available Bytes (the sum of Zero, Free, and Standby Lists) falls below approximately 4 MB, it triggers a change in the operating system’s memory management policy. The working set of a process is defined as the number of virtual memory pages that it is allowed to keep resident in RAM. Normally, the working sets of processes that are running at their maximum working set size are adjusted upwards periodically by a component of the Windows Memory Manager. This allows processes that need more RAM to grow their working sets over time. However, when Available Bytes are in short supply, the working sets of processes already running at their maximum working set size are no longer adjusted upwards. Since this change in policy often leads to increased paging activity, it is a good idea to monitor Available Bytes and set off an alarm whenever you find it hovering consistently at about 4 MB.
Figure 1 below is a graph showing the utilization of RAM on a Windows 2000 server that shows Available Bytes dropping sharply to 4 MB shortly after 20:15 and stabilizing at that point afterwards. The other Counters charted represent real memory usage in various system-managed pools: as usual, the non-pageable pool, the pageable pool, and resident bytes in the file cache are the most significant consumers of real memory. In this instance, something causes resident cache bytes to increase (evidently due to some file access activity), which serves to deplete the supply of Available Bytes. Notice that once Available Bytes drops to 4 MB, it stabilizes at that value, even as the file cache expands (probably at the expense of RAM-resident process Working set bytes (not shown). The change in memory management policy allows the Windows Memory Manager to maintain the pool of Available Bytes at a relatively constant level. But, because RAM is in short supply, something has to give. The result is a predictable increase in demand paging.
Figure 1. RAM usage on 256 MB Windows 2000 Server.
Figure 2 covers the same interval, showing the demand paging statistics from the Memory Object. These Counters report a corresponding rise in the page fault rate once Available Bytes drops to 4 MB. Cache Faults/sec represent read file operations that miss the cache and require accessing data from disk. This file cache activity apparently accounts for the expansion of the System Cache Resident Bytes depicted in Figure 1. Because there is contention for RAM among executing processes, the hard page fault rate also increases. The hard page fault rate charted here corresponds to the Page reads/sec Counter in the Memory Object. Together, Available Bytes hovering at 4 MB and a corresponding increase in the rate of hard page faults strongly suggests a situation where it would be useful to add more RAM. This example also illustrates the fact that the system file cache, which is part of the System address space working set, competes for memory on equal terms to other process working sets.
Figure 2. Demand paging rates can spike when the pool of Available Bytes is depleted.
Unfortunately, the relation between a memory shortage and the onset of demand paging illustrated here is usually not so clear-cut in many of the systems you will get a chance to observe. You also need to be aware that applications like MS SQL Server and Exchange running on Windows Server will grow their working sets dynamically to absorb any excess RAM that is available. It is not unusual to see systems running MS SQL Server or Exchange running at or near the 4 MB line without excessive paging. These applications also bypass the standard system file cache and buffer recently used database objects within their own memory-resident working sets. To diagnose shortage-of-memory conditions for these apps, it is necessary to look beyond the system level Memory statistics and examine their internal cache statistics.
Comments are closed.