PostgreSQL Performance Halved on Linux Kernel 6.8: The THP Bug Every DBA Needs to Know [2026 Guide]

PostgreSQL Performance Halved on Linux Kernel 6.8: The THP Bug Every DBA Needs to Know [2026 Guide]

Transparent Huge Pages (THP) is a Linux kernel feature that automatically groups standard 4KB memory pages into 2MB huge pages to reduce translation lookaside buffer (TLB) misses. On Linux Kernel 6.8 — the default kernel in Ubuntu 24.04 LTS and Fedora 40 — changes to THP's allocation aggressiveness have introduced a silent PostgreSQL performance regression that can halve throughput in write-heavy OLTP workloads. If you upgraded your OS in the last year and noticed unexplained PostgreSQL slowdowns, THP is almost certainly the cause.

Key takeaways:

• Linux Kernel 6.8 introduced multi-size THP and more aggressive khugepaged compaction that directly conflicts with PostgreSQL's multi-process memory access patterns, causing 20–50% throughput loss in write-heavy workloads.
• THP (harmful to PostgreSQL) and explicit huge pages via vm.nr_hugepages (beneficial for PostgreSQL shared_buffers) are two completely different features. You need to disable one and enable the other.
• The fix is two commands: set THP to madvise and configure vm.nr_hugepages for your shared memory size. But if you don't persist it with a systemd unit, your next reboot silently re-enables THP.
• Ubuntu 24.04 LTS ships Kernel 6.8 by default and will be the dominant production Ubuntu through 2029, making this a multi-year concern for every PostgreSQL deployment on that platform.
• Managed cloud databases like AWS RDS and Google Cloud SQL handle THP settings internally, but self-managed PostgreSQL on EC2, GCE, or Kubernetes pods inherits the host node's THP configuration silently.

Disable THP, enable explicit huge pages. They sound like the same thing. They're opposites.

→ Related: Transparent Huge Pages + Postgres: Stop P99 Latency Cliffs [2026]

What Are Transparent Huge Pages (THP) and How Do They Work?

Modern Linux systems manage memory in 4KB pages. Every time a process accesses memory, the CPU uses a Translation Lookaside Buffer (TLB) to translate virtual addresses to physical ones. The TLB is small — typically 512 to 2048 entries — so workloads with large memory footprints constantly suffer TLB misses, which are expensive.

Huge pages solve this by mapping memory in 2MB chunks instead of 4KB ones. A single TLB entry now covers 512x more memory. For applications with large, contiguous memory regions, that's a massive win.

THP takes this further by making huge page allocation automatic. Instead of requiring administrators to pre-allocate huge pages with vm.nr_hugepages, THP lets the kernel promote regular 4KB pages into 2MB huge pages transparently. A background daemon called khugepaged scans process memory regions and merges eligible 4KB pages into huge pages.

The problem: "transparent" means "without the application's knowledge or consent." PostgreSQL really doesn't want this happening to its memory.

PostgreSQL's official documentation explicitly warns: THP "has been known to cause performance degradation with PostgreSQL for some users on some Linux versions, so its use is currently discouraged." That's the PostgreSQL Global Development Group being diplomatic about a feature that has burned DBAs for years.

What Changed in Linux Kernel 6.8 That Affects PostgreSQL Performance?

Linux Kernel 6.8, released in March 2024, introduced multi-size transparent huge pages (mTHP) for anonymous memory. This isn't a small tweak. It's a significant architectural change to how THP works.

Before Kernel 6.8, THP operated in a fairly binary fashion: the kernel would try to allocate 2MB huge pages for anonymous memory mappings, or fall back to 4KB pages. The khugepaged daemon would periodically scan for opportunities to collapse 4KB pages into 2MB pages, but its behavior was predictable enough.

Kernel 6.8 changed this in three ways that matter:

1. Multi-size page support: The kernel can now allocate anonymous pages at sizes between 4KB and 2MB (16KB, 32KB, 64KB, etc.). THP promotion happens more frequently and at more granular levels. More promotion events means more compaction overhead.
2. Aggressive page fault behavior: Anonymous page faults can now directly allocate multi-size huge pages, rather than always starting at 4KB and waiting for khugepaged to promote later. This shoves compaction cost into the hot path of page allocation.
3. Ramped-up `khugepaged` activity: The daemon scans and compacts more aggressively to take advantage of multi-size page support. On systems with fragmented memory — which describes every busy PostgreSQL server — this generates more compaction stalls.

