Linux Memory Reclaim Tuning: PSI Metrics, zswap, and THP

Memory management in multi-tenant Linux environments requires a delicate balance between active application working sets, file-backed page caching, and swap reclamation. When systems experience memory contention, improper kernel settings often trigger aggressive kswapd CPU loops or catastrophic OOM-killer interventions. By leveraging Pressure Stall Information (PSI), zswap compressed in-memory pools, and Transparent HugePage tuning, operators can maximize workload density without compromising tail latency.

Traditional metrics like free memory or buffer percentages fail to measure actual degradation. A server with 98% memory utilization running active page caches may be completely healthy, while another with 20% free RAM might be choking on synchronous page allocation stalls. Pressure Stall Information solves this ambiguity by quantifying the exact percentage of wall-clock time CPU tasks spend waiting for memory pages.

Expand

Inspecting Memory Pressure with PSI

Linux exposes real-time hardware pressure metrics under the /proc/pressure directory. Inspecting /proc/pressure/memory provides 10-second, 60-second, and 300-second rolling averages for both some (tasks stalled on memory while at least one CPU core remained active) and full (all active tasks stalled simultaneously, indicating severe thrashing).

# Inspect real-time memory pressure stall figures
cat /proc/pressure/memory

# Sample output:
# some avg10=0.04 avg60=0.01 avg300=0.00 total=1429812
# full avg10=0.00 avg60=0.00 avg300=0.00 total=231804

When avg10 exceeds 10.0 on a production server, user requests are actively waiting for memory reclaim, signaling an immediate need to shed load or increase capacity.

Activating and Configuring zswap

zswap intercepts pages being evicted to swap space and compresses them inside a dedicated RAM pool using fast modern algorithms such as LZ4 or ZSTD. Because decompressing a 4KB page from RAM takes a fraction of a microsecond compared to physical disk access, zswap dramatically improves responsiveness under memory pressure.

# Verify current zswap kernel status
cat /sys/module/zswap/parameters/enabled

# Configure high-speed LZ4 compression and z3fold allocator
sudo sh -c 'echo 1 > /sys/module/zswap/parameters/enabled'
sudo sh -c 'echo lz4 > /sys/module/zswap/parameters/compressor'
sudo sh -c 'echo zsmalloc > /sys/module/zswap/parameters/zpool'
sudo sh -c 'echo 25 > /sys/module/zswap/parameters/max_pool_percent'

Setting max_pool_percent to 25 allows zswap to consume up to a quarter of physical memory as compressed swap before writing cold pages out to physical disk.

Tuning Transparent HugePages (THP)

Transparent HugePages reduce Translation Lookaside Buffer (TLB) misses by allocating memory in 2MB blocks rather than 4KB pages. However, setting THP to always causes kernel latency spikes when allocating memory under fragmentation. The recommended production standard for database and container hosts is madvise:

# Set Transparent HugePages to madvise mode
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

# Persist via sysctl and systemd-tmpfiles
echo "vm.swappiness = 60" | sudo tee /etc/sysctl.d/99-memory-tuning.conf
sudo sysctl -p /etc/sysctl.d/99-memory-tuning.conf

Deep Dive Video

Learn more about virtual memory architectures, paging hierarchies, and swap systems in this foundational overview:

Summary Takeaways

• Rely on PSI (/proc/pressure/memory) rather than free RAM to measure true memory exhaustion.
• Enable zswap with LZ4 compression to absorb transient memory spikes without disk I/O penalties.
• Keep THP in madvise mode to give memory-intensive applications like Redis and PostgreSQL hugepage benefits without global memory fragmentation.

Test your memory tuning configurations on high-frequency Intel Xeon Platinum VPS instances at netbayhosts.in.