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. ...
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. ...
Databases and high-throughput servers often win, but they pay by needing contiguous memory and a pool sized in advance, so the trade is architectural, not free. Why 4 KB hurts On most architectures a standard page is 4 KiB, and the TLB can hold only a limited number of translations. A database or high-throughput server that touches gigabytes typically walks a working set of millions of pages, so it keeps missing the TLB, the hardware then has to walk the page table to find each mapping. The cost is not the page itself but the constant page-table walks, and at million-page working sets the misses outrun how fast the TLB can be refilled. Bigger pages mean each entry covers more memory, so the same working set needs far fewer entries, which is exactly the relief a memory-heavy workload feels. ...
Tuning vm.overcommit_memory shifts the failure point from a blind heuristic back to your own budget, which changes exactly who eats an OOM kill. Why malloc rarely fails vm.overcommit_memory defaults to 0, the heuristic mode that says yes to almost every mmap and malloc while it can plausibly honor them, and only refuses when the system is genuinely short on memory. Committing virtual memory costs almost nothing up front because pages are handed out lazily, so most allocations succeed and most normal applications stay alive at near-zero cost. The price of the generosity is that the kernel can over-commit far beyond RAM, betting that you will not touch every page; when many bytes actually get written, someone has to pay with an OOM kill. ...
Treating all faults as slow conflates the cheap and the expensive, which is why the split between minor and major matters when you tune memory-heavy services. Minor faults map a page A minor page fault happens when the page is already resident in RAM but the process does not yet have it mapped. The kernel only has to wire up a page-table entry — pointing the virtual address at physical memory that is already there. Common cases: first touching a freshly allocated zeroed region, mapping a shared library that another process already loaded, or a page that was swapped in once and sits in memory. Minor faults are cheap: a few hundred nanoseconds, no disk, no IO. They happen constantly in normal-running processes and are not, by themselves, a performance problem. ...
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 is not extra memory. It is a bet: the kernel picks pages it predicts will not be needed soon, writes them to a device, and frees the RAM. When the prediction holds, a spike passes without killing a process. When it does not, every wrong guess costs a device round trip, three to five orders of magnitude above reading RAM. ...
When memory tightens, cold pages would go to a slow disk. zram keeps them in compressed RAM instead, trading a little CPU for much more headroom. A compressed block device in memory zram is a block device that lives in RAM and stores compressed data instead of talking to a real disk. When the kernel swaps a page into it, the page is compressed and kept in memory, so the memory gain comes from shrinking the pages rather than moving them to slow storage. Because the device is memory-backed, it answers reads and writes far faster than a disk-backed swap, but the space it provides is limited by how compressible the pages are and by how much memory you are willing to trade for the swap. ...