The process stalls while the OS compacts memory to build huge pages or reclaims memory to free it up.
Why Free memory runs low, or transparent huge pages (THP) trigger memory compaction → Effect The thread that asked for memory waits until reclaim or compaction finishes → On screen Irregular server stalls (a few ms to hundreds of ms)
Primary owner Infra team (Server infrastructure) · Also Game team (Server development)
Game team action items
Cut down large memory allocations at runtime (allocate up front at startup and reuse).
Infra team action items
Configure huge pages (THP) so only regions that ask for them use them (madvise), raise the free-memory threshold (vm.min_free_kbytes and so on).
On the graph
Random spikes · Server tick time, memory PSI
Where to look
some and full in /proc/pressure/memory (share of time stalled waiting for memory) and the increase in compact_stall from /proc/vmstat, alongside server tick time; the /sys/kernel/mm/transparent_hugepage/defrag setting
Confirmed if
Memory PSI rises and compact_stall increases when ticks spike. defrag is set to always
Ruled out if
PSI and compact_stall unchanged: not this cause. Swap usage rising: “Swap”
Check with
Infra tools (no game code needed)
Sources
Transparent Hugepage SupportLinux kernel With defrag=always, a failed THP allocation reclaims and compacts memory on the spot and stalls; with madvise, only regions that asked for it do
Documentation for /proc/sys/vm/Linux kernel min_free_kbytes: the minimum free memory (watermark) the kernel keeps in reserve
PSI - Pressure Stall InformationLinux kernel some (share of time some tasks stalled waiting for memory) and full (share of time all tasks stalled) in /proc/pressure/memory