RAM: Explanation & Insights

Where the server does its real thinking — vast, fast, and wiped clean on every reboot.

What It Is

RAM — Random Access Memory — is the server's workspace: the fast, volatile scratch space where every running program actually lives while it runs. The disk is the filing cabinet that survives a power cut; RAM is the desk you spread the papers out on to get work done. Pull the plug and the desk is swept bare in an instant — that volatility isn't a flaw, it's the trade you make for speed. RAM answers in tens of nanoseconds; even the fastest NVMe drive is a thousand times slower. The whole shape of a running computer is the CPU reaching into RAM millions of times a second, because RAM is the only thing close enough and quick enough to feed it.

The "random access" in the name is a fossil from a distinction that barely exists anymore, and it's worth a moment because it explains the word. Early storage was sequential: a tape had to spin to the right spot, so reading byte one billion meant winding past the first billion. RAM's breakthrough was that any address costs the same to reach as any other — byte one and byte one billion come back equally fast, in any order, at random. That property is so completely assumed today that we forget it was ever remarkable, but the name still carries the memory of when it wasn't.

This page is the orientation map for memory on a Linux server. It ties together the ideas that branch off it — how the kernel hands each process its own private view of memory, why the free command's "free" column lies to you in the most helpful way possible, what the page cache is and why a healthy server's RAM is supposed to look nearly full, what swap really does, and what happens at the cliff edge when the memory genuinely runs out. By the end, the single most-misread number on a Linux server — "available memory" — will read like an open book.

Why It Matters

Memory is the resource a server runs out of suddenly. A disk fills up over weeks and gives you warning after warning; RAM can go from comfortable to catastrophic in the time it takes one runaway query to ask for more than the machine has. And the failure mode is uniquely violent: when Linux truly runs out of memory, it doesn't politely slow down — the kernel's OOM killer wakes up and starts terminating processes to claw space back, often the very database or web server you most needed alive. One minute everything is fine; the next, your most important daemon has been shot in the head and there's a cryptic line in dmesg to explain it.

It also matters because memory pressure is the great disguiser. A server starved of RAM doesn't always announce "out of memory" — it starts leaning on swap, and swap lives on the disk, which is a thousand times slower, so the machine appears to develop a disk problem, or a load problem, or just a vague everything-is-molasses problem. Half of "the server is mysteriously slow" tickets are a memory problem wearing a disguise. Learning to read memory correctly is what lets you pull the mask off.

How Linux Sees Memory

Here is the idea that unlocks everything else: no process on a Linux server ever sees the real, physical RAM. Each one is handed its own private, pristine illusion called a virtual address space — a clean, continuous stretch of memory that, as far as that program can tell, belongs to it alone and starts at address zero. Two processes can both believe they own address 0x40000000, and the kernel, with help from a chip on the CPU called the MMU, quietly maps each one's illusion onto different actual chips. The program writes simple code against a tidy fiction; the kernel does the bookkeeping that makes the fiction safe to share.

That indirection buys three things at once, and they're the reason it exists. Isolation: one process physically cannot read or scribble on another's memory, because the addresses it can name don't reach there — the bedrock of multi-user security. Overcommit: the kernel can promise more memory than the machine physically has, betting (usually correctly) that not everyone cashes the cheque at once. Laziness: memory you malloc but never touch costs nothing until you touch it, because the mapping is only filled in on first use. The unit of all this bookkeeping is the page, almost always 4 KiB — the kernel never thinks about memory a byte at a time, only a page at a time, and that word "page" turns up everywhere once you start looking (page cache, page fault, paging, swap).

You can watch the whole picture in one file. Everything Linux knows about memory is laid out, plainly, in /proc/meminfo:

cat /proc/meminfo

MemTotal:       32793528 kB
MemFree:         1185432 kB
MemAvailable:   27340119 kB
Buffers:          521884 kB
Cached:         25107360 kB
SwapTotal:       8388604 kB
SwapFree:        8060412 kB

The free command is, like so much on Linux, just a friendly face painted over that file — it reads /proc/meminfo, does the arithmetic, and prints it in human units. There's the first small piece of magic: the tool isn't measuring anything the kernel doesn't already write down in plain text for you to read directly.

The Number Everyone Misreads

Run free -h on a busy, perfectly healthy server and the output frightens almost everyone the first time:

free -h

               total        used        free      shared  buff/cache   available
Mem:            31Gi       4.2Gi       1.1Gi       312Mi        26Gi        26Gi
Swap:          8.0Gi       256Mi       7.7Gi

Free memory: 1.1 GiB out of 31. The instinct is panic — the box is nearly out of RAM, time to buy a bigger server. The instinct is wrong, and unlearning it is the single most valuable thing on this page.

