As you've surfed the Web, you've probably seen browser pop-ups such as "Defragment your memory and improve performance" and "Minimize application and system failures and free unused memory." The links lead you to utilities that promise to do all that and more for a mere $9.95, $14.95, or $29.95. Sound too good to be true? It is. These utilities appear to do useful work, but at best, RAM optimizers have no effect, and at worst, they seriously degrade performance.
Literally dozens of so-called "memory optimizers" are available—some are commercial products and others are freeware. You might even be running such a product on your system. What do these products really do, and how do they try and fool you into thinking that they live up to their claims? Let's take a look inside memory optimizers to see exactly how they manipulate visible memory counters in Windows.
The Memory Optimizer UI
Memory optimizers typically present a UI that shows a graph labeled Available Memory and a line representing a threshold below which the product will take action. Another line typically shows the amount of memory that the optimizer will try to free when it runs. You can usually configure one or both levels, as well as trigger manual memory optimization or schedule optimizations. Some of the tools also display the processes running on the system.
When a scheduled optimization job runs, the utility's available-memory counter often goes up, sometimes dramatically, which appears to imply that the tool is actually freeing up memory for your applications to use. To understand how these utilities cause the available-memory line to rise, you first need to understand how Windows manages physical memory.
Windows Memory Management
Like most modern OSs, Windows implements a demand-paged virtual-memory system. An OS uses virtual memory to give applications the illusion that a computer has more physical memory than it actually does.
On 32-bit Windows systems, processes have a virtual-memory address space of 4GB that the OS typically divides equally between the process and the system. Thus, a process can allocate as much as 2GB of virtual memory, depending on the amount available. The total amount of virtual memory allocated to all processes can't exceed the sum of the system's paging files and most of its physical memory (the OS reserves a small portion of physical memory).
Given that processes can, with a large enough paging file, allocate virtual memory that exceeds the computer's physical memory capacity, the Windows Memory Manager subsystem must share physical memory among processes and the Cache Manager's cached file data. As Figure 1 illustrates, the Memory Manager assigns each process (e.g., Microsoft Word, Notepad, Windows Explorer) a part of physical memory, which is known as the process's working set. The portions of the kernel and drivers that are pageable, in addition to pageable kernel-memory buffers, called paged pool, and physical memory that the Cache Manager manages, are assigned their own working set, called the System working set.
The Memory Manager expands and contracts the System and processes' working sets in response to the needs of processes for quick access to their code and data. The computer's memory-management hardware requires that Windows manage working sets and virtual memory in page-size blocks. (On 32-bit x86 processors, pages are typically 4096 bytes in size. However, the OS and memory-intensive applications also use large pages of 4MB as an optimization, when possible.)
When a process accesses a page of its virtual memory that isn't present in its working set, the process incurs a page fault hardware exception. When that happens, the Memory Manager assigns a page of available physical memory to hold the newly accessed data. Additionally, the Memory Manager might decide to expand the process's working set by adding the page to the working set. However, if the Memory Manager deems the process's working set to be large enough, it will exchange a page already in the working set with the new page, choosing for replacement the page that the process accessed least recently, under the assumption that the process is least likely to access that page in the near future.
When the Memory Manager removes a page from a process working set, it must decide what to do with that page. If the page has been modified, the Memory Manager first puts it on the modified page list, a list of pages that eventually will be written to the paging file or to the memory-mapped files to which the pages correspond. From the modified page list, the Memory Manager moves pages to a pool called the standby list. Unmodified pages go directly to the standby list. Thus, you can view the standby list as a cache of file data.
Previous
Register
This statement might strike many computer users as ridiculous, but with explanation it makes sense. Mark's article touches on this concept but then buries it under technicalities. If my OS isn't using all its memory, it's not using my machine to full capacity. Yes, a small portion of memory must remain unallocated to give the system room to work in, but all the rest
of the memory should be used. I'm not referring to a situation such as running the system at near-maximum capacity and filling the entire virtual memory subsystem with a data set. I'm referring to modern, lightly loaded systems with large amounts of excess physical RAM that under usual circumstances will never be completely used. Ideally, the OS should use such excess RAM for caching, reallocating it only as needed. If the OS aggressively frees memory for some unknown future need, then data that the OS could have retrieved from RAM will instead require a disk read, incurring a massive performance penalty.<P>
I became aware of this counterintuitive concept when I began to use FreeBSD. I learned from a Usenet thread that near 100 percent memory usage is not only "normal" but indicative of a properly working system. Now, I measure an OS not only by how much memory it keeps free but also by how much it uses. I realize that the situation is a bit more complicated than I've described, but my point is that free memory is not your friend. You paid good money for your RAM. Do you really want it to be unused? <P>
I agree that an OS's job is to give memory to processes running on a system so that the processes can run efficiently and that this job requires using all physical memory. However, as I stated in my article, the Windows Memory Manager allocates memory by effectively using all "free" memory for cached file data, which the standby list stores. The Memory Manager uses this system to assign to certain processes only the memory they actually need so that other processes can get the memory that they actually need. One way the Memory Manager accomplishes this goal is by taking memory away from a process that doesn't need it and placing the unneeded memory on the standby list. If that process requests data from the standby list, it receives the data immediately; however, the memory demands of other processes might require that they also take memory from the standby list. The standby list serves as the file-system and paging-file cache, and even though memory on the list is considered "available," it's nevertheless actively used and therefore doesn't fit Henry's definition of free memory. <br>
--Mark Russinovich
Henry Mason January 23, 2004