Troubleshooting Linux 'kswapd0 High CPU & Direct Reclaim Latency Spikes': Complete Memory Watermark Runbook

Under sustained high-concurrency workloads—such as high-throughput WooCommerce checkouts, Redis session backends, Elasticsearch cluster ingest, and dense PHP-FPM or Nginx web server clusters—Linux systems frequently exhibit a sudden and crippling failure mode. Without warning, userland processes hang for hundreds of milliseconds, Time to First Byte (TTFB) spikes from 25ms to several seconds, HTTP 504 Gateway Timeouts cascade across edge proxies, and top displays kernel thread kswapd0 pinning a CPU core at 100% utilization.

System administrators often assume the machine has run completely out of physical memory. Yet running free -m reveals gigabytes of memory labeled as cached, swap usage may be minimal, and the Out-of-Memory (OOM) killer never engages.

The real culprit is not absolute memory starvation. It is Direct Reclaim Catastrophe precipitated by kernel memory zone watermark breaches. When the velocity of memory allocations outstrips the asynchronous clearing speed of kswapd0, incoming memory allocation requests drop down into the synchronous slowpath. Application worker threads are halted in their tracks to scan LRU lists, compact fragmented memory blocks, and synchronously flush dirty file-backed pages to block storage.

This exhaustive engineering runbook unpacks the virtual memory management (VMM) architecture of the Linux kernel, diagnoses the five core root causes behind kswapd0 thrashing and direct reclaim latency, and provides a production-grade sysctl blueprint to eliminate synchronous reclaim stalls forever.

---

1. Internal Mechanics of Linux Kernel Page Reclaim

To remediate reclaim stalls, you must understand how the Linux kernel categorizes physical RAM and governs memory reclamation.

Physical Memory Zones

The kernel divides physical memory into distinct zones based on hardware addressing constraints and architectural boundaries:

1. ZONE_DMA (First 16 MB): Retained for legacy ISA hardware devices incapable of 32-bit addressing.
2. ZONE_DMA32 (16 MB to 4 GB): Allocated for legacy 32-bit PCI devices on 64-bit platforms.
3. ZONE_NORMAL (4 GB through Total Physical RAM): The primary working memory zone on 64-bit systems where the kernel, user processes, slab caches, and page caches reside.
4. ZONE_MOVABLE: An optional pseudo-zone configured for memory hotplugging and defragmentation.

Each memory node in a NUMA (Non-Uniform Memory Access) architecture maintains its own set of these zones. Every individual zone independently tracks its own free pages, active lists, inactive lists, and reclaim watermarks.

The Three Kernel Watermarks: WMARK_MIN, WMARK_LOW, and WMARK_HIGH

Within every memory zone, the kernel calculates three critical memory thresholds known as watermarks:

[ Maximum Zone Memory Capacity ]
               |
               |  Normal Operation (Zone is healthy, no reclaim)
               v
  ===========================  <-- WMARK_HIGH (kswapd0 sleeps / stops reclaim)
               |
               |  Zone Under Pressure (kswapd0 wakes up in background)
               v
  ===========================  <-- WMARK_LOW  (kswapd0 woken up asynchronously)
               |
               |  CRITICAL DANGER ZONE (Direct Reclaim Slowpath)
               v
  ===========================  <-- WMARK_MIN  (alloc_pages_slowpath invoked)
               |
               |  Reserved for Kernel-Atomic Allocations (GFP_ATOMIC)
  ===========================  <-- 0 Free Pages (OOM Killer threshold)

• WMARK_MIN: Computed directly from the global sysctl parameter vm.min_free_kbytes. It defines the absolute floor below which standard userland allocations cannot proceed. Pages below WMARK_MIN are strictly reserved for critical, non-blocking kernel allocations (such as network packet interrupts using GFP_ATOMIC).
• WMARK_LOW: The activation threshold for background reclaim. Historically calculated as WMARK_MIN + (WMARK_MIN / 4). When userland allocations consume memory such that free pages in a zone drop below WMARK_LOW, the kernel wakes the background reclaim thread: kswapd0 (or kswapdN for NUMA node N).
• WMARK_HIGH: The deactivation threshold. Historically calculated as WMARK_MIN + (WMARK_MIN / 2). Once kswapd0 frees enough inactive cache pages or swaps anonymous memory to raise the zone’s free memory back above WMARK_HIGH, kswapd0 transitions back to sleep.

---