The result: PostgreSQL backends experience more frequent pauses while khugepaged reorganizes their memory pages. These pauses show up as latency spikes, particularly at p99, and aggregate throughput drops of 20–50% in benchmarks comparing identical PostgreSQL workloads on Kernel 6.5 versus 6.8. The effect is worst on write-heavy OLTP workloads with high connection counts and large shared_buffers allocations. That's the profile of basically every production database.

If your symptoms look more like intermittent P99 “latency cliffs” than steady slowdown, I dug into the stall mechanics and what to measure in Transparent Huge Pages + Postgres: Stop P99 Latency Cliffs [2026]. It complements the kernel-6.8 changes above with a more metrics-first way to confirm THP-induced compaction pauses.

Ubuntu 24.04 LTS ships Kernel 6.8 by default and was released in April 2024. As I covered in my Ubuntu 24.04 developer review, the toolchain improvements are real, but this THP regression is the kind of silent footgun that makes OS upgrades dangerous for database servers. Ubuntu 24.04 is projected to be the dominant production LTS through 2029. This problem isn't going away.

Linux Huge Pages vs. Transparent Huge Pages: A Critical Distinction for PostgreSQL

This is where most articles get it wrong, and where most DBAs get confused. There are two completely separate huge page mechanisms in Linux. They have opposite effects on PostgreSQL:

The confusion comes from the PostgreSQL parameter huge_pages controlling only explicit huge pages for the shared memory segment. It has zero effect on THP behavior. THP is controlled entirely at the OS kernel level.

Here's why THP is specifically harmful to PostgreSQL: PostgreSQL uses a multi-process architecture, not multi-threaded. Each client connection spawns a separate backend process with its own virtual address space. These processes access memory in small, non-contiguous patterns — reading a row here, writing a WAL record there. THP's bulk page promotion is designed for applications that access large contiguous memory regions sequentially. When khugepaged tries to merge PostgreSQL backend pages, it forces compaction on memory regions that PostgreSQL accesses in scattered, random patterns. This is like reorganizing a library's card catalog while 200 librarians are actively pulling books.

Explicit huge pages, on the other hand, apply only to the pre-allocated shared memory segment (shared_buffers), which PostgreSQL accesses via mmap. That's a single large, contiguous region that genuinely benefits from reduced TLB overhead.

If you're curious about how different database architectures handle memory, my comparison of PostgreSQL vs MySQL covers the architectural differences that make PostgreSQL particularly sensitive to OS-level memory behavior. Similarly, ClickHouse vs PostgreSQL for analytics shows how columnar engines have entirely different memory access patterns.

How to Diagnose the THP Performance Problem in PostgreSQL

Before applying fixes, confirm that THP is actually what's hurting you. Here's the diagnostic checklist:

1. Check current THP status:

Run cat /sys/kernel/mm/transparent_hugepage/enabled. If you see [always] highlighted, THP is active and promoting pages system-wide. You want [madvise] or [never].

2. Check kernel version:

Run uname -r. If you're on 6.8 or later, the mTHP changes are active. This includes any Ubuntu 24.04 installation, Fedora 40+, and other distros that shipped Kernel 6.8+.

3. Check `khugepaged` compaction activity:

Look at /proc/vmstat for THP-related counters. The key metrics are thp_collapse_alloc (successful huge page promotions), thp_collapse_alloc_failed (failed attempts that still cost CPU), and thp_fault_alloc (huge pages allocated on page faults). If these counters are climbing rapidly — hundreds or thousands per minute — khugepaged is actively interfering with your workload.

4. Check for compaction stalls:

Run grep compact /proc/vmstat. Look at compact_stall — this counts the number of times a process was stalled waiting for memory compaction. On a healthy PostgreSQL server with THP disabled, this should be near zero. On an affected server, you'll see it climbing steadily.

5. Check PostgreSQL's huge_pages_status:

In PostgreSQL 14+, run SHOW huge_pages_status;. This tells you whether PostgreSQL successfully obtained explicit huge pages for its shared memory. Values are on (using huge pages), off (not using them), or unknown. This is independent of THP — it only reports on explicit huge page usage.

6. Monitor with `vmstat`:

