Linux Memory Usage: free, vmstat, ps

Linux memory usage is easiest to understand when you separate three questions: how much memory is available, whether the server is under pressure, and which process is responsible. Use free for the first question, vmstat for pressure over time, and ps -eo pid,comm,%mem,rss --sort=-%mem for process-level attribution.

That order matters on a VPS. Linux intentionally uses RAM for buffers and cache, so “low free memory” is not automatically a problem. The more useful signs are low available memory, active swap, repeated paging, out-of-memory events, and one process growing beyond its expected range.

Key takeaways

• Use free -h for a quick human-readable memory summary.
• Read the available column before panicking about low free memory.
• Use vmstat 1 5 to see whether swap and paging activity are happening now.
• Use ps -eo pid,comm,%mem,rss --sort=-%mem sorted by memory to identify the largest resident processes.
• Treat cache as useful unless it is paired with pressure symptoms.
• For related server checks, read the Virtarix guides to CPU usage on Linux, systemctl basics, VPS backups, and VPS security.

Quick command sequence

Run these in order during a memory incident:

free -h
vmstat 1 5
ps -eo pid,comm,%mem,rss --sort=-%mem | head

The first command tells you whether memory is available. The second shows whether the server is actively swapping or waiting. The third shows which processes are using the most resident memory.

Step 1: Check available memory with free

Run:

free -h

The -h option makes sizes easier to read. The important row is usually Mem:. Focus on these columns:

• total: installed or assigned memory.
• used: memory currently in use, including memory that may be reclaimable.
• free: completely unused memory.
• buff/cache: memory used for buffers and page cache.
• available: estimated memory available for new applications without heavy swapping.

For day-to-day VPS work, available is usually more useful than free. A server can show low free memory and still be healthy because Linux is caching files to improve performance. If available memory is comfortable and swap is quiet, low free memory alone is not a reason to restart services.

Example interpretation

If free -h shows plenty of available memory, your slow application may have a CPU, disk, database, network, or application-level bottleneck instead. If available memory is low and swap is being used heavily, continue with vmstat and process checks.

Step 2: Check pressure over time with vmstat

Run five one-second samples:

vmstat 1 5

vmstat output can look dense, but a few columns are enough for first-pass troubleshooting:

• swpd: memory currently swapped out.
• free: free memory at that sample.
• buff and cache: memory used by buffers and cache.
• si: swap in per second.
• so: swap out per second.
• r: runnable processes waiting for CPU.
• b: processes blocked, often waiting for I/O.

The first line can represent averages since boot, so look at the later interval lines when diagnosing a current incident. If si and so keep moving, the server is actively swapping. Active swapping can make applications feel slow even when CPU usage looks modest.

Step 3: Find memory-heavy processes with ps

Run:

ps -eo pid,comm,%mem,rss --sort=-%mem | head

This lists processes with their process ID, command name, percentage of memory, and RSS. RSS is resident memory: the portion currently in RAM. It is not a perfect measure of total application memory, but it is useful for finding obvious outliers quickly.

If you need the full command line, use:

ps -eo pid,%mem,rss,args --sort=-%mem | head

Long command lines can reveal which worker, queue, script, or runtime is responsible. On a web VPS, common suspects include PHP workers, Node.js processes, Python workers, Java services, database processes, search indexes, backup jobs, and image-processing tasks.

Step 4: Confirm whether swap is a symptom or a safety net

Swap usage by itself is not always an emergency. Some systems keep old idle pages in swap while plenty of RAM remains available. The dangerous pattern is ongoing swap activity during a user-facing slowdown.

Use free -h and vmstat 1 5 together:

• Swap used but si and so are zero: probably historical or idle swap.
• Swap used and si or so keeps changing: current memory pressure.
• Low available memory plus high swap activity: investigate immediately.
• High cache and comfortable available memory: likely normal Linux caching.

If swap activity is active, check what changed recently. A deploy, traffic spike, backup, log parser, database import, or scheduled task can quickly change the memory profile of a small VPS.

Step 5: Decide what to do next

Once you know the pattern, choose the least risky action.

1. If available memory is healthy, keep investigating other resources.
2. If one process is clearly growing, inspect that service’s logs and recent changes.
3. If many workers are using expected memory, reduce concurrency or resize.
4. If swap is active during traffic, add caching or more memory before the next peak.
5. If the process is unknown, confirm ownership before stopping it.
6. If out-of-memory events occurred, capture logs before rebooting.

Avoid blind restarts. Restarting a service can hide evidence, interrupt customers, and make a leak harder to confirm. If you must restart, record the before-and-after memory numbers.

VPS examples

Web workers consume most memory

Use the process snapshot command to identify the runtime and worker count. If each worker is normal but there are too many workers for the plan size, tune concurrency. If one worker is unusually large, inspect requests, plugins, extensions, or job payloads.

Database memory is high

Database processes often use memory intentionally for caches and buffers. Confirm whether the database is slow, swapping, or causing out-of-memory events before lowering settings. A healthy database cache may reduce disk I/O.

Backups cause short pressure windows

Backups, compression, and archive scans can temporarily increase memory usage. If the pattern is predictable, move the job to a quieter time or lower concurrency rather than resizing immediately.

The server killed a process

Look for out-of-memory evidence in system logs, then correlate the time with traffic, deploys, imports, and scheduled tasks. The killed process tells you where to investigate, but the root cause may be a workload spike elsewhere.

Common mistakes

Treating free memory as wasted memory

Linux cache is useful. Do not try to keep free memory high just for the number. Watch available memory and swap activity instead.

Sorting only by percentage

%MEM is helpful, but RSS gives a size you can compare across servers and time windows. Capture both when you are writing an incident note.

Ignoring process count

Many small processes can use more memory than one obvious large process. Check worker counts, queue consumers, and duplicate service instances.

Restarting before collecting evidence

A restart may temporarily fix pressure but erase the pattern. Capture free, vmstat, process snapshots, and logs before intervention when possible.

Memory usage checklist for Linux servers

Before you escalate, save:

1. free -h output.
2. vmstat 1 5 output.
3. ps -eo pid,comm,%mem,rss --sort=-%mem output.
4. Current traffic or job activity.
5. Recent deploys, imports, backups, and cron jobs.
6. Any out-of-memory or service restart messages.

That evidence helps distinguish normal cache, a real leak, a temporary workload spike, and a plan-size problem.

If you want a disposable server for practicing Linux memory usage checks, Virtarix Cloud VPS plans give you an isolated environment for testing free, vmstat, process snapshots, swap behavior, and incident notes before changing production services.

FAQ

What is the best command to check Linux memory usage?

Start with free -h. It gives the fastest system-wide summary, including available memory and swap.

Should I worry when free memory is low?

Not automatically. Linux uses memory for cache. Worry more about low available memory, active swap, out-of-memory events, and application slowdowns.

How do I find which process uses the most memory?

Use ps -eo pid,comm,%mem,rss --sort=-%mem | head. For full command lines, replace comm with args.

What does vmstat show for memory pressure?

Watch si and so. If they keep changing, the server is actively swapping and may be under memory pressure.

Summary

A practical Linux memory usage workflow starts with free -h, confirms pressure with vmstat 1 5, and identifies large processes with ps -eo pid,comm,%mem,rss --sort=-%mem. Read available memory, cache, swap, and RSS together instead of reacting to one column.

For VPS administration, the goal is to decide whether the server is healthy, temporarily busy, leaking memory, or undersized for the workload. Once you know that, you can tune workers, reschedule jobs, optimize the application, or resize with evidence.

Byline: Peter French — Updated 2026-05-18.