{"id":1159,"date":"2026-09-17T23:07:25","date_gmt":"2026-09-17T23:07:25","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1159"},"modified":"2026-09-17T23:07:25","modified_gmt":"2026-09-17T23:07:25","slug":"transparent-hugepages-ksm-vps-latency","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/transparent-hugepages-ksm-vps-latency\/","title":{"rendered":"Transparent Hugepages and Kernel Samepage Merging on a VPS: Latency Effects Measured"},"content":{"rendered":"\n
Two kernel memory features are enabled by default on most Linux distributions and quietly change latency characteristics in opposite directions. Transparent Hugepages (THP) reduces TLB misses by backing memory with 2 MB pages. Kernel Samepage Merging (KSM) deduplicates identical memory pages across processes to save RAM. On a VPS, both interact with virtualisation in ways that are worth measuring rather than assuming.<\/p>\n\n\n\n
Check What Your Kernel Is Actually Doing<\/h2>\n\n\n\n
Interpretation matters here. THP has three main states: always<\/code>, madvise<\/code>, and never<\/code>. KSM has a run<\/code> value of 0<\/code> (off), 1<\/code> (on and scanning), or 2<\/code> (on but not started until a process opts in via madvise<\/code>).<\/p>\n\n\n\n
Why THP Is a Latency Risk for Databases<\/h2>\n\n\n\n
THP’s benefit is fewer TLB misses for large, sequentially-accessed working sets. Its cost is allocation latency. When the kernel needs a 2 MB page and none is available, it attempts compaction of physical memory \u2014 and that compaction can stall the allocating process for milliseconds to tens of milliseconds.<\/p>\n\n\n\n
For a database with a latency-sensitive commit path, a multi-millisecond stall is worse than the TLB savings. This is why PostgreSQL, MySQL, and Redis documentation have all historically recommended madvise<\/code> or never<\/code> for THP:<\/p>\n\n\n\n
# Persistent setting via kernel boot parameters
# Add to GRUB_CMDLINE_LINUX_DEFAULT:
# transparent_hugepage=madvise
# Then: sudo update-grub && sudo reboot
# Runtime (non-persistent) for testing:
echo madvise | sudo tee \/sys\/kernel\/mm\/transparent_hugepage\/enabled
echo defer | sudo tee \/sys\/kernel\/mm\/transparent_hugepage\/defrag<\/code><\/pre>\n\n\n\n
Setting defrag<\/code> to defer<\/code> is the low-risk middle ground: pages are still merged opportunistically in the background, but no process is blocked waiting for compaction.<\/p>\n\n\n\n
KSM on a VPS: Deduplication That Costs CPU<\/h2>\n\n\n\n
KSM scans memory pages and merges those with identical content into a single copy-on-write page. On a host running many similar VMs, this can reclaim substantial RAM \u2014 which is why hosts sometimes enable it even when your guest has it disabled.<\/p>\n\n\n\n
The trade-off is CPU. The scanning daemon consumes cycles, and when a merged page is written, the guest takes a copy-on-write fault. Those faults are usually fast, but under memory pressure with thousands of merged pages, they add up.<\/p>\n\n\n\n
Measuring the Impact on Your Workload<\/h2>\n\n\n\n
Do not change these settings based on general advice. Measure your own server. A simple before\/after procedure:<\/p>\n\n\n\n
Record a baseline. Run your normal workload and capture latency percentiles \u2014 for a database, pgbench<\/code> or sysbench<\/code>; for a web app, request p95 and p99 from your access log.<\/li>
Check the current state and note it.<\/li>
Change one setting at a time. Toggle THP to madvise<\/code> first, re-run the benchmark, compare.<\/li>
Then toggle KSM and repeat. Do not change both at once or you cannot attribute the effect.<\/li>
Watch pages_sharing<\/code> after enabling KSM \u2014 if it stays near zero, the feature is costing CPU for no benefit on your workload.<\/li><\/ol>\n\n\n\n
For latency-sensitive databases, the common configuration is THP set to madvise<\/code> with defrag=defer<\/code>, and KSM left off in the guest unless memory pressure is demonstrable. For memory-constrained multi-tenant workloads \u2014 several small containers on one VPS \u2014 KSM enabled in the guest can reclaim real RAM at an acceptable CPU cost.<\/p>\n\n\n\n
Interaction With Virtualisation<\/h2>\n\n\n\n
Inside a KVM guest, the host decides whether to back your guest memory with hugepages at its own level. Your guest-level THP setting controls only what the guest kernel requests from the virtualised MMU. The host’s own THP policy can still introduce latency you cannot see from inside. This is one more reason to measure end-to-end response time rather than reasoning from guest settings alone. A host that enables aggressive host-level THP can produce latency spikes in your guest that no amount of guest-level tuning will remove, because you are seeing the effect of host memory compaction on the physical pages backing your VM.<\/p>\n\n\n\n
Detecting a Host-Level Stall<\/h2>\n\n\n\n
If your application shows periodic latency spikes that do not correlate with your own CPU, disk, or memory activity, check two things. First, whether the spikes align with a regular interval such as 30 or 60 seconds, which often indicates a periodic host operation. Second, whether steal<\/em> time in mpstat<\/code> rises at the same moments. If steal rises while your guest’s own CPU usage is flat, the stall originated outside your VM.<\/p>\n\n\n\n
You cannot fix a host-level policy from inside the guest, but you can prove it is happening and raise it with evidence. What you can control is your own configuration: monitor compact_stall<\/code> and compact_fail<\/code> counters in \/proc\/vmstat<\/code>. A rising compact_stall<\/code> count is direct evidence that allocation is blocking on memory compaction, which correlates closely with THP-induced latency.<\/p>\n\n\n\n
# Direct evidence of compaction-induced stalls
grep -E 'compact_stall|compact_fail|compact_success' \/proc\/vmstat
# Steal time while a latency spike is occurring
mpstat 1 20 | tail -20<\/code><\/pre>\n\n\n\n
If compact_stall<\/code> is climbing, the fix is the guest-side THP change to madvise<\/code> with defer<\/code>, which stops the kernel performing synchronous compaction in the allocation path. That single change removes the most common in-guest source of multi-millisecond pauses.<\/p>\n\n\n\n