Oracle Internals Notes

Paged Buffer Cache

A paged buffer cache uses the operating system's paging mechanism to manage its data buffers. The cache consists of memory pages and/or memory page clusters in the kernel's virtual address space that correspond to file system blocks. The cache is supported by a hash table and hash collision chains in kernel memory that can be used to locate file system blocks very quickly. When a process attempts to read a data block, the operating system performs the following two steps on its behalf.

Compute the hash value of the file system block required. Search the target hash chain in the buffer cache hash table. If a buffer for that file system block is not found, allocate a buffer in kernel virtual memory and update the buffer cache hash table accordingly. Return the kernel virtual address of the buffer.
Attempt to copy the data from the virtual cache buffer into user memory. If the data is not in physical memory, the virtual memory address translation for the cache buffer will generate a page fault, physical memory will be allocated from the page pool's free list and the file system block will then be read into that physical cache buffer. Once the data is in physical memory, then the copy into user memory can proceed.

With the exception of HP-UX, all of the major operating systems that are used to run Oracle use a paged buffer cache to buffer file system data. They typically also have a small wired buffer cache, but it is only used to buffer file system metadata, not user data.

The primary advantage of using a paged buffer cache is that it maximizes the use of the physical memory that you have paid for. Almost all spare physical memory is used for file system caching. Only a small amount of physical memory is left free to satisfy short term demands for free memory.

The primary disadvantage of using a paged buffer cache is that it can perform very poorly under intensive buffered I/O. Intensive buffered I/O can quickly exaggerate the apparent working set of cache buffers beyond the point at which it exceeds the size of the page pool less the working set of executable and anonymous pages. When this happens, the system may page frantically until the apparent memory deficit has been satisfied. System performance is seriously compromised during such paging storms, and they can be prolonged if the intensive I/O is sustained.

Most modern paged buffer cache implementations attempt to reduce the risk of I/O related paging storms by managing buffer cache pages on a separate page list that uses an LRU cache replacement policy instead of the inactivity based replacement policy that is used for the rest of the page pool. This allows bounds to be placed on the size of the file system cache, and permits several optimization to the paging algorithms that reduce the risk of paging storms. However, the risk cannot be entirely eliminated, not even with careful tuning, and the original intent of using a paged buffer cache - namely to maximize physical memory usage - is somewhat defeated.

For further operating system specific information, please see the follow these links: Solaris, AIX, Tru64 Unix.