Run vmstat 1 during your workload. Watch the wa (I/O wait) and sy (system CPU) columns. Excessive khugepaged activity shows up as elevated system CPU time that doesn't correlate with your query load.

The smoking gun: high system CPU, climbing compact_stall counters, thp_collapse_alloc in the hundreds per minute, and THP set to [always]. If you see all four, THP is your culprit.

Step-by-Step Fix: Disabling THP and Enabling Explicit Huge Pages for PostgreSQL

The fix has two parts that work in opposite directions. You're disabling automatic THP (harmful) while enabling explicit huge pages (beneficial).

Part 1: Disable THP system-wide

Set THP to madvise mode, which means the kernel will only use THP when applications explicitly request it via the madvise() system call. PostgreSQL never calls madvise() for THP, so this effectively disables THP for PostgreSQL while leaving it available for applications that genuinely benefit (like some JVM workloads).

Run: echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

Also disable the defragmentation behavior: echo defer+madvise > /sys/kernel/mm/transparent_hugepage/defrag

Part 2: Configure explicit huge pages for PostgreSQL's shared memory

Calculate how many 2MB huge pages PostgreSQL needs. The formula: divide your shared_buffers value by 2MB, then add a small buffer (about 5–10%). For example, if shared_buffers = 8GB, that's 8192MB / 2MB = 4096 pages. Add 10% for overhead: 4506 pages.

Set this in sysctl: sysctl -w vm.nr_hugepages=4506

Verify the allocation worked: grep HugePages /proc/meminfo. You should see HugePages_Total matching your setting and HugePages_Free close to the total (before PostgreSQL starts).

Part 3: Configure PostgreSQL to use explicit huge pages

In postgresql.conf, set huge_pages = try (this is actually the default since PostgreSQL 11, but verify it). With try, PostgreSQL will attempt to use the explicit huge pages you allocated, and fall back gracefully if they're unavailable. Setting huge_pages = on is stricter — PostgreSQL will refuse to start if huge pages aren't available.

Restart PostgreSQL and verify with SHOW huge_pages_status; — it should report on.

Making the Fix Persistent Across Reboots (systemd Method)

This is where most guides leave you hanging. The /sys/kernel/mm/transparent_hugepage/enabled file resets to always on every reboot. If you apply the fix in a running session but don't persist it, your next kernel update or routine reboot silently re-enables THP and your performance regresses with zero warning.

You need two things: a systemd service for THP settings, and a sysctl entry for vm.nr_hugepages.

Persist THP settings with a systemd service:

Create a file at /etc/systemd/system/disable-thp.service with a [Service] section that runs ExecStart commands to write madvise to the THP enabled file and defer+madvise to the defrag file. Set Type=oneshot and RemainAfterExit=yes, with a [Install] section targeting WantedBy=multi-user.target.

Enable it: systemctl daemon-reload && systemctl enable disable-thp.service

Persist `vm.nr_hugepages` via sysctl:

Add vm.nr_hugepages = 4506 (substituting your calculated value) to /etc/sysctl.d/99-postgresql-hugepages.conf. This survives reboots and kernel upgrades.

Verify after reboot:

Reboot, then check: cat /sys/kernel/mm/transparent_hugepage/enabled should show [madvise]. grep HugePages /proc/meminfo should show your allocated pages. SHOW huge_pages_status; in PostgreSQL should return on.

I learned this persistence lesson running this site's infrastructure. When I built the 7-agent publishing pipeline that runs kunalganglani.com, a slug rewrite on live URLs burned 907K impressions of link equity because a one-time fix wasn't persisted through the system's next deploy cycle. The pattern is universal: if a fix isn't codified in a config file or service that survives restarts, it doesn't exist.

PostgreSQL Configuration: The huge_pages Parameter Explained

PostgreSQL's huge_pages parameter has three values, and understanding when to use each matters:

`huge_pages = try` (default since PostgreSQL 11): PostgreSQL attempts to allocate shared memory using explicit huge pages. If the kernel doesn't have enough huge pages available (because vm.nr_hugepages is too low or not set), PostgreSQL falls back to regular 4KB pages silently. This is the safe default and what most production deployments should use.

`huge_pages = on`: PostgreSQL requires explicit huge pages. If they're not available, PostgreSQL refuses to start. Use this in production environments where you've configured vm.nr_hugepages correctly and want to guarantee huge page usage. A startup failure is preferable to running with degraded performance and not knowing it.

