What free
is really telling you, and some bits from /proc/meminfo
The free
command is a pretty venerable Linux sysadmin tool; often
it's one of the first things I reach for when I suspect that a
system might be having RAM problems. Its normal output certainly
looks straightforward enough, but as I discovered recently it's always good to actually look up
the details of this stuff.
So let's start with the normal output:
; free -m total used free shared buff/cache available Mem: 32158 13111 683 33 18363 9727 Swap: 4094 0 4094
Total is the total physical memory. 'Used' is a calculated figure;
according to the manpage, it's total
minus free
and buff/cache
(and does not include shared
). buff/cache
is the sum of what
'free -w
' will show separately as buffers
and cache
, and this
is where life gets interesting.
Free's buffers
is /proc/meminfo
's Buffers
field,
which according to the fine documentation is:
Relatively temporary storage for raw disk blocks
shouldn't get tremendously large (20MB or so)
That size info is clearly what they call 'a little bit out of
date', considering that our normal machines run around 400 MB of
Buffers
. There can be variations from this, and in particular my
machine running ZFS on Linux usually has substantially more space in
Buffers
; right now it's almost 4 GB.
Free's cache
is the sum of meminfo's Cached
and Slab
fields.
Cached
is the page cache, which is used by normal filesystems to
hold pages read off disk (or in the case of NFS, off the network).
Slab
reports the amount of memory used by the kernel's slab
allocator. Calling
this cache
is potentially misleading, since the slab allocator
is widely used all through the kernel for many, many things as you
can see by looking at /proc/slabinfo
or running slabtop
, in
both cases as root (note that slab merging
can make the slab names somewhat misleading). However it's true
that some of the kernel's slab memory usage is for 'caches' (broadly
construed).
Free's available
is meminfo's MemAvailable
, which is a kernel
estimate based on a bunch of internal heuristics that I'm not going
to try to write up. These heuristics can be wrong for various
reasons, including kernel subsystems that can shrink their slab
usage under memory pressure but don't put the right magic markers
on their slabs so that some of their slab usage shows up in
MemAvailable
.
Nothing in free
's output tells you how much memory the kernel is
using in total. The kernel uses more memory than appears in buffers
and cache
, and free
does not attempt to reverse engineer a
kernel usage figure based on finding out how much memory appears
to be in use by user programs. This is fair enough, given that
free
is primarily concerned with telling you how much memory is
or might be freeable (it's in its name, after all). Still, it's
something to bear in mind; if you really want to get a picture of
kernel memory usage, you want another tool.
(I don't know what tool you want; I haven't looked yet. I suspect
that sufficient information is exposed in /proc/meminfo
to work
this out with reasonable accuracy.)
PS: If it was up to me, I would redefine free's cached
to be
meminfo's Cached
plus SReclaimable
. The latter is the amount
of space used by slabs that have explicitly marked themselves as
reclaimable under memory pressure, which is hopefully more or less
the set of slabs that are actually being used as caches instead of
for more sticky things.
|
|