2. The Direct Reclaim Catastrophe: alloc_pages_slowpath

Under normal operating conditions, background asynchronous reclaim is invisible. When an application process allocates memory via brk() or mmap(), the kernel’s fast path (get_page_from_freelist) checks if free pages exceed WMARK_LOW. If they dip below WMARK_LOW, the kernel fires an asynchronous wake-up interrupt to kswapd0, delivers the requested free page to the application thread instantly, and allows userland execution to proceed without delay.

kswapd0 then works quietly in the background, scanning the inactive LRU (Least Recently Used) list, unmapping clean page cache entries, and pushing pages out until free RAM ascends past WMARK_HIGH.

The Failure Cascade

Problems occur when the allocation velocity of the workload outpaces the rate at which kswapd0 can scan and free pages.

Consider an e-commerce flash sale: hundreds of PHP-FPM workers spawn simultaneously, each allocating 32 MB of heap space to handle JSON payloads, database responses, and image transformations. If the gap between WMARK_LOW and WMARK_MIN is narrow (as is common on default Linux distributions), free memory crashes through WMARK_MIN before kswapd0 can evict a sufficient number of pages.

Once free memory breaches WMARK_MIN, the kernel fastpath aborts. The kernel shifts the allocating process into alloc_pages_slowpath:

1. Synchronous Execution Hijack: The allocating thread (e.g., a MySQL worker servicing an active transaction or an Nginx worker terminating an SSL handshake) is forced to perform page reclaim directly on its own CPU core.
2. LRU Spinlock Contention: Dozens or hundreds of worker threads enter shrink_inactive_list and isolate_lru_pages simultaneously. They fight over the zone’s LRU locks, driving CPU kernel system time (%sy) to near 100%.
3. Synchronous Storage Flushes: If the inactive page cache contains dirty pages, the direct reclaim thread must issue synchronous writeback I/O requests to the storage subsystem to flush file buffers before the physical frame can be repurposed.
4. Catastrophic Latency Spikes: The userland process is frozen in uninterruptible sleep (D state) for 50ms, 200ms, or even several seconds. Upstream load balancers encounter timeouts, Redis queries drop out of SLA, and web servers return HTTP 504 Gateway Timeout errors.

---

3. The 5 Core Root Causes of kswapd0 Thrashing & Direct Reclaim Stalls

Field diagnostics across production Linux enterprise clusters highlight five recurring architectural triggers:

Cause 1: Undersized min_free_kbytes and Narrow Watermark Gaps

By default, the Linux kernel sets vm.min_free_kbytes based on a conservative heuristic rooted in older hardware standards: 4 * sqrt(total_memory_kbytes). On a 64 GB RAM server, default min_free_kbytes often hovers around 67 MB (67,584 KB). On a 128 GB server, it may default to roughly 90 MB.

Furthermore, the default vm.watermark_scale_factor is 10 (representing 0.1% of the zone size). This creates an extraordinarily narrow buffer between WMARK_MIN and WMARK_LOW—often less than 50 MB to 100 MB.

When a multi-threaded database or web application requests 500 MB of allocations over a burst window of 10 milliseconds, that tiny 100 MB buffer is annihilated instantly. kswapd0 does not have time to complete a single scan cycle before every worker thread is pushed into direct reclaim.

Cause 2: NUMA Node Memory Imbalance (zone_reclaim_mode)

On modern multi-socket enterprise servers, physical RAM is split across NUMA nodes linked to specific CPU sockets:

[ Socket 0: 32 Cores ] <==== UPI Interconnect ====> [ Socket 1: 32 Cores ]
          |                                                    |
[ NUMA Node 0: 128 GB RAM ]                          [ NUMA Node 1: 128 GB RAM ]
(Running MySQL: 127 GB allocated)                   (Idle Services: 8 GB allocated)
Free: 250 MB -> kswapd0 thrashing!                  Free: 120 GB -> Completely unused!

If vm.zone_reclaim_mode is set to 1 (or non-zero), the kernel enforces strict local node allocation. When MySQL runs primarily on Node 0 and exhausts Node 0’s free memory, the kernel will aggressively run direct reclaim and purge local page caches—causing massive stalls—even though Node 1 has over 100 GB of free, untouched RAM.

Cause 3: High vm.swappiness on Rotational or Virtualized Storage

The vm.swappiness parameter controls the ratio of anonymous memory (process heap/stack) reclaim versus file-backed page cache reclaim:

