Optimizing Huge Pages for Proxmox/KVM: Real-World Database Performance Tuning

When 4KB Becomes a Bottleneck at 2 AM

It happened at 2 AM while I was wrestling with a Redis and PostgreSQL cluster on Proxmox. Despite plenty of free RAM and low CPU load, the application reported unusually high latency. The system felt “sluggish” even though the hardware was high-end. After digging in with perf and /proc/meminfo, I discovered the main culprit: excessively high TLB (Translation Lookaside Buffer) misses.

By default, Linux manages memory in 4KB pages. For a 32GB RAM virtual machine, the system has to handle over 8 million pages. Every time the CPU needs data, it must look up this massive page table. When the table exceeds the cache (TLB) capacity, the CPU is forced to access RAM repeatedly just to… find where the data is. Huge Pages were created to eliminate this waste by increasing page size to 2MB or 1GB.

My homelab currently runs 12 VMs and containers. This is where I test everything before pushing to production. Real-world experience shows that with heavy workloads like databases, you’re wasting 10-15% of CPU performance just on memory management if you’re not using Huge Pages.

Three Memory Management Methods: Which One to Choose?

1. Standard Pages (4KB) – Familiar but Taxing

This is the default configuration, very flexible for small processes. However, for VMs with tens of gigabytes of RAM, it becomes a burden because the sheer number of pages causes the CPU to struggle during lookups.

2. Transparent Huge Pages (THP) – Convenient but Risky

Linux automatically aggregates 4KB pages into 2MB when needed. It sounds great, but in production, it often causes sudden “lag.” The khugepaged process can block I/O while scanning and defragmenting pages. Oracle and Redis experts always recommend disabling this feature first.

3. Static Huge Pages – Slow and Steady

This is my preferred choice. We statically allocate a fixed amount of RAM for Huge Pages at boot time. This RAM is “reserved” entirely and cannot be swapped out. This method provides the highest and most stable performance for KVM virtualization.

Pros and Cons to Consider

• Pros:
  • Significantly reduces TLB misses. The CPU focuses on processing logic instead of searching tables.
  • Memory is pinned to physical RAM. It’s never pushed to Swap, ensuring extremely low latency.
  • The kernel is less burdened because the page tables are significantly smaller.
• Cons:
  • RAM allocated for Huge Pages is “gone for good.” If a VM doesn’t use it all, other processes cannot borrow it.
  • Requires a host reboot for the configuration to take effect stably and avoid memory fragmentation.
  • Disables RAM Ballooning (automatic VM memory scaling).

Why I Choose Static Huge Pages for Proxmox?

If you’re running small-scale hosting, RAM Ballooning is a lifesaver for overcommitting resources. But for enterprise databases, stability is the top priority. I’m willing to trade flexibility to ensure Redis never stutters due to page faults. On a server with 128GB RAM, I usually dedicate 64GB-80GB specifically for Huge Pages.

Detailed Implementation Guide

The following steps will help you configure 2MB Huge Pages—the most common and easiest type to deploy today.

Step 1: Check Hardware Information

First, confirm that your CPU supports Huge Pages using the following command:

grep -i hugepages /proc/meminfo

Step 2: Configure Kernel Parameters

We will modify Grub to allocate RAM right at boot. For example: allocating 20GB of RAM for Huge Pages (2MB type), which is equivalent to 10240 pages.

nano /etc/default/grub

Add the parameters to the GRUB_CMDLINE_LINUX_DEFAULT line:

# Allocate 10240 2MB pages = 20GB
GRUB_CMDLINE_LINUX_DEFAULT="quiet default_hugepagesz=2M hugepagesz=2M hugepages=10240"

Update grub and reboot the server:

update-grub
reboot

Step 3: Verify the Results

After the system is up, run this command to see if the RAM has been “reserved”:

grep Huge /proc/meminfo

The HugePages_Free metric should be approximately the 10240 you just configured.

Step 4: Apply to Virtual Machines (VMs)

Now, tell Proxmox to allocate RAM for the VM from the Huge Pages pool instead of regular RAM.

Use the CLI for speed:

# Replace 100 with your VM ID
qm set 100 -hugepages 2

Important note: You must completely shut down the VM and start it again (Power Cycle) for the configuration to take effect.

Step 5: Final Confirmation

While the VM is running, check the host again:

grep HugePages_Free /proc/meminfo

If Free decreases by exactly the VM’s RAM capacity, congratulations. Your system is now “flying” on high-speed memory.

A Few Real-World Notes

For extremely large VMs (over 64GB RAM), 1GB Huge Pages (hugepagesz=1G) will yield better results. However, it requires slightly stricter hardware support.

Additionally, VM snapshots that include RAM might encounter errors on some older QEMU versions when using Huge Pages. Always thoroughly test your backup procedures after infrastructure changes.

System optimization isn’t magic; it’s about understanding how the kernel and hardware operate. I hope this late-night experience helps you optimize your systems more smoothly!