Memory Management

As mentioned earlier, a database managing an enterprise business needs to run on a large Symmetrical Multiprocessing (SMP) server. Such a server is often equipped with a large amount of physical memory. Most of a system's memory is allocated to the database buffer cache area (referred to as the database buffers). Database buffers are used to cache table and index data pages read from disk into memory. Because disk access is slow compared to memory access, having more memory allocated for database buffers greatly improves database performance. A well-tuned database utilizes most of the available memory, leaving just enough for other running applications and the operating system. Allocating too much memory for a database deprives other applications of memory. Also, overallocating memory can result in excessive swapping, which is extremely detrimental to database performance.

How the Linux kernel manages physical memory is also important to the performance of a database server. On the IA-32 architecture, the kernel manages memory in 4KB pages. On the other hand, most modern processors can work with larger pages (up to multiple megabytes). For many applications, using 4KB pages is ideal. Small pages reduce internal fragmentation, incur a smaller overhead when swapping data in and out of memory, and ensure that the virtual memory that is in use is resident in physical memory. Most database servers use large shared-memory segments for their database buffers. The result is that a lot of page table entries (PTEs) are required. This adds a considerable maintenance overhead for the memory manager. For example, take a database server that allocates 1GB of shared memory for its buffers using 4MB shared memory segments. A kernel using a 4KB page size would require 262,144 PTEsa significant number of page tables, which adds considerable maintenance overhead for the memory manager. This calculation is, of course, oversimplified. The actual number of PTEs would be much larger because Linux is unable to share page tables for shared memory.

The capability of using larger pages is available in the 2.6 kernel. A process can explicitly request large pages from a memory pool. Using large pages reduces the number of PTEs required when an application requests large memory blocks. Consequently, the computational costs of maintaining the PTEs are also reduced. Going back to the previous example, if the page size is 4MB instead of 4KB, only 1,024 PTEs would be required for the 1GB database buffers (again, this calculation is oversimplified). Another advantage of large-page support is that large pages also increase the range of memory covered by the translation lookaside buffer (TLB), thus decreasing the possibility of TLB misses. TLB access is extremely fast compared to accessing a page table because the TLB is a CPU cache area.