$$\text{ratio} = \frac{\text{reclaim anonymous memory}}{\text{reclaim file-backed memory}}$$

A default vm.swappiness = 60 instructs the kernel to scan anonymous pages aggressively. In virtualized cloud environments or nodes backed by high-latency SAN/NAS storage, writing anonymous pages out to swap space incurs massive I/O wait. As kswapd0 struggles to push dirty pages into swap, its scan queues clog, causing both kswapd0 CPU saturation and direct reclaim stalls for running tasks.

Cause 4: Slab Cache Inode and Dentry Bloat (vfs_cache_pressure)

Workloads that touch massive directory structures—such as cPanel shared hosting servers holding millions of maildir files, large Git repositories, or WordPress installations processing thousands of media uploads—consume substantial kernel memory for directory entries (dentries) and inode objects inside the slab allocator.

If vm.vfs_cache_pressure is kept too low (e.g., default 100 or lower during heavy file traversal), the kernel prioritizes reclaiming page cache pages rather than freeing reusable dentry and inode slab objects. The kernel exhausts unstructured physical pages while holding gigabytes of unevictable metadata structures. When free pages drop below watermarks, kswapd0 burns 100% CPU scanning lists of locked slab objects.

Cause 5: Transparent Huge Pages (THP) Defrag Compaction Stalls

Transparent Huge Pages (THP) group standard 4 KB pages into 2 MB continuous memory blocks. However, when physical memory becomes fragmented over weeks of uptime, allocating a contiguous 2 MB page fails.

If /sys/kernel/mm/transparent_hugepage/defrag is set to always, any allocation requiring a huge page triggers synchronous page compaction (compact_zone) directly within the allocating thread. The process is paused while the kernel shuffles physical 4 KB pages across memory to stitch together a continuous 2 MB block. This introduces latency spikes reaching 500ms to 2,000ms.

---

4. Diagnostic Procedures & Kernel Telemetry

Never guess when dealing with kernel virtual memory. Use these diagnostic workflows to confirm whether memory watermarks, direct reclaim, or compaction are impacting your systems.

Step 1: Real-Time Zone Watermark Status via /proc/zoneinfo

Inspect the exact watermark numbers for your active memory zones:

cat /proc/zoneinfo | awk '
  /^Node/ {node=$2}
  /^Node.*zone/ {zone=$4}
  /pages free/ {free=$3}
  /min/ {min=$2}
  /low/ {low=$2}
  /high/ {high=$2}
  /spanned/ {
    printf "Node %s Zone %-8s | Free: %-8d | Min: %-8d | Low: %-8d | High: %-8d\n", node, zone, free, min, low, high
  }'

Expected output on a healthy 64 GB host:

Node 0 Zone DMA32    | Free: 12480    | Min: 2156     | Low: 4312     | High: 6468    
Node 0 Zone Normal   | Free: 2451920  | Min: 65536    | Low: 131072   | High: 196608  

If Free is hovering between Min and Low, kswapd0 is actively engaged. If Free is equal to or less than Min, user processes are actively stalling in direct reclaim.

Step 2: Measuring Cumulative Direct Reclaim Stalls vs Background Steals

Use sar -B (from the sysstat package) to quantify page scanning behavior in real time:

sar -B 1 10

Sample telemetry during a Direct Reclaim crisis:

14:10:01 AM  pgscank/s  pgscand/s  pgsteal/s  %vmeff
14:10:02 AM    1240.00   84200.00    2410.00    2.82
14:10:03 AM     890.00  112450.00    1850.00    1.63
14:10:04 AM    1420.00   96700.00    3100.00    3.16

Diagnostic Metrics Breakdown:

• pgscank/s: Pages scanned per second by the background kernel thread kswapd0.
• pgscand/s: Pages scanned per second by Direct Reclaim (user processes). In a healthy, properly tuned system, this metric should remain 0.00. Any sustained positive value confirms that application worker threads are being hijacked to reclaim memory synchronously.
• %vmeff: Virtual memory efficiency, measured as (pgsteal / pgscan) * 100. A value below 20–30% indicates that the kernel is scanning hundreds of thousands of pages while struggling to find freeable frames—a textbook indicator of memory thrashing.

To extract cumulative counters from /proc/vmstat:

cat /proc/vmstat | grep -E 'pgscan|pgsteal|compact|allocstall'

Watch for:

• allocstall_normal / allocstall_movable: Increments every single time an application is blocked in direct reclaim.
• compact_stall: Increments when processes are blocked waiting for memory compaction (THP defragmentation).

