The right one-liner for a quick RAM check is free -h. The right field to alert on is available, not free. The two are not the same. free is unused RAM. available is free plus the disk cache that the kernel can release at any time. A box with 1% free and 80% buff/cache is fine. A box with 1% free and 80% used is in trouble.
Table of contents
- The free command in one line
- What available means and why it differs from free
- Reading /proc/meminfo directly
- The difference between RAM and swap
- Finding which process is using the most memory
- OOM (out-of-memory) events and how to investigate them
- FAQ
The free command in one line
The free command with the -h flag prints the memory state in human-readable units. The output is a single block:
total used free shared buff/cache available
Mem: 15Gi 3.2Gi 1.4Gi 312Mi 10Gi 11Gi
Swap: 4.0Gi 0B 4.0GiThe columns are explained in the free man page. total is the total physical RAM. used is what the kernel and userspace have allocated. free is unused RAM. shared is memory shared between processes (tmpfs, etc.). buff/cache is the disk cache that the kernel is holding.
The right answer for a sanity check is to look at available. That is the number that says “how much can a new process actually use.” The kernel can release buff/cache at any time when a process needs the memory, so the effective free memory is free + buff/cache minus a small reservation.
The right answer for a monitoring system is to alert on available falling below a threshold. The threshold depends on the workload, but 10% of total is a reasonable starting point. A box with 5% or less available is under memory pressure and will start swapping heavily.
What available means and why it differs from free
The free number is the raw count of pages that the kernel has not allocated. The buff/cache is the disk cache — pages the kernel is using to cache disk blocks, which can be released the moment a process needs the memory.
The right answer for the question “how much memory can my process use” is available. The kernel calculates this as free + reclaimable_cache - kernel_reserve. The exact formula is in MemAvailable in /proc/meminfo.
The wrong answer is to alert on free and assume that a low free means out of memory. The right answer is to alert on available. A box with 1% free and 80% buff/cache has 80% available and is fine. A box with 1% free and 1% buff/cache is in trouble.
A common monitoring mistake is to alert on the percent used. The right answer is to alert on available / total. A box at 95% used is fine if the usage is buff/cache. A box at 95% used with low buff/cache is in trouble. The two cases look the same in the percent-used view but are very different in reality.
Reading /proc/meminfo directly
The free command is a frontend to /proc/meminfo. If you are scripting a monitor, a deployment tool, or a dashboard, read /proc/meminfo directly. The fields you want:
MemTotal— total physical RAMMemFree— unused RAM (same asfreeinfree -h)MemAvailable— memory available to new processes (the right field to monitor)Buffers— block device cacheCached— page cache (this is most of the disk cache)SwapTotal— total swap spaceSwapFree— unused swap spaceDirty— pages waiting to be written to diskWriteback— pages actively being written to disk
The right one-liner to get just the available memory:
grep ^MemAvailable /proc/meminfoThe right one-liner to get available memory as a number (in kB):
awk '/^MemAvailable/{print $2}' /proc/meminfoThe wrong answer is to read MemFree and assume that is the available memory. The right answer is MemAvailable.
The difference between RAM and swap
Swap is disk space that the kernel uses as overflow memory. When physical RAM is low, the kernel writes inactive pages to swap and reads them back when needed. The right answer is to have some swap configured (1-2x RAM is a common starting point) but not to rely on it heavily.
The wrong answer is to disable swap. The right answer is to leave swap enabled and monitor swap usage. A box that is constantly swapping (high si/so in vmstat) is under memory pressure, regardless of how much available it has at the moment.
A common question is how much swap to allocate. The right answer is 1x RAM for a server with predictable workload, 2x RAM for a server with spikey workload, and 0 for a high-performance database server (which wants swap disabled to prevent latency spikes).
The right answer for a database server is vm.swappiness=1 (or 10) — this tells the kernel to prefer dropping the page cache over swapping out process memory. The right answer for a generic server is the default vm.swappiness=60.
Finding which process is using the most memory
The right tool for a quick per-process memory view is top (sort by %MEM with Shift+M) or htop (already sorted by memory). The right one-liner to find the top 10 memory consumers:
ps aux --sort=-%mem | head -11The right answer for a deep investigation is pmap -d <pid> to see the memory map of a specific process, or smem for a more readable view of per-process memory usage including shared memory.
The wrong answer is to use ps and look at the RSS column. RSS (resident set size) is the non-swapped physical memory a process is using, but it does not include shared memory. The right answer for a process that uses shared libraries is to look at PSS (proportional set size), which counts shared memory proportionally. smem shows PSS by default.
OOM (out-of-memory) events and how to investigate them
An OOM event happens when the kernel decides a process is using too much memory and kills it. The OOM killer’s decisions are based on the oom_score of each process, which is proportional to memory usage. The right answer is to see OOM events in dmesg:
dmesg | grep -i 'out of memory'The output shows the process that was killed, its PID, the memory state at the time, and the kernel’s reasoning. The right answer is to see whether the OOM is genuine (a process actually exceeded memory) or spurious (a process was killed because the system was under memory pressure and the OOM scorer picked it).
The right answer for an investigation is to look at the kernel log around the time of the kill and see what was happening. The wrong answer is to assume the killed process is the culprit — sometimes a process gets killed because it has the highest oom_score, which is the process using the most memory, which is not necessarily the process that caused the pressure.
The right answer for a permanent fix is to add more RAM, tune the workload to use less memory, or add swap. The wrong answer is to disable the OOM killer.
FAQ
Why does my box show 16 GB but free -h says 15 GB?
The kernel reserves a small portion of RAM at boot for its own use — typically 1-2% of physical. The reserved memory is in /proc/iomem and is usually labeled System RAM followed by smaller reserved regions. The right answer is that the discrepancy is normal and not a sign of broken hardware.
My available is 0 but the box is still working. Why?
The kernel can release buff/cache at any time. If a process requests memory, the kernel shrinks the cache and grants the request. The available value is calculated assuming the cache is fully reclaimable, so 0 available with high buff/cache is actually fine — the kernel just has not pre-emptively released the cache. The right answer is to alert on available / total falling below 5%, not on available hitting 0.
What is the difference between used and buff/cache in free?
used is memory allocated to processes. buff/cache is memory the kernel is using as a disk cache. The kernel can release buff/cache at any time when a process needs the memory, so the right number for “how much can a new process use” is available, not free. A box with 1% free and 80% buff/cache is fine.
Should I disable swap?
No. The right answer is to leave swap enabled. Swap is the safety net that prevents an OOM kill when memory pressure spikes. The right answer for swap size is 1x RAM for predictable workloads, 2x for spikey workloads, and 0 for high-performance database servers. The right answer for swap behavior is vm.swappiness=10 for a database, default 60 for everything else.
How do I clear the disk cache?
echo 3 > /proc/sys/vm/drop_caches clears the page cache, dentries, and inodes. The right answer is that you almost never need to do this — the kernel manages the cache automatically. The wrong answer is to clear the cache as a regular maintenance task, which just forces the kernel to re-read everything from disk and slow down the system. The right answer is to let the kernel do its job.
Is there a way to see memory pressure in real time?
Yes. vmstat 1 shows memory and CPU stats every second. The right fields to watch are si and so (swap in and out per second), bi and bo (block in and out per second), and us, sy, id, wa (CPU breakdown). The right answer for an interactive view is htop or glances. The right answer for a metrics pipeline is node_exporter (which exports /proc/meminfo and /proc/vmstat to Prometheus) and a dashboard in Grafana.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: