Impact of Linux Page Size on Database Performance and Kubernetes Node Optimization

Linux Page Size

All modern multi‑user operating systems use virtual memory, and Linux x86‑64 manages it with paging. Linux supports 4 KB, 2 MB, and 1 GB page sizes, each representing the smallest unit of contiguous memory that can be mapped.

Smaller pages minimize waste for tiny allocations, while larger pages reduce the total number of pages needed for big allocations and improve translation speed because fewer page‑table walks are required.

TLB Cache Hits and Misses

Every memory access on Linux must translate a virtual address to a physical one. The CPU’s Translation Lookaside Buffer (TLB) caches recent translations; a hit is fast, while a miss triggers a page‑table walk in the kernel, which is considerably slower.

Why TLB Misses Matter for Databases

Databases constantly read and write memory, requiring at least one TLB lookup per operation. Larger rows or higher concurrency increase the number of distinct pages accessed, raising the likelihood of TLB misses and degrading performance.

When rows exceed 4 KB, a 4 KB page layout may need multiple TLB lookups per row, whereas a 2 MB or 1 GB page can often satisfy the same access with a single lookup.

Benchmarks

Benchmarks on an AMD EPYC 7J1C3 @ 2.55 GHz show that using 2 MB pages instead of 4 KB pages can increase throughput by up to 8× for narrow (128 B), medium (8 KB), and wider (16 KB) rows. The 1 GB page provides an additional 1‑21 % improvement over 2 MB pages, depending on row width.

Key results:

128 B rows on 4 KB pages achieve >3.5 M reads/s; 2 MB pages achieve ~8× higher throughput.

8 KB rows see an 8× boost with 2 MB pages.

16 KB rows see a 5× boost with 2 MB pages, and a modest further gain with 1 GB pages.

2 MB vs 1 GB Pages

Since all tested row sizes fit within a 2 MB page, the only variable is the TLB miss rate when using 1 GB pages. Across all widths, 1 GB pages deliver a modest 1‑21 % throughput increase over 2 MB pages.

Kubernetes Node Specialization

Historically, Kubernetes ran stateless web workloads that favored 4 KB pages. Modern clusters now host specialized workloads (e.g., machine learning, storage‑intensive services) where configuring nodes with huge pages can benefit stateful databases.

Node specialization can be expressed via pod‑node selectors and taints, allowing the scheduler to place database pods on nodes configured with 2 MB or 1 GB pages.

Configuring Huge Pages on Linux for Kubernetes

Huge pages are configured at the Linux kernel level, independent of Kubernetes. Transparent Huge Pages should usually be disabled for database workloads.

Enabling 2 MB pages is straightforward on most distributions; enabling 1 GB pages may require boot‑time kernel parameters and is supported on RHEL, Oracle Linux, CentOS, Ubuntu, and SUSE.

How Many Huge Pages to Allocate

The amount of huge page memory to reserve depends on the node’s RAM, the number of non‑database pods, and the database’s memory footprint. Proper sizing ensures the database can fully utilize the larger pages without starving other workloads.

Conclusion

Most popular databases see performance gains with huge pages on Linux x86‑64.

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

Specialized nodes can be provisioned with huge pages to optimize database workloads.

Configure the Linux kernel to use 2 MB or 1 GB pages and adjust pod resource requests/limits accordingly.

Select the appropriate mix of huge and regular pages based on the database’s row size and concurrency characteristics.