How to Check Memory Usage in Linux (Ubuntu Guide)

Keeping an eye on memory usage in Linux is one of the simplest ways to catch a slowdown before it becomes a crash. Whether you’re troubleshooting a sluggish app, sizing a server, or just curious how much RAM is free right now, Ubuntu ships with everything you need — no extra installs required for most of it. Left unchecked, a single runaway process can eat through available RAM, push the system into swap, and drag everything else down with it. This guide walks through the commands that actually matter, from a 5-second snapshot to full historical trend tracking.

Quick Overview: The free Command

The fastest way to check memory usage in Linux is the free command:

free -h

The -h flag makes the output human-readable (MB/GB instead of raw kilobytes). You’ll see six figures: total (installed RAM), used (currently active), free (completely unused), shared (used by tmpfs/shared memory), buff/cache (kernel buffers and disk cache, reclaimable on demand), and available — the number that actually matters, since it estimates how much memory new applications can use without triggering swap. A low “used” number next to a high “buff/cache” number isn’t a problem; Linux is simply caching files to speed things up.

Real-Time Monitoring with top and htop

free gives you a snapshot, but top shows memory usage in Linux as it happens:

top

Press Shift + M to sort processes by memory, and watch the %MEM, VIRT, RES, and SHR columns — RES (resident memory) is the most accurate measure of what a process is actually using in RAM, while VIRT includes memory it could theoretically use, including swap. A process whose RES keeps climbing over time is a good sign of a memory leak.

htop does the same job with a friendlier, color-coded interface:

sudo apt install htop
htop

Press F6 to choose a sort column, or Shift + M for the same quick memory sort. Green, blue, and orange segments in the memory bar represent used, buffer, and cache memory respectively, so you can read your system’s memory usage in Linux at a glance.

Deeper Stats with vmstat and /proc/meminfo

For memory usage in Linux alongside CPU, disk, and swap activity in one view, use:

vmstat -s

This lists total, used, active, and inactive memory, plus swap-in/swap-out (si/so) figures — a rising so value is an early warning that your system is under real memory pressure. For raw data that scripts can parse directly, check:

cat /proc/meminfo

This file is where tools like free pull their numbers from, and it includes fields you won’t find anywhere else, such as Dirty and Committed_AS.

Finding Which Process Is Using the Most Memory

When you need to know exactly what’s eating your RAM:

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

This lists the ten biggest memory consumers by process. For a specific process ID, pmap <PID> breaks down its memory map in detail, and installing smem (sudo apt install smem) gives a more accurate per-process view that accounts for shared libraries instead of double-counting them.

Common Causes of High Memory Usage

Before jumping to conclusions, it helps to know what typically drives memory usage in Linux up in the first place:

• Memory leaks — a process that keeps allocating RAM without releasing it, visible as a RES value in top that only ever climbs.
  
  
• Too many background services — daemons, browser tabs, and startup apps quietly add up over an uptime of several days.
  
  
• Heavy caching — not actually a problem, but often mistaken for one; the kernel uses spare RAM for disk cache and releases it instantly when an app needs it.
  
  
• Undersized hardware for the workload — running containers, VMs, or rendering jobs on a machine that simply wasn’t built for that much concurrent memory demand.
  
  
• Runaway cron jobs or scripts — scheduled tasks that spawn processes faster than they finish, slowly consuming available memory over time.
  

Matching the cause to the right tool above is what turns a vague “my system feels slow” into an actual fix.

Checking Swap Usage

Swap is your safety net when RAM runs out, but relying on it heavily is a performance red flag since disk is far slower than RAM. Check it with:

swapon --show

or look at the Swap row in free -h. If swap usage climbs steadily during normal activity, it usually means your workload has outgrown your installed RAM.

Tracking Memory Trends Over Time with sar

Snapshots are useful, but recurring slowdowns are easier to diagnose with historical data. The sar command (from the sysstat package) logs memory usage in Linux over time, so you can pull up exactly what happened an hour — or a week — ago:

sudo apt install sysstat
sar -r 5 3

This is the tool most sysadmins reach for when a server “felt slow yesterday afternoon” and they need proof.

Automating Memory Checks

For servers you don’t watch all day, a simple cron job can log memory usage in Linux at set intervals so you have a history to check later:

*/10 * * * * free -h >> /var/log/memory.log

Pair this with sar, and you’ll have both a lightweight log and detailed historical data without needing a full monitoring stack.

GUI Tools for Memory Monitoring

If you’d rather not use the terminal, Ubuntu’s built-in GNOME System Monitor (Settings > About, or search “System Monitor”) shows RAM and swap usage with live graphs. KDE users have KSysGuard, and terminal fans who still want visuals can try btop, an even more polished alternative to htop.

What to Do When Memory Usage Is Too High

If you’ve confirmed memory is genuinely the bottleneck — not just cache — a few options help: close unused browser tabs and background services first, since they’re the easiest wins. If a specific process is the culprit, check whether it has a memory leak by watching its RES value grow over time in top. For workloads that are simply too heavy for your current setup — rendering, streaming, or running multiple VMs — the more reliable fix is more headroom rather than constant tuning. A rendering RDP plan or a streaming RDP built with extra RAM removes the bottleneck entirely instead of fighting it process by process. For general workloads that keep maxing out, moving to a reliable dedicated server with more RAM headroom is usually simpler than micromanaging every app.

If you manage several machines and don’t want to check memory usage in Linux manually every day, a managed VPS handles monitoring and scaling for you. And for heavy multi-threaded jobs like compiling, batch processing, or simulations, a multithreading dedicated server is built specifically to handle high concurrent memory and CPU load without choking.

Final Thoughts

You don’t need a dozen tools to stay on top of memory usage in Linux — free -h for a quick check, top or htop for real-time monitoring, and vmstat or sar when you need deeper or historical detail. Learn to read the “available” figure instead of panicking over “used,” and you’ll catch real memory pressure long before it turns into a crash. Bookmark this guide, and the next time something feels sluggish, you’ll know exactly which command to run first.

Frequently Asked Questions