Why Do Database Servers Use Huge Pages for TLB Pressure?

Database servers often configure huge pages because their large in-memory buffer pools require thousands of virtual-to-physical address translations, which quickly overwhelm the CPU's Translation Lookaside Buffer. By increasing the size of each memory page from the standard 4 kilobytes to 2 megabytes or 1 gigabyte, a single TLB entry can cover a much larger region of memory. This drastically reduces TLB misses, eliminates expensive hardware page table walks, and stabilizes query latency under heavy workloads.

Virtual Memory and the Translation Lookaside Buffer

In classical computing, operating systems use virtual memory to isolate processes and manage physical RAM. Memory is divided into fixed-size blocks called pages, typically \(4\text{ KB}\) on x86-64 architectures. When a database process accesses a memory address, the CPU must translate the virtual page number into a physical frame number using multi-level page tables stored in main memory.

Because reading page tables from RAM on every memory access would severely degrade performance, the CPU caches recent translations in a small, fast hardware cache called the Translation Lookaside Buffer (TLB). A TLB hit resolves the address in roughly a single clock cycle, whereas a TLB miss forces the hardware to perform a page table walk across multiple levels of memory.

Why Database Workloads Cause TLB Thrashing

Database management systems such as PostgreSQL, MySQL, and Oracle allocate massive shared memory regions—often tens or hundreds of gigabytes—for buffer pools, caches, and sort areas. With standard \(4\text{ KB}\) pages, a \(64\text{ GB}\) buffer pool requires:

\[\frac{64 \times 1024^3\text{ bytes}}{4096\text{ bytes/page}} = 16{,}777{,}216\text{ pages}\]

A typical modern CPU TLB holds only a few hundred to a few thousand entries. When a database executes random-access workloads across a large working set, the active pages far exceed the TLB capacity. This causes continuous TLB misses, known as TLB thrashing, where the CPU spends a significant fraction of its execution time walking four- or five-level page tables instead of processing queries.

How Huge Pages Increase TLB Reach

Huge pages expand the memory coverage of each TLB entry—a metric known as TLB reach. On x86-64 systems, standard huge pages are \(2\text{ MB}\) (or \(1\text{ GB}\) for gigantic pages). Using \(2\text{ MB}\) pages reduces the number of pages needed for a \(64\text{ GB}\) buffer pool by a factor of \(512\):

\[\frac{64 \times 1024^3\text{ bytes}}{2 \times 1024^2\text{ bytes/page}} = 32{,}768\text{ pages}\]

With \(2\text{ MB}\) pages, each TLB entry maps \(512\) times more memory than a \(4\text{ KB}\) entry. Even if the TLB has fewer dedicated entries for huge pages than for standard pages, the total TLB reach increases dramatically, keeping the majority of the database's hot working set cached in the TLB.

Additional Benefits for Database Servers

Beyond reducing TLB misses, huge pages offer two structural advantages for database servers:

• Smaller Page Tables: Fewer pages mean the operating system maintains much smaller page table structures, saving gigabytes of kernel memory on high-RAM servers with many concurrent database connections.
• Locked Memory Allocation: Explicit huge pages are typically pre-allocated and pinned in physical RAM, preventing the operating system from swapping the database buffer pool to disk and avoiding background memory compaction overhead.