Step 3: Identifying Stalled Processes and Kernel Callstacks

To catch the specific processes trapped in memory reclaim, run pidstat:

pidstat -r -d 1 5

Check the system CPU utilization and page fault rates. If processes display high system time without significant user computation, trace the kernel functions consuming CPU cycles using perf:

perf top -F 99

If your system is trapped in direct reclaim, perf top will show the CPU bound to these kernel symbols:

• shrink_inactive_list
• isolate_lru_pages
• compact_zone / compaction_alloc
• native_queued_spin_lock_slowpath (lock contention across LRU lists)

To capture the backtrace of an application thread frozen in direct reclaim:

cat /proc/<PID>/stack

Sample call trace showing direct reclaim stall:

[<0>] alloc_pages_slowpath+0x3ef/0xd80
[<0>] __alloc_pages_nodemask+0x2c6/0x310
[<0>] alloc_pages_vma+0x88/0x1e0
[<0>] do_anonymous_page+0x10b/0x3a0
[<0>] handle_mm_fault+0xa6c/0x12a0
[<0>] do_user_addr_fault+0x1e8/0x460
[<0>] exc_page_fault+0x6b/0x150

Step 4: Inspecting NUMA Topology and Node Skew

Verify whether memory allocation is balanced across physical sockets:

numactl --hardware
numastat -m

Look closely at the node_reclaim and other_node statistics. If one node shows zero free memory while another possesses dozens of gigabytes, NUMA allocation affinity is suffocating workloads on the saturated socket.

---

5. Actionable Remediation Runbook

Follow this systematic tuning sequence to eliminate kswapd0 thrashing and protect application threads from synchronous direct reclaim.

Step 1: Size vm.min_free_kbytes Correctly

The default vm.min_free_kbytes is dangerously low for modern multi-gigabyte production workloads. Sizing this parameter to 1% to 3% of total physical RAM establishes an adequate reserve buffer for atomic kernel operations and network buffers.

Total Host RAM	Default min_free_kbytes	Recommended min_free_kbytes
16 GB	~45 MB (45,056 KB)	262,144 KB (256 MB)
32 GB	~64 MB (65,536 KB)	524,288 KB (512 MB)
64 GB	~90 MB (90,112 KB)	1,048,576 KB (1 GB)
128 GB	~128 MB (131,072 KB)	2,097,152 KB (2 GB)
256 GB+	~180 MB (184,320 KB)	4,194,304 KB (4 GB)

Important: Do not set min_free_kbytes higher than 5% of total RAM, as excessively large reservations permanently lock physical RAM away from user applications and filesystem caches.

Step 2: Expand the Watermark Gap with watermark_scale_factor

Introduced in Linux kernel 4.6, vm.watermark_scale_factor is the single most effective tool for preventing direct reclaim.

The parameter sets the distance between WMARK_MIN, WMARK_LOW, and WMARK_HIGH as a percentage of the total zone size (in units of 10,000, where 10 = 0.1%, and 200 = 2.0%).

Gap Calculation:
Watermark Gap = Zone Size * (vm.watermark_scale_factor / 10000)

Setting vm.watermark_scale_factor = 200 widens the gap to 2.0% of each memory zone.

Why this resolves the problem: With a wider buffer between WMARK_MIN and WMARK_LOW, kswapd0 wakes up much earlier—when substantial free memory still remains. It begins scanning and clearing pages in the background long before high-velocity allocation bursts can deplete free memory down to WMARK_MIN. Direct reclaim is avoided entirely.

Step 3: Disable Aggressive NUMA Zone Reclaim

Ensure that processes can allocate memory from any NUMA node rather than stalling to reclaim local pages:

sysctl -w vm.zone_reclaim_mode=0

Setting vm.zone_reclaim_mode = 0 allows the kernel to satisfy allocation requests from adjacent NUMA nodes over the CPU interconnect, completely bypassing local eviction loops.

Step 4: Calibrate vm.swappiness and vfs_cache_pressure

For enterprise web clusters and relational database servers (MariaDB/MySQL, PostgreSQL):

• Set vm.swappiness = 10 (or 1): Prevents the kernel from swapping out active process heaps to disk, preserving physical RAM for transactional threads.
• Set vm.vfs_cache_pressure = 100: Maintains a balanced reclamation pace between directory/inode slab caches and the file page cache. (On dedicated database systems with stable working sets, lowering this to 50 helps retain index caches in RAM).

