Memory: Used, Free, Cached & the "Available" Metric

Chapter 1's snapshot showed only 412.6 MiB "free" out of 16 GB total, alongside heavy swap usage — and deliberately left both unexplained. This chapter resolves both: why the low "free" figure is very likely a false alarm, and why the swap figure deserves real attention, though — as the closing worked example shows — not always for the reason it first appears to.

The Classic "No Free Memory" False Alarm

Linux treats unused RAM as wasted RAM. Rather than leaving memory sitting empty, the kernel fills it with a cache of recently-read disk data — the page cache — so a repeated read can be served instantly from memory instead of hitting the disk again. That cache shows up in buff/cache, and on any machine that's been running a while, it tends to consume most of whatever isn't already allocated to running processes.

Reading free -h Properly

When Memory Pressure Is Real: Swap

Swap is fundamentally different from cache. When physical RAM is genuinely insufficient, the kernel moves active, in-use memory pages out to disk to free up space — a process that's orders of magnitude slower than RAM itself, since it involves real disk I/O for data a process actually needs. Unlike reclaiming cache, swapping has a real, measurable performance cost.

The OOM Killer: When Memory Pressure Gets Severe Enough

If physical RAM and swap are both genuinely exhausted, Linux's Out-Of-Memory (OOM) killer steps in and picks a process to terminate outright, freeing its memory by force. A process that simply vanishes, with no crash log of its own and no obvious cause, is a classic OOM-kill symptom — confirmed by checking the kernel's own log:

Reading these entries correctly is exactly the log-reading discipline this site's own Logging & Log Analysis (log1) course covers in depth — this is one specific, high-value example of it, applied to a memory-pressure investigation specifically.

Windows' Own Memory Model

Windows doesn't expose the exact same free-vs-cache split. Task Manager shows figures like "In use," "Available," "Committed," and "Cached," alongside a "Standby" list — memory holding recently-used file data that can be reclaimed, conceptually similar to Linux's page cache. Task Manager's own "Available" figure already accounts for reclaimable standby memory, in the same spirit as Linux's "available" column, though the two aren't a precise one-to-one match.

Working Example: Fully Reading Chapter 1's Snapshot

Chapter 1 showed 412.6 MiB free, 4417.8 MiB buff/cache, and swap at 1890.3 of 2048.0 MiB used. The low "free" figure is exactly this chapter's false alarm — a healthy 4.3 GiB of reclaimable cache sits right next to it. The swap figure, at first glance, looks like a serious active problem. But checking whether it's actually active right now means returning to Chapter 2's own vmstat sample from this same machine:

si and so are both 0 across every sample — nothing is actively swapping in or out right now. Combined with Chapter 2's own finding of 0.0 wa, the picture is consistent and honest: this machine's high swap-used figure is a leftover from an earlier period of pressure, not an active crisis, and the actual, currently-active bottleneck is exactly what Chapter 2 already found — genuine CPU contention. Memory isn't this machine's real problem right now; it's a secondary artifact worth noting, not the headline finding.

Hands-On Exercises