Diagnosing Linux Memory Issues with free and vmstat
When a Linux server starts swapping heavily or applications suddenly slow to a crawl, the first instinct for many administrators is to reach for graphical monitors. On headless RHEL, CentOS, and Fedora hosts, the fastest path to clarity usually sits in two venerable utilities: free and vmstat. They ship with every install, require no extra packages, and output enough data to identify the underlying cause of most incidents.
Running these tools is second nature for sysadmins in places like Sydney's Macquarie Park tech corridor or the Brisbane hosting scene, where clusters of enterprise workloads hum along and a memory hiccup can drag dozens of services with it. A short session over a serial console from a Melbourne NOC is often enough to identify whether the issue is genuine memory exhaustion, runaway cache growth, or simply aggressive swapping caused by a misconfigured kernel parameter.
The strength of free and vmstat is that they speak the same language as the kernel itself, drawing their figures directly from /proc/meminfo and the same internal counters that monitoring stacks eventually sample. A focused reading of both utilities, in the right order, will give you a clearer picture than any dashboard in the first few minutes of an incident.
Interpreting Output from free
The free command summarises the state of physical memory and swap in a compact table. The columns that matter most are total, used, free, shared, buff/cache, and available. A common misconception among newcomers is that the free column represents how much memory is genuinely available; in reality, much of the buff/cache figure is reclaimable on demand, which is why the available column is usually the better indicator of headroom.
For interactive work, running free -h produces human-readable values using powers of two, which suits most modern servers with tens or hundreds of gigabytes of RAM. When scripting or feeding values into alerts, however, the raw free -b output integrates more reliably with monitoring agents common to local providers operating from Perth and Adelaide data centres.
Making Sense of vmstat Memory Columns
The vmstat utility adds a dynamic element by sampling memory and CPU counters at regular intervals. The memory section reports swpd, free, buff, and cache, while the swap columns si and so tell you how many blocks per second are moving between RAM and disk. Sustained non-zero values for si and so are the clearest signal that the kernel is thrashing and that real workloads are suffering.
Running vmstat 2 5 produces five samples at two-second intervals, which is enough to see whether pressure is transient or chronic. For environments where AEST logging timestamps can confuse short-window analysis, the -t flag adds a human-readable timestamp to each row.
| Aspect | free | vmstat |
|---|---|---|
| Output style | Single snapshot | Repeated samples over time |
| Primary focus | Memory totals and availability | Memory, swap activity, CPU queues |
| Source data | Reads /proc/meminfo | Reads /proc/meminfo and /proc/stat |
| Best use case | Quick capacity check | Tracking pressure trends |
| Key columns | total, used, available | si, so, bi, bo |
Spotting Swap Pressure and Cache Behaviour
When vmstat shows persistent swap-in and swap-out traffic, the kernel is moving pages to disk because RAM is genuinely scarce. This is distinct from a high cache figure in free, which usually indicates the kernel is using spare memory for filesystem caching and will surrender it instantly when applications need it. The two scenarios look similar at a glance but require opposite responses.
Tuning /proc/sys/vm/swappiness is often the first lever. On database-heavy hosts in Australian financial services, a value of 10 keeps the kernel from swapping aggressively, while on file servers it can remain at the default 60 without issue. Always confirm with vmstat afterwards to verify the change took effect. On older RHEL systems, an iptables ruleset with extensive connection tracking can also balloon cache use, a situation the iptables firewall guide covers in detail for legacy boxes.
Common Memory Bottleneck Scenarios
A frequent culprit is an application with a slow leak, often a Java or Python service that gradually consumes more of its cgroup limit until the OOM killer triggers. Another is kernel slab growth, visible through /proc/slabinfo but hinted at by a steadily shrinking available figure in free. NUMA-aware workloads on multi-socket servers can also suffer when memory is bound to the wrong node, a problem more common on the larger dual-socket servers found in Sydney enterprise racks.
Pairing with Other Tools for Deeper Insight
Once free and vmstat point you in the right direction, deeper analysis usually requires top, htop, smem, or a direct look at /proc/meminfo. For historical trending, sar collected over weeks will reveal whether the current behaviour is new or part of a slow drift. When you need to confirm a fix under realistic load, run web load tests against the service from a region close to your users, since memory behaviour often shifts once genuine traffic patterns are applied.
For a broader view of command-line tooling and related system administration topics, the https://linuxtpoint.com/ homepage collects the kind of references worth bookmarking.
The practical habit to take away is this: when memory trouble hits, run free once for the snapshot, then vmstat with a short interval for the trend, and only reach for heavier tools once those two outputs have told you what kind of problem you are dealing with.