Step 5: Prevent THP Compaction Stalls

Transparent Huge Pages frequently trigger severe synchronous allocation stalls under fragmented conditions. To eliminate defragmentation pauses without completely disabling huge pages for databases that benefit from them, change the defrag mode to madvise or defer+madvise:

echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

By setting this to madvise, only processes that explicitly request memory defragmentation via madvise(..., MADV_HUGEPAGE) will incur compaction delays. Unaware userland processes (like Nginx and PHP-FPM) will instantly fall back to standard 4 KB pages without blocking.

To make this persistent across reboots, apply it via a systemd-tmpfiles configuration or a system startup service:

cat << 'EOF' > /etc/tmpfiles.d/transparent-hugepage.conf
w /sys/kernel/mm/transparent_hugepage/defrag - - - - madvise
EOF

Step 6: Deploy Production /etc/sysctl.d/99-memory-tuning.conf

Consolidate these settings into a persistent sysctl configuration file tailored for high-concurrency 64 GB – 128 GB Linux servers:

# /etc/sysctl.d/99-memory-tuning.conf
# Nextgen Systems Engineering: Kernel Page Reclaim & Watermark Optimization

# 1. Expand the minimum free memory reserve (1 GB for a 64GB host)
vm.min_free_kbytes = 1048576

# 2. Widen the watermark buffer to 2% of total zone capacity
# Allows kswapd0 to wake up early and prevent direct reclaim stalls
vm.watermark_scale_factor = 200

# 3. Disable local NUMA zone reclaim to allow cross-node memory allocation
vm.zone_reclaim_mode = 0

# 4. Limit aggressive swapping of anonymous process memory
vm.swappiness = 10

# 5. Maintain balanced inode and dentry slab cache reclamation
vm.vfs_cache_pressure = 100

# 6. Ensure dirty pages are flushed smoothly before writeback buffers fill
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Apply the changes immediately without rebooting:

sysctl --system

---

6. Real-World Diagnostic Verification Script

To continuously monitor your memory watermarks and detect direct reclaim spikes before they trigger client-facing timeouts, deploy this diagnostic shell script:

#!/usr/bin/env bash
# /usr/local/bin/check-memory-reclaim.sh
# Diagnostic monitor for kswapd0 thrashing and direct reclaim stalls

set -euo pipefail

echo "=========================================================="
echo " Linux Memory Watermark & Reclaim Diagnostic Audit"
echo "=========================================================="

# Check current sysctl values
MIN_FREE=$(sysctl -n vm.min_free_kbytes)
SCALE_FACTOR=$(sysctl -n vm.watermark_scale_factor)
SWAPPINESS=$(sysctl -n vm.swappiness)
NUMA_RECLAIM=$(sysctl -n vm.zone_reclaim_mode)

echo "Configuration:"
printf "  vm.min_free_kbytes        : %d KB\n" "$MIN_FREE"
printf "  vm.watermark_scale_factor : %d\n" "$SCALE_FACTOR"
printf "  vm.swappiness             : %d\n" "$SWAPPINESS"
printf "  vm.zone_reclaim_mode      : %d\n" "$NUMA_RECLAIM"
echo "----------------------------------------------------------"

# Assess Direct Reclaim Activity over a 3-second sample
echo "Sampling kernel page reclaim counters (3 seconds)..."
SAMPLE1=$(cat /proc/vmstat | grep -E 'pgscand|pgsteal_direct|allocstall' | sort)
sleep 3
SAMPLE2=$(cat /proc/vmstat | grep -E 'pgscand|pgsteal_direct|allocstall' | sort)

echo "Reclaim Delta Check:"
paste <(echo "$SAMPLE1") <(echo "$SAMPLE2") | awk '{
    metric=$1
    delta=$4-$2
    if (delta > 0) {
        printf "  [ALERT] %-25s increased by %d events!\n", metric, delta
    } else {
        printf "  [OK]    %-25s stable (delta: 0)\n", metric
    }
}'

echo "----------------------------------------------------------"
echo "Zone Status Overview:"
cat /proc/zoneinfo | awk '
  /^Node/ {node=$2}
  /^Node.*zone/ {zone=$4}
  /pages free/ {free=$3}
  /min/ {min=$2}
  /low/ {low=$2}
  /high/ {high=$2}
  /spanned/ && free != "" {
    status = "[OK] Normal"
    if (free <= min) status = "[CRITICAL] Direct Reclaim Imminent"
    else if (free <= low) status = "[WARN] kswapd0 Reclaim Active"
    printf "  Node %s %-8s | Free: %-8d | Min: %-8d | Low: %-8d | Status: %s\n", node, zone, free, min, low, status
  }'
