free Command: Tutorial & Examples

The clearest two-line view of a Linux server's memory — once you know which column to read.

What It Is

free is the smallest, sharpest answer to one of the most stressful questions a new sysadmin asks: do I have enough RAM on this box, or is it about to fall over? Type four letters and you get two lines: one for physical memory, one for swap. That's it. No process list, no scrolling, no flags to remember. Like top and ps, free isn't doing anything magic — it reads /proc/meminfo, where the kernel publishes the entire live state of memory as plain text, and reformats it.

There's a reason this page exists and isn't just a man-page rehash: almost every beginner reads free wrong the first time, then panics. They see used is enormous, free is tiny, and they conclude the server is dying. It isn't. Linux is doing exactly what a well-designed operating system should do with spare RAM, and once you understand the trick, the output of free goes from terrifying to boring — which is what you want from a memory tool. We'll walk every column, explain the famous "Linux ate my RAM!" moment, and teach you to read the one column the GNU maintainers added precisely so you'd stop misreading the others.

Your First Look

The invocation almost nobody bothers without a flag, because the default is in kibibytes and unpleasant to read:

free -h

               total        used        free      shared  buff/cache   available
Mem:            30Gi        15Gi        12Gi       5.9Gi       8.7Gi        15Gi
Swap:           31Gi       7.7Gi        23Gi

The -h is for "human-readable" — auto-scaled units (Gi = gibibytes, Mi = mebibytes) so you don't have to count zeros. Always use -h. Two rows: physical memory on top, swap on the bottom. Six columns on Mem:, three on Swap:. The two lines tell you everything important about memory on this server in one glance, and that's the whole product.

If you want to see inside buff/cache — split into its two real components — add -w (wide):

free -h -w

               total        used        free      shared     buffers       cache   available
Mem:            30Gi        15Gi        12Gi       5.9Gi       179Mi       8.5Gi        15Gi
Swap:           31Gi       7.7Gi        23Gi

Same numbers, one more column. We'll come back to why those two are usually summed.

How I Read It

The honest answer: I look at exactly one column. It's the rightmost one — available — and it's the only number that tells you what you actually want to know, which is "how much memory can I still hand out to programs before this box starts hurting?"

Forget free (the column). Forget used. They tell a misleading story. The reading is:

First, available vs total. Above and the box is in 30 GiB total / 15 GiB available — half the RAM is free for new work, plenty of headroom. If available had read 200 MiB instead, that would be the alarm: the machine is one allocation away from swapping hard or summoning the OOM killer.

