Linux free shows almost no free memory? Read available first

Run free -h on a server and you will often see a tiny free column next to a large buff/cache column. Those numbers alone don’t tell you the machine is short of memory. The kernel’s estimate of how much memory new programs can get is in a separate column, available.

Every column comes from /proc/meminfo

free is part of procps-ng. It doesn’t measure memory itself. It reads /proc/meminfo, which the kernel exports. The free(1) manual for procps-ng 4.x maps the columns like this:

free column	/proc/meminfo field	Meaning
total	MemTotal	Usable RAM
free	MemFree	Memory not used for anything
shared	Shmem	Mostly tmpfs and shared memory
buff/cache	Buffers + Cached + SReclaimable	Kernel buffers, page cache, reclaimable slab
available	MemAvailable	Estimate of memory available to new programs without swapping
used	total − available	Memory in use or not available

free -w shows buffers and cache in separate columns. To see every raw value in the table, run:

grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|Shmem):' /proc/meminfo

A small free number is common

Most of Cached is page cache: file data read from disk and kept in memory, so that reading the same data again doesn’t require another read from storage. Linux can use RAM for this file-backed page cache, and it can reclaim much of that cache when memory runs short. On a server that reads a lot of files, a small MemFree is common and is not a sign of trouble by itself. Nor is it proof that the system is healthy.

Why free + cache is the wrong sum

People used to add free and cached together and treat the total as spare memory. The 2014 kernel commit by Rik van Riel that added MemAvailable says this is now almost always wrong. Cached includes memory that dropping the cache can’t free, such as shared memory, tmpfs and ramfs, and it leaves out reclaimable slab. Getting the estimate right requires knowledge of kernel internals, so the kernel now computes it. The field has existed since Linux 3.14.

How available is estimated

In Linux v7.2, si_mem_available() works roughly in this order:

1. Start from the number of free pages, minus the pages the kernel keeps in reserve.
2. Add the file page cache (the active and inactive file LRU lists). Subtract whichever is smaller: half of it, or the sum of all zones’ low watermarks. The code assumes that part should stay in memory.
3. Add reclaimable slab and other reclaimable kernel memory, with the same kind of deduction.
4. If the result is negative, use 0.

This is a heuristic and can change between kernel versions. The result is an estimate, not a guarantee.

The used number depends on your procps version

procps-ng 3.3.16 calculated used as total − free − buffers − (Cached + SReclaimable), and fell back to total − free if that came out negative. Starting with 4.0.1, procps-ng uses total − available. So the same memory state can produce different used figures depending on the procps version. Before you compare used across systems, check each one’s version with free -V.

drop_caches is not the fix

Writing 3 to /proc/sys/vm/drop_caches discards clean page cache and reclaimable slab objects such as dentries and inodes. As a result, the free column may increase. But the kernel documentation says this file is not a way to control cache growth. The kernel already reclaims these objects on its own when memory is needed. If the discarded data or objects are needed again, they must be read or rebuilt, which can add I/O and CPU work. For that reason the documentation advises against using it outside testing or debugging environments. Dirty objects, which haven’t been written to disk yet, are not freed this way either.

Summary

For a first look at memory headroom, available is more useful than free. A single value or downward trend does not by itself diagnose memory pressure.

For another case where OS numbers don’t add up the way you’d expect, see Deleted a file but the disk space didn’t come back?