Why Does ‘free -h’ Show No Free Memory? Understanding Buff/Cache Before You Buy RAM

Someone runs free -h on a production box, sees 62 of 64 GB “used” and almost nothing free, and raises a ticket to buy more RAM. Nine times out of ten that ticket is wrong, because the number that scared them is not measuring what they think it is.

Linux is designed to use memory you have paid for. Empty RAM is wasted RAM, so the kernel fills it with cached copies of files it has read from disk. That cache is instantly reclaimable the moment a process actually needs the space. The classic mistake is to read the free column, panic at how small it is, and provision hardware to fix a problem that does not exist. This is how to read Linux memory reporting correctly and size RAM on evidence rather than on a frightening number.

What free -h is actually telling you

Run it on a healthy, busy Ubuntu 24.04 server and you get something like this:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        9.2Gi       1.1Gi       412Mi        52Gi        52Gi
Swap:          8.0Gi          0B       8.0Gi

The eye goes straight to free: 1.1 GiB. It looks like the box is nearly out of memory. It is not. Read the columns properly:

• used — memory genuinely allocated to running processes and kernel structures that is not reclaimable as cache. Here, 9.2 GiB.
• buff/cache — page cache, buffers and slab that hold file data and metadata. Here, 52 GiB. This is the kernel doing its job, not a leak.
• free — memory that is completely untouched. On a server that has been up for any length of time this trends towards zero, and that is correct behaviour.
• available — the number that actually matters: the kernel’s estimate of how much memory a new workload could claim without swapping, counting the reclaimable cache. Here, 52 GiB.

So the box has 52 GiB it can hand to a new process on demand. It is nowhere near exhaustion. Anyone reading free instead of available is reading the wrong column, and has been since the available column was added to free years ago precisely to stop this mistake.

Where the available number comes from

free is a thin wrapper over /proc/meminfo. The line that drives the available column is MemAvailable, which the kernel has exposed since version 3.14. It is not simply MemFree plus Cached — the kernel is more honest than that. Some cache is pinned and cannot be dropped, and it holds back low-memory watermarks, so MemAvailable is a deliberately conservative estimate of what is genuinely reclaimable.

$ grep -E 'MemTotal|MemFree|MemAvailable|^Cached|Buffers|Dirty|Writeback' /proc/meminfo
MemTotal:       65808476 kB
MemFree:         1191284 kB
MemAvailable:   54892160 kB
Buffers:          842560 kB
Cached:         51203904 kB
Dirty:             18432 kB
Writeback:             0 kB

The value to trust is MemAvailable. If it is a healthy fraction of MemTotal, the machine has headroom whatever MemFree says. Two lines worth a glance while you are here: Dirty is data written but not yet flushed to disk, and a persistently large Dirty figure points at I/O keeping up rather than a memory shortage.

How to tell real pressure from healthy caching

Cache being large is not evidence of a problem. Evidence of a problem is the machine having to reclaim that cache aggressively, or swap, to satisfy demand. Two tools show that directly.

First, vmstat. Watch the si and so columns — swap-in and swap-out, in KiB per second:

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 1219432 842560 51203904    0    0    12    48  920 1740  6  2 92  0  0
 1  0      0 1201884 842560 51210240    0    0     0   120  880 1602  5  1 94  0  0

Zeros under si and so mean the system is not swapping at all. That is what health looks like, even with cache filling the box. Sustained non-zero values — particularly so, pages being pushed out to swap — mean the kernel is short of memory and starting to page working sets to disk. That is when latency dies and when RAM might genuinely help.

Second, and more precise, Pressure Stall Information. Since kernel 4.20 the kernel accounts the time tasks spend stalled waiting on memory, and exposes it at /proc/pressure/memory:

$ cat /proc/pressure/memory
some avg10=0.00 avg60=0.00 avg300=0.00 total=41290
full avg10=0.00 avg60=0.00 avg300=0.00 total=18104

The some line is the percentage of time at least one task was stalled waiting on memory; full is the time every runnable task was stalled, which is the more serious signal. The avg10, avg60 and avg300 figures are those percentages over the last 10, 60 and 300 seconds. All zeroes, as above, means no memory stalls: the large cache is costing you nothing. If some avg60 is sitting at, say, 15 and full is non-zero, tasks are being held up reclaiming memory and you have real pressure to act on. PSI is the difference between guessing and measuring.

Sizing RAM on evidence, not on a scary number

Put the three readings together and you have a defensible decision. If available is comfortable, vmstat shows no swap activity, and PSI is near zero, the box is healthy and buying RAM buys you nothing. If available is chronically low, so is regularly non-zero, and memory PSI is elevated across the 60- and 300-second windows under normal load, you have a real constraint — and now you can quantify it instead of reacting to a single alarming column.

This is capacity planning, and it belongs in the same evidence discipline as the rest of your platform. The same instinct that makes teams instrument delivery metrics rather than argue from anecdote should govern hardware spend: alert on MemAvailable as a fraction of total and on memory PSI, not on MemFree. It also feeds straight into how you allocate infrastructure cost to the workloads that actually drive it — you cannot bill or right-size what you have mis-measured.

The one-line version to give your on-call team: on Linux, free near zero is normal and available is the number that counts. Before anyone orders memory, show me swap activity in vmstat and a non-zero full line in /proc/pressure/memory. No pressure, no purchase.