`huge_pages = off`: PostgreSQL never uses explicit huge pages. As postgresqlco.nf contributors note, this may be appropriate for small systems with less than 2GB of RAM where the overhead of huge page management exceeds the TLB miss savings.

There's also huge_pages_size (added in PostgreSQL 15), which lets you specify the huge page size if your kernel supports multiple sizes (1GB pages on some architectures). For most deployments, the default 2MB is correct.

The critical point: huge_pages = try does not protect you from THP. The huge_pages parameter controls only PostgreSQL's explicit request for huge pages from the pre-allocated pool. THP operates at the kernel level and affects all processes regardless of PostgreSQL's configuration. You have to fix both sides.

For more on how database parameter tuning interacts with infrastructure decisions, the comparison of pgvector vs Pinecone covers how PostgreSQL's memory configuration affects vector database workloads specifically. And if you're evaluating managed alternatives like Neon vs Supabase, know that managed platforms handle THP settings for you.

Impact on Cloud and Container Environments (AWS, GCP, Kubernetes)

The cloud story here has three very different scenarios, and people keep conflating them.

Managed PostgreSQL services (AWS RDS, Aurora, Google Cloud SQL, Azure Database for PostgreSQL): These services manage the underlying OS, including kernel parameters. AWS RDS and Aurora run on Amazon Linux with tuned kernel settings. THP is typically set to madvise or never on managed database instances. If you're on a fully managed service, you're probably fine. But verify with your provider if you're seeing unexplained latency spikes after a platform update.

Self-managed PostgreSQL on cloud VMs (EC2, GCE, Azure VMs): You own the OS. If you launched an Ubuntu 24.04 instance, you're running Kernel 6.8 with THP set to always by default. Every fix in this guide applies directly. This is the most common scenario where DBAs get burned — they upgrade their AMI or VM image, don't realize the kernel changed THP behavior, and spend weeks blaming PostgreSQL for a problem the OS created.

[Kubernetes](/glossary/kubernetes) and container environments: This is the trickiest case. THP settings on the host node apply to all containers running on that node, including PostgreSQL pods. You cannot change THP settings from inside a container — it requires host-level access. If your Kubernetes cluster runs on Ubuntu 24.04 nodes, every PostgreSQL pod on those nodes inherits the always THP setting.

The fix for Kubernetes requires either:

• Configuring THP settings in your node provisioning (user data scripts, Ansible playbooks, or cloud-init for your node groups)
• Using a DaemonSet that runs a privileged init container to set THP to madvise on each node
• Using a Kubernetes operator that handles node tuning (like the Node Tuning Operator in OpenShift)

A PostgreSQL instance that benchmarks beautifully on a tuned staging server can perform 50% worse in production if the production nodes have different THP defaults. The OS is not neutral ground.

For more on how host-level configurations silently affect containerized workloads, my post on eBPF monitoring replacing sidecars covers the broader pattern of host-kernel features impacting container behavior.

Before and After: What Performance Improvement to Expect

How much performance you recover depends on your workload profile, connection count, and shared_buffers size. Here's what benchmarks from the database performance engineering community show:

Write-heavy OLTP (pgbench, 80% writes, 200 connections):

• Before fix (THP=always, no explicit huge pages): ~45,000 TPS
• After fix (THP=madvise, explicit huge pages enabled): ~78,000 TPS
• Improvement: 73% throughput recovery, p99 latency dropped from 42ms to 18ms

Mixed read-write (60/40 read/write, 100 connections):

• Before: ~62,000 TPS
• After: ~81,000 TPS
• Improvement: 30% throughput recovery, p99 improved from 28ms to 14ms

Read-heavy OLAP (analytical queries, 16 connections):

• Before: ~8,200 QPS
• After: ~9,100 QPS
• Improvement: 11% throughput recovery — less dramatic because read-heavy workloads generate fewer page faults and less khugepaged activity

The pattern is clear: the more writes you do and the more connections you have, the worse THP hurts you. Makes sense. Writes generate more page faults, and more connections mean more backend processes for khugepaged to interfere with.

PostgreSQL 17 (released September 2024) and the upcoming PostgreSQL 18 (beta released June 2026) both run on Kernel 6.8+ by default on current LTS distributions. Neither release changes anything about how PostgreSQL interacts with THP. This remains an OS-level concern that PostgreSQL doesn't and can't mitigate internally.

Checklist: Verify Your PostgreSQL THP and Huge Pages Configuration

Run through this on every PostgreSQL server, especially after OS upgrades:

1. THP status: cat /sys/kernel/mm/transparent_hugepage/enabled → should show [madvise] or [never]
2. THP defrag: cat /sys/kernel/mm/transparent_hugepage/defrag → should show [defer+madvise] or [never]
3. Kernel version: uname -r → note if 6.8+ (mTHP is active)
4. Huge pages allocated: grep HugePages /proc/meminfo → HugePages_Total should match your vm.nr_hugepages setting
5. Huge pages in use: HugePages_Free should be lower than HugePages_Total when PostgreSQL is running (the difference is what PostgreSQL is using)
6. PostgreSQL config: SHOW huge_pages; → should return try or on
7. PostgreSQL status: SHOW huge_pages_status; → should return on
8. Persistence — THP: systemctl status disable-thp.service → should show active (exited)
9. Persistence — sysctl: grep nr_hugepages /etc/sysctl.d/* → should show your configured value
10. Compaction activity: grep compact_stall /proc/vmstat → should be stable (not climbing) under load

If any item fails, the fix isn't complete. Step 8 is the one most DBAs miss. It's the one that bites you three months later after a routine reboot.

For teams managing PostgreSQL backups alongside performance tuning, my pgBackRest vs Barman vs WAL-G comparison covers the backup tooling side of PostgreSQL operations. And if you're running local AI workloads alongside PostgreSQL on the same host, THP settings affect both — another reason to get this right at the OS level.

What Is khugepaged and Why Does It Affect PostgreSQL?

khugepaged is a kernel daemon that runs continuously in the background, scanning process memory regions for opportunities to collapse 4KB pages into huge pages. It's the workhorse behind THP's "transparent" promise.

The problem is timing. khugepaged doesn't coordinate with PostgreSQL. It can kick off a compaction event — physically moving and merging memory pages — while a PostgreSQL backend is in the middle of a critical operation. During compaction, the affected memory pages are locked. Any PostgreSQL backend trying to access those pages stalls until compaction completes.

On Kernel 6.8, khugepaged is more aggressive because the mTHP infrastructure gives it more opportunities. It's not just looking for 512 contiguous 4KB pages to merge into a 2MB page anymore. It can now merge smaller groups (8 pages into a 32KB page, 16 into a 64KB page, etc.). More merge opportunities means more merge attempts. More merge attempts means more compaction stalls.

This is particularly toxic for PostgreSQL's architecture. Each PostgreSQL backend is a separate process that fork()s from the postmaster. After forking, each backend has its own copy-on-write memory pages. khugepaged sees hundreds of processes with similar memory layouts and aggressively tries to promote their pages. That's exactly the wrong optimization for a workload where each backend accesses different rows, indexes, and buffer pool pages.

The Percona Engineering Team has published extensive analysis showing that khugepaged compaction activity correlates directly with PostgreSQL latency spikes, particularly at the p99 and p999 percentiles. Their engineers found that disabling THP reduced p99 latency by 40–60% in their PostgreSQL test environments.

The Boring Fix That Changes Everything

Here's the uncomfortable truth: this issue has been known for years. The PostgreSQL Global Development Group has warned about THP since the PostgreSQL 9.x era. What Kernel 6.8 did was take a known problem and make it significantly worse through mTHP, while simultaneously shipping that kernel as the default on the most popular Linux distribution in production.

The fix takes about 10 minutes. Two sysctl entries, one systemd service, one PostgreSQL parameter check. It's not exciting. It won't make for a great conference talk. But it will recover 20–50% of your throughput on every PostgreSQL server running Kernel 6.8+.

If you're running PostgreSQL on Ubuntu 24.04, Fedora 40+, or any distro with Kernel 6.8, check your THP settings today. Not tomorrow. Today. Because the longer you run with THP set to always, the more query latency you're silently eating. And when PostgreSQL 18 ships later this year and everyone upgrades, the DBAs who already fixed this will wonder what the fuss is about — while everyone else discovers that their shiny new database version is mysteriously slower than the one it replaced.

This is one of those things where the boring answer is actually the right one. Disable THP. Enable explicit huge pages. Persist it. Move on.

Photo by Gabriel Heinzer on Unsplash.