The Automatic Approach — and Its Hidden Cost
Linux developers recognized that HugePages delivered real performance gains but required manual configuration that most administrators would never do. Their solution was Transparent HugePages (THP) — a kernel feature that automatically promotes standard 4KB pages into 2MB HugePages without any application changes.
How THP works mechanically: A kernel thread called khugepaged runs continuously in the background, scanning process memory. When it finds 512 consecutive 4KB pages belonging to the same process that are all present in RAM and aligned correctly, it attempts to collapse them into a single 2MB HugePage. This collapse requires briefly locking the affected memory region, copying data, and updating page table entries. The application is paused during this operation.
THP's mode is controlled through a virtual file at /sys/kernel/mm/transparent_hugepage/enabled, which reports the active mode in brackets among the three available options and can be written to switch modes.
The three modes:
| Mode | Behavior |
|---|---|
always |
THP enabled for all processes. khugepaged runs aggressively. |
madvise |
THP only for memory regions where the application calls madvise(MADV_HUGEPAGE). |
never |
THP completely disabled. Only explicit HugePages work. |
Why THP causes latency spikes: The collapse operation is not free. It requires CPU time, memory bandwidth, and — critically — a brief lock on the affected pages. For a single-threaded application like Redis, any lock on its memory means the entire server stalls. This produces the characteristic pattern: latency is normally 1ms, but every few minutes it spikes to 50–200ms as khugepaged collapses memory in the background. The spikes are periodic, unpredictable, and difficult to diagnose without knowing to look for THP.
There is also a fragmentation problem: THP requires 512 contiguous 4KB pages. On a server that has been running for days, physical memory becomes fragmented. khugepaged may trigger memory compaction — moving pages around in RAM to create contiguous blocks — which is even more disruptive than the collapse itself.
The industry consensus: For latency-sensitive applications (Redis, Memcached, Kafka, real-time trading systems), disable THP entirely. For batch workloads where occasional pauses are acceptable, madvise mode is a reasonable compromise. The always mode is rarely the right choice for production databases.
A common SRE interview scenario: "Your Redis cluster shows periodic latency spikes every few minutes. CPU and network look normal. What do you check?" The answer that separates senior candidates: check cat /sys/kernel/mm/transparent_hugepage/enabled and look for khugepaged in top. THP is the most common cause of this exact pattern. Follow up: "How do you make the fix permanent?" — add echo never > /sys/kernel/mm/transparent_hugepage/enabled to /etc/rc.local or a systemd unit, since the /sys filesystem resets on reboot.