Memory

For ordinary buffered relation I/O, PostgreSQL’s shared buffers sit above the operating system’s file cache. A shared-buffer hit avoids another read through that lower layer; a shared-buffer miss can still be served from memory by the operating system. The same file data can occupy both caches, so this is not a promise that PostgreSQL and the kernel share one physical copy. The mmap shared-memory settings concern shared regions, not a claim that ordinary table files are directly memory-mapped. ...

Expiration and eviction can both turn a successful lookup into a miss, but they answer different questions. Expiration follows a key’s deadline. Eviction removes eligible keys to respond to memory pressure. Extending a TTL cannot prevent capacity-driven eviction, and increasing memory cannot correct a deadline that the application set incorrectly. ...

Huge pages can increase the amount of memory covered by each cached address translation. They can reduce translation overhead for suitable workloads, but the result depends on access patterns and hardware. A large allocation alone does not prove frequent TLB misses, and fewer pages needed to describe a working set does not mean those translations all fit in the processor’s TLB. ...

Linux overcommit policy controls admission of certain virtual-memory commitments. It is separate from allocating resident physical pages, choosing an OOM victim, and enforcing a container’s memory limit. A successful allocation can precede physical demand, but that does not make all allocations free or guarantee that later accesses will succeed under every resource constraint. ...

A page fault means the processor could not complete an access using the current mapping or permissions. It is not synonymous with a storage read, and some faults represent invalid accesses rather than recoverable demand paging. Linux’s minor and major counters distinguish whether handling required page-in I/O. Interpret those counters alongside the mapping type and workload; neither is a direct measurement of all application storage traffic. ...

A Redis process can keep a substantial resident footprint after application keys are deleted. That observation deserves explanation, but it does not by itself prove a leak or allocator fragmentation. The useful question is which bytes remain allocated, which pages remain resident, and whether that footprint threatens the actual capacity budget. ...

Swap gives Linux a backing store for eligible memory pages that need not remain resident. It can preserve cold data while RAM serves active work, but it does not make the machine’s working set fit at RAM speed. The useful question is whether reclaim frees space without repeatedly stalling important tasks. Swap occupancy, swap traffic, and application progress answer different parts of that question. ...

When memory tightens, eligible cold pages may be reclaimed to swap. A zram swap device stores compressed pages in RAM, trading CPU work and memory overhead for potential headroom. The benefit depends on the workload; it is not a fixed amount of extra memory. ...