free, slabtop, and /proc/meminfo - memory diagnostics

Linux memory looks simple (used vs free) but is complex (page cache, anonymous memory, slab, reclaim). This lesson covers how to read the memory state and find pressure.

free

free -h

Output:

               total        used        free      shared  buff/cache   available
Mem:           64Gi        30Gi        10Gi       1Gi        24Gi        33Gi
Swap:          8.0Gi       7.0Gi       1.0Gi

Reading:

• total: physical RAM.
• used: actively used by applications + kernel.
• free: completely unused.
• shared: tmpfs and similar.
• buff/cache: page cache + buffers. This is not “wasted” - it is reclaimable when needed.
• available: free + reclaimable cache. The real “free” memory for new allocations.

For monitoring, use available — the sixth column. The free column (the third) is the misleading one: it counts only memory that holds nothing at all, so it excludes the reclaimable page cache and looks alarmingly small on a perfectly healthy host that has simply been up long enough to cache its working set. On the sample above, free says 10Gi while available says 33Gi, and 33Gi is the number that predicts whether the next allocation succeeds.

Alerting on the free column is how a team ends up paging itself about a host that is behaving exactly as designed. Scrape MemAvailable from /proc/meminfo rather than parsing free(1), whose column layout has changed between procps versions.

/proc/meminfo

cat /proc/meminfo

Key fields:

• MemTotal: total physical RAM.
• MemFree: completely unused.
• MemAvailable: free + reclaimable. The “real” available.
• Buffers: block device cache.
• Cached: page cache.
• SwapTotal, SwapFree: swap space.
• Dirty: pages waiting to be written to disk.
• Writeback: pages actively being written.
• AnonPages: anonymous memory (process heap, stack).
• Mapped: files mapped into processes (e.g. shared libraries).

Page cache

Linux uses free RAM as a page cache: read-ahead, write buffer. When applications need more RAM, the kernel reclaims cache pages.

# Force the kernel to drop cache (test only)
echo 1 > /proc/sys/vm/drop_caches    # page cache
echo 2 > /proc/sys/vm/drop_caches    # dentries and inodes
echo 3 > /proc/sys/vm/drop_caches    # both

In production, the cache is performance. Don’t drop it manually.

Anonymous memory

Anonymous memory is process memory that has no file backing: heap, stack, malloc. It cannot be discarded like cache; it must be written to swap or compressed.

grep -E 'AnonPages|Active\(anon\)|Inactive\(anon\)' /proc/meminfo

If anonymous memory is high and free is low, the system will start swapping.

slabtop

The kernel allocates many small caches (inode, dentry, buffer headers). The slab allocator manages them.

slabtop

Output:

 Active / Total Objects (% used)    : 1000000 / 1200000 (83.3%)
 Active / Total Slabs (% used)      : 30000 / 32000 (93.8%)

  OBJS   ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
  50000   49000  98%    0.19K  5000       10    9M  dentry
  30000   29000  96%    0.06K   500     60    1M  vm_area_struct
  ...

A high slab usage for one cache type (e.g. dentry) may indicate a leak. Sort by size, find the largest, investigate.

Identify memory pressure

Pressure shows up as:

• High Dirty / Writeback: writes not flushing.
• High AnonPages: anonymous memory growing.
• Swap activity (si/so in vmstat).
• High pgfault / pgmajfault in pidstat -r.
• Page cache shrinking while applications need memory.

Common patterns

Knowledge check