Support > About cloud server > 12 Free Linux Commands for Checking Memory Usage: From Global Overview to Granular Detail
12 Free Linux Commands for Checking Memory Usage: From Global Overview to Granular Detail
Time : 2026-11-04 16:46:25
Edit : Jtti

In the daily operation and maintenance of Linux servers, memory is the most frequent "trouble spot" for system failures. Once physical memory is exhausted, the consequences range from system sluggishness—triggered by swapping—to the "OOM Killer" (Out-of-Memory Killer) forcibly terminating critical processes, which can cause an immediate service outage.

While powerful monitoring systems like Zabbix and Prometheus are widely available, knowing a few native, free-to-use command-line tools can help you pinpoint issues the very second a problem arises. Below are 12 battle-tested Linux memory diagnostic commands, covering everything from high-level system overviews to granular, process-level analysis.

Global Perspective: Assessing Overall Memory Usage

1. `free -h` (The classic high-level overview)

free -h

This is the essential first step for any memory troubleshooting. Focus on the `available` column rather than the `free` column. Linux utilizes idle memory for caching (buff/cache); the `available` figure provides a more accurate estimate of the memory actually accessible to applications.

2. `cat /proc/meminfo` (The most detailed kernel-level data)

cat /proc/meminfo | head -n 15

For the rawest and most comprehensive data, look at this virtual file. It contains detailed information on memory allocation from the kernel's perspective, including `MemFree`, `Buffers`, `Cached`, and `Dirty` (memory pages waiting to be written to disk).

3. `vmstat` (Distinguishing between computational bottlenecks and I/O bottlenecks)

vmstat 1

Beyond checking the `free` column, pay close attention to the `si` (swap-in) and `so` (swap-out) columns. If these values ​​remain consistently above zero, it indicates that physical memory is exhausted and the system is relying on the hard drive to stay afloat. Additionally, a spike in `wa` (I/O wait) is often a side effect of frequent swap operations caused by insufficient memory.

4. `sar -r` (Analyzing historical memory trends)

sar -r 1 5

Part of the `sysstat` package. Its strength lies in its ability to look not only at the present but also at the past (via files in `/var/log/sa/saXX`). Focus on the `%memused` and `kbmemfree` metrics; this is ideal for investigating retrospective issues, such as "why did memory usage suddenly spike in the middle of last night?"

Real-time Monitoring: Like a Dashboard

5. `top` (The classic real-time monitoring tool)

top

Once inside, press the `M` key to sort processes by memory usage (highest to lowest). By observing the `MiB Mem` section at the top, you can quickly determine whether memory is being consumed by user-space processes (`us`) or the system kernel (`sy`).

6. `htop` (A more intuitive, modern monitoring tool)

htop

Featuring color-coded progress bars, it provides an exceptionally intuitive view of CPU and memory usage. You can use your mouse or arrow keys to navigate the process list and examine detailed memory consumption.

7. `glances` (An all-in-one dashboard)

glances

A cross-platform monitoring tool written in Python (installable via `pip install glances` or through `yum`/`apt`). It consolidates CPU, memory, disk, network, and process information onto a single screen, even highlighting potential bottlenecks.

Pinpointing the Culprit: Identifying What’s "Eating" Your Memory

8. `ps aux --sort=-%mem` (Precise process sorting)

ps aux --sort=-%mem | head -n 10

Without needing to enter an interactive interface like `top`, this command sorts processes by memory usage percentage in descending order, instantly revealing the top 10 memory-consuming processes. This is typically the first step in tracking down the source of a memory leak.

9. `smem` (Seeing through the facade of shared memory)

smem -tk

Traditional `ps` commands often overstate memory usage by double-counting memory shared across different processes. `smem` introduces the concepts of PSS (Proportional Set Size—accounting for shared memory proportionally) and USS (Unique Set Size—memory exclusive to a single process), providing an accurate picture of exactly how much physical memory each application is truly consuming. 10. `pmap` (Deep dive into a specific process's memory layout)

pmap -x <PID> | tail -n 1

Once you have identified a suspicious process (such as a Java or Node.js application), you can use `pmap` followed by its PID to gain insight into its memory address space—for instance, to check if the heap is unusually large or to see how many shared libraries have been loaded.

Kernel and Crisis Troubleshooting: Uncovering Hidden Resource Consumption and Crash Logs

11. `slabtop` (Investigating kernel memory leaks)

slabtop

Often, user-space processes may appear to have normal memory usage, yet total system memory consumption remains high; this could indicate a leak in kernel objects (Slab cache). Much like `top`, `slabtop` provides a real-time view of kernel object allocation, helping you detect if caches—such as `dentry` or `inode` caches—have spiraled out of control.

12. `dmesg | grep -i oom` (Reconstructing the incident)

dmesg -T | grep -i "out of memory"

If your website suddenly returns 502 errors and services restart automatically, it is highly likely that the OOM (Out-Of-Memory) Killer has intervened. This command retrieves kernel logs, clearly showing exactly when a specific process (including its name and PID) was forcibly terminated by the system for consuming excessive memory.

These 12 commands cover a comprehensive range of troubleshooting dimensions—from macro to micro, and from current status to historical records. However, as an operations professional, you must face a sobering reality: identifying which process is consuming all the memory does not always solve the root cause.

Even if your application code is perfectly optimized, issues such as server oversubscription—where the actual available physical memory is far lower than the advertised capacity—or sudden traffic spikes can still drain memory instantly, causing your application to crash due to a lack of underlying resources.

While memory troubleshooting demonstrates technical acumen, choosing Jtti provides a rock-solid foundation for your business. Visit the official Jtti website to explore high-performance cloud server configurations—ideal for high-concurrency, memory-intensive applications—and access test IPs.

Relevant contents

A Practical Guide to Installing Kubernetes Gateway API: From CRDs to Traffic Shifting—The Next-Generation Gateway Replacing Ingress How to Disable IPv6 and Use Only IPv4 on CentOS: A Guide to Layered Configuration and Verification Is your Linux server’s average load too high? Keep this guide handy—it covers everything from troubleshooting to resolution. How to Troubleshoot Linux Memory Leaks? A Comprehensive Practical Guide: From Monitoring to Pinpointing the Issue Why Do Small Packets with High PPS Cripple a VPS More Than High Bandwidth Does? — Soft IRQs, RPS, and Network Interface Packet Reception Optimization Why Do Cloud Servers Receive "Unexpected" UDP Broadcasts? A Guide to Identifying and Troubleshooting Layer 2 Leaks Is the time on your US-based VPS always inaccurate? A complete guide to synchronizing your server's network time via the command line. Only 20% bandwidth used, yet CPU at 100%? Uncovering the "hidden killer" behind server lag. Beyond "Vibe Coding," why is Harness Engineering more important than prompting? Ensuring AI Coding Agents "Survive" in the Cloud: Engineering Practices for Persistence, Orchestration, and Network Reliability
Go back

24/7/365 support.We work when you work

Support