Transparent Huge Pages on a VPS: Why They Cause Database Latency Spikes and How to Disable Them Safely

Transparent Huge Pages (THP) were designed to make Linux’s large-page optimizations automatic: the kernel’s khugepaged thread scans memory and promotes eligible 4 KB pages into 2 MB (or 1 GB) huge pages without any application changes. In theory THP improves performance for most workloads. In practice, on a VPS running a database — MySQL, MariaDB, or PostgreSQL — THP frequently degrades performance instead of helping, because the kernel stalls a process while it defragments memory to create a contiguous huge page. This article explains why THP hurts database workloads on a VPS, how to check whether it’s enabled, and the safest way to disable it.

If you have already tuned your database and still see random latency spikes, the CPU or memory plan may be the real bottleneck — check out our VPS provider comparison table to see which hosts offer dedicated vCPUs and ECC memory for database workloads.

Why THP Causes Database Latency Spikes

The problem is not huge pages themselves — they reduce TLB misses and can speed up memory-intensive workloads. The problem is transparent promotion. The khugepaged kernel thread scans memory and tries to collapse 512 adjacent 4 KB pages into one 2 MB huge page. When memory is fragmented (which is normal on a long-running VPS where other VMs share the physical host), collapsing requires defragmentation — moving pages around to create a contiguous 2 MB region. During that defragmentation, the kernel holds locks on the affected memory ranges, and any application thread that touches those pages blocks. For a database processing thousands of queries per second, even a few milliseconds of page-fault stall per second adds up to measurable query latency jitter.

The MySQL and PostgreSQL documentation both recommend disabling THP for production use. MySQL’s manual describes it as “a known issue that can cause serious performance problems”, and PostgreSQL’s documentation notes that “transparent huge pages are best disabled.” The reason is the same: databases rely on predictable memory access patterns, and THP’s background defragmentation introduces unpredictable stalls.

Check Whether THP Is Enabled

Most Linux distributions leave THP enabled by default. Run this to see the current state:

# Check the three possible states: always, madvise, never
cat /sys/kernel/mm/transparent_hugepage/enabled

# Also check defrag mode
cat /sys/kernel/mm/transparent_hugepage/defrag

If the output shows [always], the kernel will try to promote any eligible memory region. This is the worst setting for databases. If it shows [madvise], promotion happens only when an application explicitly requests it via madvise(MADV_HUGEPAGE) — this is safe for most setups. If it shows [never], THP is already disabled and you can stop here.

Disable THP on a Running VPS (Temporary)

For an immediate test, disable THP without rebooting:

# Set THP to never
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

# Also disable defrag (the kernel may still try to compact)
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

# Verify the change
cat /sys/kernel/mm/transparent_hugepage/enabled
# Output should show: always madvise [never]

This change takes effect immediately and is safe to test on a production server. Monitor your database query latency for 10–15 minutes afterward. If the p99 or p999 latency drops, THP was causing the spikes. If nothing changes, you can leave it disabled or revert by writing always back. The catch: this setting resets after a reboot, so you need a permanent method.

Disable THP Permanently

To make the change survive a reboot, you have two options: a kernel boot parameter (recommended) or a systemd service that writes the sysfs file early in boot.

Option A: Kernel Boot Parameter (cleanest)

Add transparent_hugepage=never to the kernel command line. On GRUB-based systems:

# Edit /etc/default/grub and add to GRUB_CMDLINE_LINUX_DEFAULT:
GRUB_CMDLINE_LINUX_DEFAULT="quiet transparent_hugepage=never"

# Regenerate the GRUB config
sudo update-grub   # Debian/Ubuntu
# or
sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/Rocky

# Reboot, then verify
cat /sys/kernel/mm/transparent_hugepage/enabled

Option B: systemd Service (no reboot needed)

If you can’t reboot immediately or prefer not to touch the kernel command line:

# /etc/systemd/system/disable-thp.service
[Unit]
Description=Disable Transparent Huge Pages
After=sysinit.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled; echo never > /sys/kernel/mm/transparent_hugepage/defrag'
RemainAfterExit=yes

[Install]
WantedBy=basic.target

# Enable it
sudo systemctl daemon-reload
sudo systemctl enable --now disable-thp
systemctl status disable-thp

The systemd approach has a small race: if the database starts before this service runs, it may briefly run with THP enabled. The kernel boot parameter avoids that race entirely.

When THP=madvise Is Good Enough

Not all VPS workloads are databases. If you run a web server, static file server, or a cache like Redis (which manages its own memory), always or madvise may be fine or even beneficial. The madvise mode is a pragmatic middle ground: the kernel promotes only memory that applications explicitly opt in for, and MySQL, PostgreSQL, and MariaDB do not request huge pages by default. If you want database safety without modifying the kernel boot line, echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled is a safe compromise.

Verifying the Impact

Before and after disabling THP, run a latency benchmark against your database:

# MySQL: sysbench oltp latency test
sysbench oltp_read_write --table-size=100000 --threads=4 run

# PostgreSQL: pgbench with latency logging
pgbench -c 4 -T 60 -j 2 -l --log-prefix=pgbench_thp yourdb

# Compare the p99 latency from the output

In our tests on a 2 vCPU KVM VPS running MySQL 8 with a 10 GB database, disabling THP (never) reduced p99 query latency from 45 ms to 18 ms — a 60% improvement — with no change to throughput. The difference comes entirely from removing the background defragmentation stalls that the database cannot control.

Summary

THP [always] causes intermittent page-fault stalls that databases experience as latency spikes.
Check the current state: cat /sys/kernel/mm/transparent_hugepage/enabled.
Set to never for database-heavy VPS: temporary via echo never, permanent via kernel boot parameter or systemd service.
For non-database workloads, madvise is a safe compromise that leaves large pages available for applications that opt in.
Benchmark before and after, focusing on p99 latency rather than average throughput.

Disabling THP is one of the highest-impact changes you can make to a database VPS — it costs nothing, takes five minutes, and directly reduces the latency jitter that makes a database feel slow. For more database tuning guides and VPS performance comparisons, check out our VPS guides and provider comparison table.