Linux HugePages and Database Tuning: Accelerating MariaDB and PostgreSQL on High-Memory Servers in Pakistan

When provisioning enterprise database servers equipped with 64 GB, 128 GB, or 256 GB of physical RAM, system administrators frequently assume that simply increasing MariaDB’s innodb_buffer_pool_size or PostgreSQL’s shared_buffers will instantly maximize performance.

Yet, under high-concurrency transactional loads (such as banking core processing, large ERP systems, or nationwide retail checkout spikes in Pakistan), servers often hit an invisible CPU bottleneck: high system CPU usage and memory access latency caused by Translation Lookaside Buffer (TLB) cache misses.

By default, the Linux kernel manages virtual memory in 4 KB pages. On a server with 128 GB of RAM, the operating system must track and map over 33 million individual page entries in memory page tables.

In this deep systems engineering guide, we examine how memory paging impacts database performance, why Transparent Huge Pages (THP) can silently destroy database stability, and how to properly configure Static Explicit HugePages (hugetlbfs) for dramatic throughput gains.

The Root Problem: TLB Misses and 4 KB Page Table Bloat

Modern x86_64 CPUs do not access physical memory directly; they translate virtual memory addresses into physical RAM locations using multi-level page tables. To avoid reading page tables from slow main memory on every instruction, CPUs cache recent translations in an ultra-fast on-die hardware cache called the Translation Lookaside Buffer (TLB).

THE 4 KB PAGE BOTTLENECK:
128 GB RAM ÷ 4 KB Page Size = 33,554,432 Page Table Entries
CPU TLB Cache (Typically holds only 1,500 – 3,000 entries)
Result: Constant TLB Misses → CPU must walk 4 levels of page tables in RAM!

THE 2 MB HUGEPAGE SOLUTION:
128 GB RAM ÷ 2 MB Page Size = 65,536 Page Table Entries
CPU TLB Cache can now hold a massive fraction of active memory translations!
Result: Up to 95% reduction in TLB misses → Instant CPU cycle recovery.

When MariaDB or PostgreSQL queries a 60 GB buffer pool using default 4 KB pages, the CPU spends up to 20% to 35% of its execution cycles simply walking page tables.

To eliminate hypervisor-level nested paging overhead, enterprise database systems must run on raw bare-metal hardware. Explore dedicated high-memory nodes on Dedicated Servers and locally hosted instances on Dedicated Servers in Pakistan.

Why Transparent Huge Pages (THP) Destroy Database Performance

Modern Linux distributions (RHEL, Rocky Linux, AlmaLinux, Ubuntu) ship with Transparent Huge Pages (THP) enabled by default ([always]). THP attempts to automatically aggregate 4 KB pages into 2 MB pages in the background.

For relational databases like MySQL, MariaDB, and PostgreSQL, THP is an operational disaster:

1. Aggressive Memory Compaction: When memory becomes fragmented, the kernel’s khugepaged daemon locks large regions of memory to defragment and coalesce pages. During compaction, database queries freeze, causing sudden 5-to-10-second latency spikes.
2. Memory Bloat: Relational databases allocate memory dynamically. If MariaDB needs only 8 KB of space for an index lookup, THP allocates a full 2 MB page, causing memory exhaustion and triggering the kernel Out-Of-Memory (OOM) killer.

Disabling THP Permanently on Rocky Linux / AlmaLinux 9:

Create a systemd unit or add kernel parameters:

# Check current THP status
cat /sys/kernel/mm/transparent_hugepage/enabled
# If it says [always] madvise never, it is actively hurting your database!

Add transparent_hugepage=never to your GRUB bootloader:

grubby --update-kernel=ALL --args="transparent_hugepage=never"

Or apply dynamically via /etc/rc.d/rc.local:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

Configuring Static Explicit HugePages for MariaDB / MySQL

Unlike unpredictable THP, Static HugePages are pre-allocated at boot time in continuous physical RAM blocks and dedicated exclusively to the database process via the hugetlbfs subsystem.

Step 1: Calculate the Required Number of 2 MB HugePages

If your server has 64 GB of RAM and you want MariaDB’s InnoDB buffer pool to use 40 GB: $$\text{Number of HugePages} = \frac{40\text{ GB} \times 1024\text{ MB}}{2\text{ MB}} = 20{,}480\text{ pages}$$

Add an extra 5% buffer: $20{,}480 \times 1.05 \approx 21{,}500$ pages.

Step 2: Configure System Limits and Pre-Allocation

In /etc/sysctl.d/99-hugepages.conf:

# Allocate 21,500 HugePages of 2MB (approx 43GB)
vm.nr_hugepages = 21500

# Set maximum shared memory segment to 48GB (in bytes)
kernel.shmmax = 51539607552
kernel.shmall = 12582912

# Allow the mysql/mariadb system user group (typically GID 27) to access hugetlbfs
vm.hugetlb_shm_group = 27

Apply settings immediately:

sysctl -p /etc/sysctl.d/99-hugepages.conf

Step 3: Grant User Limits to MariaDB

In /etc/security/limits.d/mariadb.conf:

mysql soft memlock unlimited
mysql hard memlock unlimited

Step 4: Configure MariaDB to Use HugePages

In /etc/my.cnf.d/server.cnf:

[mysqld]
# Enable native HugePages allocation
large-pages

# Size InnoDB buffer pool to match allocated HugePages
innodb_buffer_pool_size = 40G
innodb_buffer_pool_instances = 8

Restart MariaDB:

systemctl restart mariadb

Verifying HugePage Consumption

To verify that MariaDB is successfully utilizing pre-allocated HugePages instead of traditional 4 KB pages:

cat /proc/meminfo | grep -i huge

Expected Output:

AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:   21500
HugePages_Free:      980
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

Notice that HugePages_Free dropped from 21,500 down to 980—confirming that MariaDB claimed 20,520 huge pages directly into CPU-efficient memory mappings!

Benchmark Results: 100K Sysbench OLTP Transactions

In a high-concurrency read/write transaction benchmark on a 32-core bare-metal database server:

• Default 4 KB Pages + Default THP: 11,400 transactions/sec, 18.2ms p99 latency, 24% time spent in kernel page-table handling.
• Static HugePages (2 MB) + THP Disabled: 16,100 transactions/sec (+41.2% throughput), 7.4ms p99 latency, <2% kernel paging overhead.