sysadmin · difficulty ◆
free — report real memory usage & swap
Your server says 97% RAM used and you panic — then you learn what buff/cache actually means and stop. This is that lesson.
The moment a server starts swapping, every sysadmin reaches for one command. Here is what its numbers actually tell you — and which one you should ignore.
AI-generated draft · reviewed and editedThis text was generated with AI as a first draft, then reviewed and edited by the author, who holds editorial responsibility for it.
$ freeWhat it does
free prints how much physical memory (RAM) and swap space is in use on the machine. It reads the counters out of /proc/meminfo and lays them out in a table: total, used, free, shared, buff/cache, and available — for both RAM and swap. Run bare and you get kibibytes (1024-byte units), which is why the first thing everyone does is add -h. The whole point of the command is the subtle difference between 'used' and 'available': used sounds alarming, available is the number that actually tells you whether you are in trouble.
Why it matters
Linux loves free memory the way a hoarder loves a spare bedroom — it caches aggressively, so 'used' is almost always high and 'free' is almost always low even when nothing is wrong. The number that matters is 'available': memory that can be reclaimed from cache and given to a process the moment it needs it. So when someone shouts 'the box is at 95% RAM!', the correct response is `free -h`. Nine times out of ten, buff/cache is huge, available is healthy, and there was never a problem. When available actually bottoms out, then — and only then — you start worrying about swap pressure.
Where the numbers come from
/proc/meminfo is a virtual file — the kernel computes it on every read — and free is essentially a formatter for it. The man page maps each column onto a field: total is MemTotal, free is MemFree, shared is Shmem, buffers is Buffers, cache is Cached plus SReclaimable, and available is MemAvailable. Seeing the mapping makes the odd cases obvious. `grep MemAvailable /proc/meminfo` on a box under pressure returns a small number while MemFree still looks respectable, because MemFree counts only memory that is not in use at all, while MemAvailable is an estimate of what could actually be handed to a new process once reclaimable cache and slabs are taken into account. When you want a memory number for a script or a dashboard, read the field directly and skip the table.
Example
$ free -h total used free shared buff/cache available
Mem: 15Gi 7.1Gi 977Mi 42Mi 7.7Gi 8.3Gi
Swap: 4.0Gi 3.4Gi 645Mi-h prints human-readable units. Look at the gap: only 7.1Gi 'used', but 7.7Gi sits in buff/cache and can be reclaimed — so 'available' is a healthy 8.3Gi. The box is fine.
$ free -h -t total used free shared buff/cache available
Mem: 15Gi 7.1Gi 977Mi 42Mi 7.7Gi 8.3Gi
Swap: 4.0Gi 3.4Gi 645Mi
Total: 19Gi 10Gi 1.6Gi-t appends a Total row that adds RAM and swap together — and it fills in only total, used and free; procps leaves the shared, buff/cache and available columns blank on that line. Swap is heavily used here (3.4 of 4.0Gi) — a sign this box pushed memory hard in the past, but right now it is not actively thrashing.
$ free -m total used free shared buff/cache available
Mem: 15698 7236 977 42 7871 8461
Swap: 4095 3450 645-m prints mebibytes instead of human units. Scripts and monitoring dashboards often read free -m because integers parse cleanly. The 15698 MiB total is the same 15Gi of RAM the -h output above shows — free -h just rounds it to whole gigabytes.
$ free -s 2 -c 3 total used free shared buff/cache available
Mem: 16075264 7410308 1001336 43232 8060092 8664956
Swap: 4194300 3533264 661036
total used free shared buff/cache available
Mem: 16075264 7408996 1002396 43228 8060292 8666268
total used free shared buff/cache available
Mem: 16075264 7408996 1002396 43228 8060292 8666268-s N reprints every N seconds, -c N stops after N iterations. Watch availability trend across a few seconds to spot a slow memory leak in a process — a stable available over time means no leak, a steadily shrinking one means something is chewing RAM.
Common flags
- -h
- human-readable sizes, scaled to the shortest three-digit unit (15Gi, 626Mi) instead of the default kibibytes
- -m
- report in mebibytes — friendly to scripts and dashboards
- -g
- report in gibibytes (rounds down, handy for quick eyeballing)
- -t
- append a Total row summing RAM and swap
- -s N
- repeat the output every N seconds (monitoring loop)
- -c N
- stop after N repetitions — pair with -s for bounded sampling
- -w
- wide output; breaks buff/cache into separate buffers and cache columns
History
Origin
free has shipped with procps/procps-ng since the early days of Linux. Its entire job is to read /proc/meminfo — a virtual file the kernel generates on the fly — and render its dozens of raw counters into a table a human can read in one glance. The tool barely changed for decades; the interesting evolution was adding the 'available' column, which arrived in procps-ng 3.3.10 in 2014 specifically because the classic used/free pair kept misleading people who did not understand cache. The number itself is the kernel's MemAvailable field, added in Linux 3.14; procps emulates it on kernels from 2.6.27 upward, and on anything older 'available' is simply the same as 'free'.
Why 'available' had to be invented
For years, 'free' memory was tiny and 'used' was huge on every healthy Linux box, and newcomers read that as 'the machine is almost out of RAM'. The 2013 addition of the available column was the kernel and procps maintainers conceding that the old pair was actively deceiving. available is an estimate of what could be reclaimed right now — freeing cache and dropping clean pages — which is the number that correlates with whether you will actually OOM. That one column defused years of false alarms.
Fun facts
Pros & cons
pros
- + Universal — installed by default on every Linux distribution
- + One glance answers 'am I out of memory?' via the available column
- + Reads live kernel counters, so it needs no privileges and is instant
cons
- − The used/free/buff-cache columns actively mislead newcomers — only available is diagnostic
- − Reports a snapshot only; leaks need -s monitoring or a logging tool
- − Different units by default across distros/age, so bare output is easy to misread
Takeaways
- 1Run `free -h` and read the 'available' column — it is the only number that tells you if you are actually out of memory
- 2Ignore 'free' being small: on Linux, buff/cache is reclaimable, so 'free' low + 'available' high = healthy
- 3Watch Swap separately — heavy swap use signals past or present memory pressure
- 4Sample leaks with `free -s 2 -c 10` and watch available trend over ~20 seconds
- 5Add -t for a RAM+swap total, -m for script-safe integer output