Second, glance at the Swap row — but read it the way a veteran does. Above, Swap: 31 GiB total, 7.7 GiB used, 23 GiB free. Some swap in use is normal — even on a perfectly healthy server. The kernel parks cold pages (memory a program allocated but hasn't touched in hours) out on the swap device so it can use that RAM for something more valuable — the page cache. What matters is the trend and the rate: a box that's been sitting at 7.7 GiB of swap for two weeks is fine; a box where swap is climbing every minute and the disk lights are solid red is thrashing, and that's when performance falls off a cliff. free shows the snapshot; vmstat shows the rate.

That's it. Two glances: available, then trend on swap. Now let's explain every column so the rest of the output stops being a mystery.

The "Linux Ate My RAM!" Moment

Every accidental sysadmin hits this. You SSH into a box, run free -h, and see something like total 30Gi, used 15Gi, free 1.2Gi, buff/cache 13Gi. You stare at free: 1.2Gi and your heart sinks: the server is almost out of memory. You start hunting for a process to kill. Stop. The box is fine. Look at available — likely 14 or 15 Gi.

Here's what's actually happening, and it's one of those Linux ideas that, once it clicks, you love the system a little more. Empty RAM is wasted RAM. A page of memory sitting unused does nothing for you — it's electricity burning to refresh a row of DRAM that no program is reading. So the Linux kernel takes any RAM that isn't being used by a program and lends it to the disk subsystem as a cache: every file your server has read recently sits in that buff/cache column, ready to be served in nanoseconds instead of milliseconds the next time something asks for it. That's why your web server's second request is so much faster than the first — the file already lives in buff/cache.

The genius part: the kernel gives that memory back to programs instantly when they ask. It's a loan, not an allocation. When a process calls malloc() and there isn't a free page handy, the kernel drops as much cache as needed, in microseconds, and the program never knows. So the right way to read free -h is: used is what programs are using, buff/cache is RAM the kernel is holding for you as a cache, and available is the sum you can still hand to a new program before pain begins. A healthy steady-state Linux server runs with free near zero and buff/cache enormous, forever. That's the system working correctly.

Pro Tip

read available, not free. The GNU coreutils team added the available column to free (and the matching MemAvailable line in /proc/meminfo, on kernel 3.14+) precisely because so many people were misreading the free column and panicking. available is the kernel's honest estimate of how much memory a new program could grab without forcing the box to swap — it includes the reclaimable parts of buff/cache and excludes the parts that can't be evicted. If you only remember one thing from this page, remember this column.

The Columns Explained

Every column in free -h, in order, with the trap each one sets for newcomers.

total — total usable physical RAM (or swap), minus a tiny slice reserved for the kernel binary and a few bookkeeping structures. So total is always a hair under the marketing number on the box (a 32 GiB machine reads ~30.5 GiB here — not a bug, that's kernel text and reserved low memory). From MemTotal and SwapTotal in /proc/meminfo.
used — memory used by programs and the kernel, excluding the reclaimable parts of cache. The man page defines it as total - free - buffers - cache, then in newer versions as total - available — the practical effect is the same: used is what you can't easily get back. Higher than you expect? It's not buggy — it just includes Shmem, slab caches that can't be reclaimed, kernel stacks, and so on.
free — memory that is completely unused. On a Linux box that's been up for more than a few minutes, this number is almost always tiny, and that is correct. See the "Linux ate my RAM!" section above. From MemFree/SwapFree.
shared — memory shared between processes, almost all of it tmpfs (RAM-backed filesystems like /run, /dev/shm, and many systemd runtime directories). High shared on a database box often means something is using a big in-memory file. From Shmem in /proc/meminfo.
buff/cache — RAM the kernel is lending to the disk subsystem. This is the column that scares people. With -w it splits into:
- buffers — small caches of block device metadata (filesystem structures, directory entries, raw device blocks). Usually small, megabytes.
- cache — the page cache: file contents that have been read from (or written to) disk and kept around in case they're needed again, plus reclaimable slab. This is where the real memory goes — gigabytes on any busy server.
available — the column to read. The kernel's estimate of how much memory a new process could allocate without triggering swap. Not just free + buff/cache, because some cache pages are pinned (mmap'd in active use, dirty pages waiting to flush, slab items in use). The kernel does the honest accounting for you. From MemAvailable, added in kernel 3.14 (2014) — every modern distro has it.

The Swap row uses the simpler total/used/free only (the cache concepts don't apply to swap — swap is just slow disk-backed memory the kernel parks cold pages on).

Reading It by Example

Build instinct with a few patterns. Assume free -h output throughout.

total 16Gi, used 2.1Gi, free 200Mi, buff/cache 13Gi, available 13Gi — perfectly healthy. The classic "Linux ate my RAM" output that panics beginners. free is tiny, buff/cache is huge, available is the same as buff/cache — the box has 13 GiB it can hand to a new program any time. Move on.

total 4Gi, used 3.4Gi, free 90Mi, buff/cache 480Mi, available 300Mi — getting tight. Now you should care. available under 10% of total means the next big allocation will force eviction of cache (slowing the box) or, worse, push pages to swap. Find the memory hog with ps sorted by %MEM or top and press M.

Swap: 8Gi total, 200Mi used, 7.8Gi free on a box that's been up for weeks — totally fine. Cold pages parked on disk so RAM can be cache. Don't touch it. The 200Mi likely hasn't moved in days.

Swap: 8Gi total, 7.9Gi used, 100Mi free and available near zero on Mem — actively thrashing. This is the dangerous state. Programs are being swapped in and out constantly, the disk is the bottleneck, and the box feels frozen even though top shows low CPU. Confirm with vmstat 1 and watch the si/so columns (swap-in / swap-out in kilobytes per second) — anything sustained above zero is bad news.

available dropping by 200 MiB every minute, watched with free -h -s 5 — a memory leak in something. Find it with ps aux --sort=-%mem | head and watch its RSS climb over time.

shared is 4 GiB out of nowhere — something is using a big tmpfs. Check with df -h -t tmpfs or mount | grep tmpfs. Common culprit: a database or build cache writing to /dev/shm.

Cheat Sheet

The handful of invocations worth memorizing:

free -h — human-readable, the default you actually want.
free -h -w — wide format, splits buff/cache into buffers and cache.
free -h -t — adds a Total: line summing RAM + swap.
free -h -s 2 — refresh every 2 seconds. Ctrl-C to quit. (For watching a leak in real time.)
free -h -s 5 -c 12 — refresh 12 times then exit. One-minute snapshot for a script log.
free -h -L — one-line format, perfect for cron logs.
free -m / -g — force mebibytes / gibibytes (no auto-scaling).
free --si — use SI units (powers of 1000) instead of binary. Almost nobody wants this; disks lie in SI, memory honors binary.
free -v — show the commit limit line — relevant only if you've disabled kernel memory overcommit (vm.overcommit_memory=2), which most boxes have not.

How You'll Actually Use It

In real life, free is almost always a four-keystroke check. You SSH into a box, type free -h, glance at available and the swap row, and move on. The two-line output is its whole personality — it's not a tool you use, it's a tool you consult.

The two exceptions worth knowing. Watching a leak: free -h -s 5 in a tmux pane while the leaking process runs, so you can see available drift down minute by minute — much easier to read than top or ps when you just want a memory pulse. Cron snapshots: free -h -L >> /var/log/mem.log once a minute gives you a trivial historical view without installing anything (vmstat or sar does this properly, but the one-liner is fine for a weekend).

If you find yourself trying to script around free (awk '/^Mem:/ {print $7}' and so on), you've outgrown it — reach for vmstat for trends, /proc/meminfo for the raw fields with stable names, or a proper monitoring agent. free's column positions have shifted between versions; scripts that pin to column 4 break.

Gotchas

free is not what's available — available is what's available. The whole point of this page. The free column shows memory that's truly idle; on a healthy server it's near zero and that's correct.
A little swap in use is normal. The alarm is the rate of swapping (si/so in vmstat), not the static used number. A box can sit with 500 MiB of swap used for months and be perfectly happy.
The OOM killer fires when both RAM and swap are exhausted. It picks a victim by score (roughly: who's using the most memory, with adjustments) and kills it — not necessarily the runaway you'd pick by hand. Always-on databases get killed with surprising regularity by leaky web workers on the same box. Tune oom_score_adj if it matters; or just give the box more RAM.
Dropping caches with echo 3 > /proc/sys/vm/drop_caches rarely helps. root can force the kernel to evict buff/cache immediately — useful for a benchmark where you want a cold cache, basically nothing else. You're not "freeing memory" you needed; you're throwing away a free performance boost. Don't put it in a cron job.
-b, -k, -m, -g are binary (KiB/MiB/GiB, powers of 1024), not the decimal --kilo/--mega/--giga which imply --si. Mixing these up makes your memory numbers off by 7%.
shared was zero on kernels before 2.6.32. Ancient history now, but if you see a tutorial showing shared always 0, that's why.
free reads a snapshot. A program that allocates 2 GiB and frees it between two free runs is invisible. Watch with -s or use a proper time-series tool.

History & Philosophy

free ships in procps-ng, the same little package that gives you ps, top, vmstat, pgrep, pkill, uptime, and watch. One small project, almost every process and memory tool you reach for on a Linux box. The lineage goes back to the BSD vmstat/ps family of the 1980s, rewritten for Linux in the early 90s, and maintained continuously since — which is why so many of them share the same "read /proc, format nicely, get out of the way" design.

And here's the same payoff you get on the top and ps pages: free isn't doing anything magic. Run this:

cat /proc/meminfo

MemTotal:       32868472 kB
MemFree:        12345678 kB
MemAvailable:   15678901 kB
Buffers:          183296 kB
Cached:          8765432 kB
...

Every number free prints lives in that file. The kernel publishes the entire live state of memory as plain text, refreshed on read; free is a 200-line program that parses it and pretty-prints. The available column? It's MemAvailable divided by 1024. The whole tool is a thin layer over /proc/meminfo. That's the "everything is a file" idea again, and once it lands, you start exploring /proc yourself for the numbers free doesn't bother showing — Dirty: (pages waiting to flush to disk), Slab: (kernel data structures), HugePages_Total: (databases love these), and dozens more.

The deeper philosophy of the available column is worth pausing on too. It exists because the maintainers watched, for years, beginners misread free, panic, and either reboot a healthy server or buy a bigger one. Rather than write more documentation, they added a column. That's a lovely piece of API design: when users keep getting it wrong, don't blame them — change the interface.