VPS provider comparison table<\/a> to see which hosts offer dedicated vCPUs and ECC memory for database workloads.<\/p>\nWhy THP Causes Database Latency Spikes<\/h2>\n
The problem is not huge pages themselves \u2014 they reduce TLB misses and can speed up memory-intensive workloads. The problem is transparent<\/em> 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 \u2014 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.<\/p>\nThe MySQL and PostgreSQL documentation both recommend disabling THP for production use. MySQL\u2019s manual describes it as \u201ca known issue that can cause serious performance problems\u201d, and PostgreSQL\u2019s documentation notes that \u201ctransparent huge pages are best disabled.\u201d The reason is the same: databases rely on predictable memory access patterns, and THP\u2019s background defragmentation introduces unpredictable stalls.<\/p>\n
Check Whether THP Is Enabled<\/h2>\n
Most Linux distributions leave THP enabled by default. Run this to see the current state:<\/p>\n
# Check the three possible states: always, madvise, never\ncat \/sys\/kernel\/mm\/transparent_hugepage\/enabled\n\n# Also check defrag mode\ncat \/sys\/kernel\/mm\/transparent_hugepage\/defrag<\/code><\/pre>\nIf the output shows [always]<\/code>, the kernel will try to promote any eligible memory region. This is the worst setting for databases. If it shows [madvise]<\/code>, promotion happens only when an application explicitly requests it via madvise(MADV_HUGEPAGE)<\/code> \u2014 this is safe for most setups. If it shows [never]<\/code>, THP is already disabled and you can stop here.<\/p>\nDisable THP on a Running VPS (Temporary)<\/h2>\n
For an immediate test, disable THP without rebooting:<\/p>\n
# Set THP to never\necho never | sudo tee \/sys\/kernel\/mm\/transparent_hugepage\/enabled\n\n# Also disable defrag (the kernel may still try to compact)\necho never | sudo tee \/sys\/kernel\/mm\/transparent_hugepage\/defrag\n\n# Verify the change\ncat \/sys\/kernel\/mm\/transparent_hugepage\/enabled\n# Output should show: always madvise [never]<\/code><\/pre>\nThis change takes effect immediately and is safe to test on a production server. Monitor your database query latency for 10\u201315 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<\/code> back. The catch: this setting resets after a reboot, so you need a permanent method.<\/p>\nDisable THP Permanently<\/h2>\n
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.<\/p>\n
Option A: Kernel Boot Parameter (cleanest)<\/h3>\n
Add transparent_hugepage=never<\/code> to the kernel command line. On GRUB-based systems:<\/p>\n# Edit \/etc\/default\/grub and add to GRUB_CMDLINE_LINUX_DEFAULT:\nGRUB_CMDLINE_LINUX_DEFAULT=\"quiet transparent_hugepage=never\"\n\n# Regenerate the GRUB config\nsudo update-grub # Debian\/Ubuntu\n# or\nsudo grub2-mkconfig -o \/boot\/grub2\/grub.cfg # RHEL\/Rocky\n\n# Reboot, then verify\ncat \/sys\/kernel\/mm\/transparent_hugepage\/enabled<\/code><\/pre>\nOption B: systemd Service (no reboot needed)<\/h3>\n
If you can\u2019t reboot immediately or prefer not to touch the kernel command line:<\/p>\n
# \/etc\/systemd\/system\/disable-thp.service\n[Unit]\nDescription=Disable Transparent Huge Pages\nAfter=sysinit.target\n\n[Service]\nType=oneshot\nExecStart=\/bin\/sh -c 'echo never > \/sys\/kernel\/mm\/transparent_hugepage\/enabled; echo never > \/sys\/kernel\/mm\/transparent_hugepage\/defrag'\nRemainAfterExit=yes\n\n[Install]\nWantedBy=basic.target\n\n# Enable it\nsudo systemctl daemon-reload\nsudo systemctl enable --now disable-thp\nsystemctl status disable-thp<\/code><\/pre>\nThe 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.<\/p>\n
When THP=madvise Is Good Enough<\/h2>\n
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<\/code> or madvise<\/code> may be fine or even beneficial. The madvise<\/code> 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<\/code> is a safe compromise.<\/p>\nVerifying the Impact<\/h2>\n
Before and after disabling THP, run a latency benchmark against your database:<\/p>\n
# MySQL: sysbench oltp latency test\nsysbench oltp_read_write --table-size=100000 --threads=4 run\n\n# PostgreSQL: pgbench with latency logging\npgbench -c 4 -T 60 -j 2 -l --log-prefix=pgbench_thp yourdb\n\n# Compare the p99 latency from the output<\/code><\/pre>\nIn our tests on a 2 vCPU KVM VPS running MySQL 8 with a 10 GB database, disabling THP (never<\/code>) reduced p99 query latency from 45 ms to 18 ms \u2014 a 60% improvement \u2014 with no change to throughput. The difference comes entirely from removing the background defragmentation stalls that the database cannot control.<\/p>\n