echo "=========================================================="

Make the script executable and test your environment:

chmod +x /usr/local/bin/check-memory-reclaim.sh
/usr/local/bin/check-memory-reclaim.sh

---

7. Infrastructure Scaling: Why Bare-Metal Solves Noisy-Neighbor VMM Stalls

While kernel watermark tuning successfully remedies reclaim latency in dedicated operating environments, virtualized instances face fundamental hypervisor constraints.

On shared multi-tenant public cloud virtual machines and oversubscribed hypervisors:

1. Hypervisor Memory Ballooning: When neighboring VMs on the physical host demand memory, the hypervisor’s balloon driver inflates inside your guest kernel. It rapidly steals physical frames, creating artificial watermark drops that send your guest kswapd0 into 100% CPU lockups.
2. vCPU Steal Time (%st): If the hypervisor deschedules the virtual CPU core assigned to execute kswapd0, asynchronous reclamation halts. Incoming memory requests crash straight into direct reclaim while waiting for hypervisor CPU scheduling slices.
3. Non-Deterministic NUMA Slicing: Standard VPS instances are frequently sliced across physical NUMA nodes without deterministic memory locality pinning, leading to high interconnect latency across the socket bus during page allocation.

+-------------------------------------------------------------------------+
|                  VIRTUALIZED / SHARED HYPERVISOR                        |
|                                                                         |
|  [ Guest OS: kswapd0 ]   <-- Stalled by vCPU Steal Time & Ballooning    |
|           |                                                             |
|           v                                                             |
|  [ Hypervisor Layer ]     <-- Noisy Neighbors Contending on Shared RAM  |
|           |                                                             |
|           v                                                             |
|  [ Shared Physical RAM ] <-- High Interconnect & Page Reclaim Jitter    |
+-------------------------------------------------------------------------+

                                  VS

+-------------------------------------------------------------------------+
|                 NEXTGEN ENTERPRISE DEDICATED HARDWARE                   |
|                                                                         |
|  [ Bare-Metal Kernel ]    <-- 100% Dedicated Physical CPU Cores         |
|           |                                                             |
|           v                                                             |
|  [ Direct PCIe NVMe ]     <-- Sub-millisecond Swapping & Flush I/O      |
|           |                                                             |
|           v                                                             |
|  [ Dedicated DDR5 ECC ]   <-- Deterministic NUMA Topology & Zero Steal  |
+-------------------------------------------------------------------------+

For mission-critical transactional platforms—such as large-scale WooCommerce catalogs, multi-tenant SaaS APIs, high-volume trading backends, and enterprise Elasticsearch clusters—hardware isolation is the ultimate safeguard.

Deploying on bare-metal Dedicated Servers ensures complete ownership of physical multi-channel DDR5 ECC RAM, deterministic NUMA socket assignment, and direct unmetered PCIe NVMe bandwidth. For domestic compliance, lowest regional latency, and enterprise-grade hosting in South Asia, deploying on Dedicated Servers in Pakistan delivers single-hop network peering and dedicated bare-metal resources that completely eliminate hypervisor-level memory contention.

---

8. Summary Checklist

To eliminate kswapd0 100% CPU spikes and direct reclaim stalls:

• Check baseline metrics: Execute sar -B 1 10 and ensure pgscand/s reads 0.00.
• Examine watermark levels: Review cat /proc/zoneinfo to verify that free pages remain well above low.
• Tune vm.min_free_kbytes: Size the reserve to 1%–3% of total host RAM (e.g., 1048576 KB on a 64 GB host).
• Expand vm.watermark_scale_factor: Set to 200 to give kswapd0 sufficient runway to clear memory asynchronously.
• Disable vm.zone_reclaim_mode: Set to 0 to prevent local NUMA node starvation.
• Constrain vm.swappiness: Drop to 10 to protect active process heaps from slow swap I/O thrashing.
• Set THP defrag to madvise: Eliminate synchronous 2 MB page compaction stalls across background worker processes.
• Migrate heavy workloads: Move high-concurrency database and web applications away from oversubscribed virtual hypervisors onto dedicated bare-metal infrastructure.

---