Skip to content

CONCEPT Cited by 1 source

Reclaimable vs non-reclaimable memory

Definition

Reclaimable memory is memory the kernel can transparently drop when another process requests pages — page cache, buffer cache, clean memory-mapped pages backed by files on disk. Non-reclaimable memory is memory pinned to a process's heap / stack / cached state that the kernel cannot evict without killing the process; the process must explicitly free it (via free(), via unmapping, via terminating). The distinction is the primitive that makes the single number "X GB memory used" ambiguous without category decomposition.

(Source: sources/2026-04-21-planetscale-high-memory-usage-in-postgres-is-good-actually.)

Why the distinction matters

"All three of these cache types are reclaimable by the operating system and can be dropped when something else needs RAM. … [RSS] is not reclaimable by the operating system and is what increases out of memory (OOM) risk."

— Simeon Griggs, PlanetScale

A node showing 90% memory usage where the split is 80% reclaimable + 10% non-reclaimable is in a fundamentally different operational state than 10% reclaimable + 80% non-reclaimable, even though the aggregate number is identical.

Concrete categories

Memory class Reclaimable? Typical holder
Page cache (file reads) Yes Kernel
Buffer cache (block I/O) Yes Kernel
Memory-mapped clean pages Yes Kernel
Anonymous pages (heap/stack) No Process
Shared memory (e.g. shared_buffers) No Process group
Dirty memory-mapped pages Partial Kernel flushes then reclaims
Kernel slab / dentry caches Partial Kernel shrinker
Swap-backed pages Partial (via swap) Process

Postgres's shared_buffers lives in shared memory — non-reclaimable while Postgres runs. The OS page cache that Postgres relies on as its second caching tier is reclaimable — which is why Postgres can trust the kernel to manage it.

Impact on dashboards

Operator-facing dashboards that sum reclaimable + non-reclaimable into a single "X% memory used" number create two distinct failure modes:

  1. False-positive panic. Dashboards showing "80% memory used" when 70% is page cache are expected healthy behaviour — reading Linux's free -m top row without the -/+ buffers/cache adjustment (see concepts/linux-page-cache) produces exactly this confusion.
  2. False-negative complacency. A node at 60% total memory where 55% is non-reclaimable RSS is one memory-hungry query away from OOM — the 40% slack is actually 5% because the cache can be reclaimed but RSS cannot.

Both mistakes are defeated by showing the decomposition, not the sum.

Seen in

Last updated · 550 distilled / 1,221 read