Look at the buff/cache column: 26 GiB. That isn't memory that's gone — it's memory Linux has borrowed to cache files it has read from disk, on the bet you'll want them again. And you usually do: serving the next request from that cache is a thousand times faster than going back to the disk. The kernel's philosophy is blunt and correct — free RAM is wasted RAM. Idle memory does no work; memory full of cached files makes the whole machine faster. So Linux keeps RAM nearly full on purpose, and a healthy server's free column is supposed to be small.

The number that actually tells you the truth is available — 26 GiB here. That's the kernel's honest estimate of how much memory a new program could claim right now without anything having to go to swap, because the cache is instantly evictable: the moment a real process needs that RAM, the kernel drops cached pages and hands the space over, no disk write required. So the rule is simple and it overturns the panic:

Pro Tip

Ignore the free column; read the available column. free near zero on a busy server is healthy — it means the page cache is doing its job. You only worry when available gets small, because that's the memory genuinely up for grabs. The day someone tells you "the server's out of RAM, look, only 1 gig free," you'll know to look one column to the right.

This is why the page cache deserves its own page — it's not a side-effect of memory, it's one of the cleverest uses of it. See page cache for the full story of how Linux turns spare RAM into free speed.

When It Really Runs Out

The cache is elastic, so for a long time growing demand just squeezes it smaller and nobody notices. But cached pages are the easy give-back; eventually a server under real pressure runs out of cache to evict and faces a genuine shortage of memory that processes actually need. Now the kernel has two escalating moves, and watching for the first one is how you catch trouble before the second.

First, it swaps. The kernel takes pages of real, in-use memory that haven't been touched in a while and writes them out to swap on disk, freeing the RAM for something hotter. A little swap sitting idle is fine and normal. The danger is thrashing: when the working set genuinely exceeds RAM, the kernel ends up frantically shuttling pages between RAM and disk — evicting a page only to need it again a second later — and because disk is a thousand times slower than memory, the machine slows to a crawl while the CPUs sit mostly idle, blocked in iowait, waiting on swap I/O. This is the classic memory-problem-disguised-as-a-disk-problem. Sustained swap activity — not swap usage, but the rate of paging in and out — is one of the cleanest early warnings a server gives.

Then, if there's nowhere left to turn, it kills. When even swap can't satisfy demand, the kernel invokes the OOM killer — a routine that scores every process by a heuristic ("how much memory would killing this free, and how expendable is it?") and sends SIGKILL to the unlucky winner. It is a last resort to keep the whole machine from locking up, and it's brutal by design: no cleanup, no save, just gone. You find out after the fact, in the kernel log:

dmesg | grep -i 'killed process'

[1843271.554] Out of memory: Killed process 2287 (mysqld) total-vm:9583220kB, anon-rss:7811944kB

Warning

The OOM killer's choice rarely feels fair. It tends to target whichever process is biggest — which on a server is very often your database or application server, the thing you least wanted to lose. If a critical daemon keeps mysteriously dying with no crash of its own, check dmesg for an OOM kill before you debug the daemon: it may be an innocent bystander, and the real fix is more RAM, a memory limit on whatever is leaking, or a leak hunted down and squashed.

The full diagnose-and-recover walkthrough lives on out of memory; memory leak covers the slow-creep version where one process eats the machine over days.

The Physics, Briefly

It's worth knowing what RAM physically is, because the answer is quietly astonishing. Each bit in the dominant type — DRAM, the "D" for dynamic — is stored as a tiny electric charge in a capacitor so small that billions fit on a fingernail-sized die. A charged capacitor is a 1, an empty one a 0. But these capacitors are leaky: left alone, the charge drains away in milliseconds and the bit would simply evaporate. So the memory controller refreshes every single row of the chip thousands of times a second — reading each bit and writing it straight back to top up the charge — for the entire time the machine is on. That frantic, ceaseless rewriting is the "dynamic" in DRAM, and it's why RAM forgets the instant the power dies: stop refreshing, and within a heartbeat every leaky capacitor empties and the desk is swept clean.

Backstory

Because RAM is ultimately just charge sitting in capacitors, it's vulnerable to the physical world — a stray cosmic ray or background radiation can flip a bit. Servers that can't tolerate a silent bit-flip use ECC (Error-Correcting Code) memory, which carries extra bits to detect and repair single-bit errors on the fly. It's the unglamorous reason real server RAM costs more than the desktop kind, and the reason a server can run for years without a memory-induced glitch. CleverUptime reads these ECC error counts where the hardware exposes them — a slowly rising count is a memory module quietly beginning to fail.