Why Linux memory numbers lie

A common support ticket reads: "The server is out of memory. free shows only 200 MB available." In many cases, the system is healthy. Linux uses unused RAM for the page cache, and free reports that memory as used. Acting on that number—by restarting applications or dropping caches—can make performance worse.

This post explains how Linux virtual memory works, which metrics actually indicate pressure, and when swap matters.

How Linux divides memory

Linux treats memory as several categories:

  • Anonymous memory: Heap, thread stacks, and application allocations. The kernel can swap this out to disk.
  • Page cache: File contents read from disk. The kernel keeps them in RAM so future reads are faster, but it reclaims these pages immediately when applications need memory.
  • Kernel structures: Slab allocations, page tables, and other internal metadata.
  • Swap: Disk or compressed-RAM backing store for anonymous pages not currently in use.

The most important idea: page cache is not memory stolen from your application. If your app needs RAM, the kernel evicts clean cache pages without asking.

Reading free, vmstat, and top

Run:

bash
free -h

Focus on the available column, not free. available estimates how much memory is available for starting new applications without swapping.

bash
vmstat 1 5

Watch si (swap in) and so (swap out). Sustained non-zero values mean the kernel is paging anonymous memory to disk. Brief spikes are usually noise.

In top or htop, RES is the physical RAM a process uses. VIRT includes mapped files and swapped addresses, so it is often misleading and should not be used alone for capacity planning.

Page cache: the memory that looks like usage

Copy a 50 GB file and free will show used rise by roughly 50 GB. That is the page cache doing its job. When a database suddenly needs 10 GB, Linux drops clean cache pages instantly.

Inspect cache details:

bash
grep -E "Cached|MemAvailable|MemFree|SwapTotal|SwapFree" /proc/meminfo

Swap: not always a problem, sometimes a lifesaver

Swap is slower than RAM, but it is not inherently bad. It lets the kernel move rarely used anonymous pages—such as an idle cron environment—to disk, freeing RAM for active workloads or page cache.

Check swappiness:

bash
cat /proc/sys/vm/swappiness

The default is usually 60. Lower values tell the kernel to avoid swapping. There is no universal correct number. A database node often benefits from a lower swappiness (10–20), while a general-purpose web host can stay at the default.

Diagnosing real memory pressure

High cache usage is normal. Real pressure looks like:

  • available stays near zero for several minutes.
  • si and so in vmstat are continuously non-zero.
  • Major page faults (pgmajfault) are climbing.
  • The OOM killer terminates processes. Check dmesg or system logs.

Inspect a specific process:

bash
grep -E "VmRSS|VmSwap|VmSize" /proc/self/status

VmSwap shows how much of that process is currently swapped out. A high value on a latency-sensitive service is a signal to add RAM or reduce memory usage.

Quick reference table

Symptom Likely meaning First action
free is low, available is healthy Page cache is using spare RAM Monitor; no action needed
High si/so rates in vmstat Active swapping Check swappiness, find memory growth, or add RAM
available near zero, little swap Anonymous memory pressure Identify top RSS consumers; review limits
OOM killer in logs Memory and swap exhausted Reduce load, add memory, or adjust oom_score_adj

Production checklist

  • Record baseline free -h, vmstat, and /proc/meminfo during normal load.
  • Alert on available memory, not free memory.
  • Monitor si/so rates, not just total swap utilization.
  • Set vm.swappiness deliberately per workload instead of using defaults everywhere.
  • Check dmesg for OOM kills after deployments or scaling events.
  • Never include drop_caches in a production runbook.

Takeaway

Low "free" memory in Linux is usually the page cache working as intended. Watch available, sustained swap-in/swap-out rates, and OOM logs to distinguish real pressure from normal caching. Tune swappiness by workload, and avoid clearing caches on running production systems just to make the numbers look better.

IFLEON can help with Linux performance reviews and production infrastructure audits.