One of the most persistent misunderstandings among entry-level systems administrators and support engineers is interpreting Linux memory utilization. An administrator logging into a newly provisioned database or web server frequently panics upon discovering that 95% of physical RAM is consumed, even with minimal application load.
In Linux, free memory is wasted memory. The Linux kernel proactively repurposes idle RAM for filesystem disk caching, releasing it dynamically the microsecond applications demand memory. Understanding the architecture of Buffers, the Page Cache, and the kernel's emergency Out-Of-Memory (OOM) Killer is foundational for diagnosing performance degradation and application crashes.
Virtual Memory Architecture & Pages
Linux utilizes a Virtual Memory subsystem that isolates user applications into virtual address spaces. The kernel maps virtual addresses to physical RAM using the CPU's Memory Management Unit (MMU) in atomic blocks called Pages (typically 4 KB on x86_64 architecture):
- Resident Set Size (RSS): The actual portion of physical RAM currently allocated and occupied by a process.
- Virtual Size (VSZ): The total virtual memory address space allocated to a process, including shared libraries, mapped disk files, and uncommitted allocations.
- Anonymous Memory: Memory allocated for process stacks, heaps, and variable data that is not backed by a physical file on disk.
Buffers vs Page Cache: The Disk Caching Engine
When you query system memory using the free -m or free -h command, the kernel breaks down physical memory into distinct categories:
free -h total used free shared buff/cache available
Mem: 31Gi 8.2Gi 1.1Gi 450Mi 22Gi 22Gi
Swap: 8.0Gi 120Mi 7.9Gi| Column / Metric | Kernel Definition & Operational Purpose |
|---|---|
| total | Total physical RAM installed and recognized by the BIOS/UEFI. |
| used | Memory actively allocated to user-space processes, kernel data structures, and shared memory. |
| free | Memory with zero current assignment. In a healthy server, this should naturally be low. |
| buff/cache | Combined disk caching subsystem: Buffers (raw disk block I/O metadata) + Page Cache (cached file contents). |
| available | The True Metric: Estimated memory available for starting new applications without swapping. Includes free RAM plus reclaimable page cache. |
The Critical Difference: Buffers vs Cache
- Buffers: Temporary in-memory storage for raw disk blocks waiting to be written to or read from physical storage. Buffers track filesystem metadata (inodes, directory listings, block bitmaps) and raw block device access.
- Page Cache: Caches the actual data contents of files read from disk. When an application reads a file, Linux retains the read pages in RAM. Subsequent reads are fulfilled directly from memory at nanosecond speeds rather than requiring mechanical disk or NVMe lookups. If an application needs memory, the kernel immediately evicts clean page cache pages with zero penalty.
The Role of Swap & swappiness
Swap space is a designated disk partition or file utilized when physical memory demands exceed RAM capacity. Furthermore, Linux uses swap to page out stagnant, inactive memory pages (such as initialization code that ran once at boot), freeing fast physical RAM for active caching.
The kernel parameter vm.swappiness (ranging from 0 to 100, default typically 60) controls the kernel's aggressiveness in swapping anonymous memory versus reclaiming page cache:
# Check current swappiness value
sysctl vm.swappiness
# In latency-critical database servers (e.g. MySQL, Redis), reduce swappiness to 10
sudo sysctl -w vm.swappiness=10The Out-Of-Memory (OOM) Killer Mechanics
Because Linux permits memory overcommitting (promising applications more virtual memory than physically exists, assuming not all will use their full allocation simultaneously), a server can exhaust both physical RAM and swap space. When the kernel cannot allocate a single additional page to service an interrupt, it invokes the Out-Of-Memory (OOM) Killer to save the operating system from a total kernel panic.
How the OOM Killer Scores Processes (oom_score)
The kernel calculates an integer score (from 0 to 1000) for every running process, visible in /proc/[PID]/oom_score:
- The primary factor is the percentage of physical RAM consumed by the process.
- The kernel applies penalties for processes that consume large amounts of memory with short runtimes.
- Processes running as root or critical system daemons receive minor negative adjustments.
- The process with the highest overall
oom_scoreis terminated with an uncatchableSIGKILL(signal 9).
Forensic Detection in dmesg
When an application crashes unexpectedly due to memory exhaustion, inspect kernel logs immediately:
sudo dmesg -T | grep -i -E "oom|out of memory|killed process"[Wed Sep 9 11:22:15 2026] Out of memory: Killed process 14205 (mysqld) total-vm:18450124kB, anon-rss:14250100kB, file-rss:0kB, shmem-rss:0kB, UID:27 pgtables:32400kB oom_score_adj:0Protecting Critical Daemons with oom_score_adj
To prevent the kernel from ever terminating a critical management daemon (such as sshd), an administrator can configure oom_score_adj to -1000:
# Find PID of sshd daemon and grant complete immunity from OOM Killer
sudo pkill -0 sshd && echo -1000 | sudo tee /proc/$(pgrep -o sshd)/oom_score_adjSummary
Evaluating Linux memory health requires focusing on available memory rather than raw free memory. By recognizing the performance benefits of the Page Cache, tuning swappiness appropriately for database and virtualization workloads, and auditing dmesg for OOM Killer invocations, Linux systems engineers ensure peak server performance and workload stability.