How Large Linux Pages Boost Database Performance on Kubernetes

This article examines the impact of Linux page size on database performance and how to optimize database workloads on Kubernetes nodes.

Most popular databases benefit from large Linux pages.

Kubernetes was originally designed for large‑scale orchestration of lightweight, stateless applications where the default 4 KB Linux page size is appropriate. Recent enhancements such as StatefulSets, Persistent Volumes, and support for hugepages enable Kubernetes to run stateful, persistent databases efficiently.

Benchmarks show that using Linux 2 MB pages instead of 4 KB can increase database throughput up to eight‑fold, and the benefit grows with higher concurrency.

All modern multi‑user operating systems use virtual memory, and Linux x86‑64 manages it with paging. Linux supports three page sizes:

4 KB

2 MB

1 GB

Page size is the smallest unit of contiguous memory that can be mapped. Smaller pages reduce internal fragmentation for tiny allocations, while larger pages reduce the total number of pages needed for big allocations and speed up address translation because fewer TLB entries are required.

Each memory access must translate a virtual address to a physical address. CPUs cache recent translations in a Translation Lookaside Buffer (TLB). A TLB hit is fast; a miss forces a page‑table walk in the kernel, which is considerably slower even though the walk is implemented in efficient C code.

TLB misses become more significant for databases because every row read or write requires at least one TLB lookup. Wider rows (e.g., variable‑length strings, JSON, CLOB, BLOB) increase the number of distinct pages accessed, leading to more TLB misses. Likewise, higher concurrency raises the lookup rate.

Wider rows increase the number of TLB lookups.

Higher concurrency increases lookups per unit time.

Benchmark configurations:

Narrow rows (128 B) fitting within a single 4 KB page.

Medium rows (8 KB) spanning at least two 4 KB pages.

Wide rows (16 KB) spanning at least four 4 KB pages.

All tests used a pre‑warmed database of 100 million rows that fit entirely in DRAM, accessed via IPC rather than TCP, eliminating disk I/O and network overhead.

Results:

2 MB pages deliver up to 8× higher throughput for narrow and medium rows compared to 4 KB pages.

For wide rows, 2 MB pages provide about 5× higher throughput.

1 GB pages offer a modest 1‑21 % improvement over 2 MB pages across all row sizes.

Kubernetes node specialization allows different node types (e.g., GPU‑enabled, high‑memory, ARM) to be labeled and scheduled via pod selectors, enabling dedicated nodes for database workloads.

To optimize databases on Kubernetes you can control:

Linux kernel page size (4 KB, 2 MB, or 1 GB) on the host.

The number of hugepages allocated (2 MB or 1 GB).

Memory and hugepage requests/limits in pod specs.

Treat the database as a regular Kubernetes application.

Configuring 2 MB pages is straightforward on most Linux distributions and usually does not require kernel boot‑parameter changes. Configuring 1 GB pages varies by distro and typically needs boot‑time parameters. Supported distributions include RHEL 7/8, Oracle Linux 7/8, CentOS 7/8, Ubuntu 18.04/20.04, and SUSE 12/15.

When deciding how many hugepages to allocate, consider the node’s total RAM, the number of non‑database pods sharing the node, and the expected memory benefit for the database.

In summary:

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

Kubernetes supports 4 KB, 2 MB, and 1 GB pages.

Historically many clusters use 4 KB pages, but dedicated nodes with hugepages can dramatically improve DB throughput.

Configure the Linux kernel for 2 MB or 1 GB pages, disable transparent hugepages, and request the appropriate hugepage resources in pod specifications.