How Large Linux Pages Can Boost Database Throughput on Kubernetes by Up to 8×

Linux Page Size and Database Performance

Most popular databases benefit from Linux huge pages. Using 2 MB or 1 GB pages instead of the default 4 KB can increase throughput dramatically because each memory access requires fewer TLB look‑ups.

Why TLB Cache Misses Matter for Databases

All modern OSes use virtual memory and paging. Every memory access (e.g., from MySQL, PostgreSQL, or any application) must translate a virtual address to a physical one. The CPU’s Translation Lookaside Buffer (TLB) caches recent translations. A TLB hit is fast; a miss forces a page‑table walk in the kernel, which is much slower.

Databases perform many memory accesses, so TLB misses become a major bottleneck, especially when rows are wide or concurrency is high.

Benchmark Overview

Benchmarks compared 4 KB, 2 MB, and 1 GB Linux pages on a single node (AMD EPYC 7J1C3 @ 2.55 GHz) with 128‑byte, 8 KB, and 16 KB rows. Results:

For 128‑byte rows, 2 MB pages delivered >3.5 M reads/s, an 8× improvement over 4 KB pages.

For 8 KB rows, 2 MB pages also gave an 8× throughput boost.

For 16 KB rows, 2 MB pages provided a 5× increase.

1 GB pages added a modest 1‑21 % gain over 2 MB pages, depending on row size.

Kubernetes Node Specialization

Historically, Kubernetes scheduled lightweight, stateless workloads (NGINX, Java, Node.js) where 4 KB pages were appropriate. Modern clusters run stateful, memory‑intensive databases, machine‑learning jobs, and storage‑heavy services. Nodes can be labeled and tainted so that pods requiring huge pages are scheduled onto nodes configured with 2 MB or 1 GB pages.

Configuring Huge Pages on Linux (Kubernetes‑Independent)

Huge pages are configured at the kernel level, not via Kubernetes. Disable Transparent Huge Pages (THP) to avoid memory waste. On x86_64, enabling 2 MB pages is straightforward on most distributions; 1 GB pages require boot‑time parameters and differ per distro (RHEL, Oracle Linux, CentOS, Ubuntu, SUSE, etc.).

Practical Recommendations

Identify the typical row width of your database; wider rows benefit more from huge pages.

Estimate the number of concurrent connections and the overall working set size.

Choose nodes with sufficient RAM to allocate the desired amount of 2 MB or 1 GB pages.

Set resource requests/limits for memory and huge‑page resources in pod specs.

Consider adding a dedicated “database‑optimized” node pool with huge‑page‑enabled kernels.

Conclusion

Most popular databases see performance gains from Linux huge pages.

Kubernetes supports 4 KB, 2 MB, and 1 GB pages, but many clusters still use 4 KB by default.

Specialized node pools can be used to run databases with 2 MB or 1 GB pages for up to an 8× throughput increase.

Configure huge pages at the OS level and expose them to pods via resource requests.