Linux Commands to Diagnose Server Performance Issues Caused by Low Memory

𑇐 A practical user guide for WordPress and LAMP administrators running on a small VPS.

Tatiana Timonina

November 4th, 2026 𑇐 10 min read

Introduction

Some server problems never show up as an obvious error. Your website keeps loading, WordPress still lets you log in, and everything looks relatively normal. Behind the scenes, though, your Linux server may be struggling with one of its most important resources: memory (RAM).

I ran into this on a WordPress website hosted on a DigitalOcean Ubuntu VPS. Saving changes in the WordPress admin didn’t always work, and image uploads for new blog posts were unreliable. I only connected the dots when a routine package installation during a PHP upgrade stalled. Investigating the server showed that it was running low on memory and disk space, and that the kernel’s Out-Of-Memory (OOM) Killer can terminate processes when RAM runs out.

The lesson: on a VPS, memory management matters as much as CPU performance. This guide walks through six commands to check whether your server is under memory pressure, identify the cause, and respond safely.

Who this guide is for: anyone running WordPress or a LAMP/LEMP stack on a small Ubuntu VPS who sees slow pages, failed saves, failed uploads, or package installations that stop unexpectedly.

Why memory problems are easy to miss

WordPress, PHP, the web server, and the database all share the same limited pool of RAM. A single image upload can involve several steps at once:

1. PHP receives the upload request.
2. The image is stored temporarily.
3. WordPress processes it and may generate additional image sizes.
4. PHP talks to the database.
5. The web server and PHP keep handling other visitors.

On a VPS with limited RAM, these overlapping operations can create real memory pressure. Maintenance tasks such as package installs and upgrades add to the load. They do not necessarily cause the problem, but they can expose a limit that was already there.

Typical warning signs

• Changes in the WordPress admin sometimes fail to save.
• Image uploads fail or stop partway.
• Admin operations take longer than expected.
• Package installations hang or stop unexpectedly.
• Services restart or disappear without a clear error.

Quick reference

#1 free -h 
'''Total, used, and available RAM, plus swap use'''

#2 swapon --show
'''Whether swap is enabled and how large it is:'''

#3 ps aux --sort=-%mem | head -n 10
'''Which processes use the most RAM'''

#4 sudo journalctl -k | grep -i -E "out of memory|killed process"
'''Whether the OOM Killer has terminated anything'''

#5 df -h /
'''Free disk space (needed for swap, updates, and logs)'''

#6 sudo du -xhd1 /var
'''Which directories consume the most disk space''' 

Run them in this order. Commands 1 to 4 look at memory directly. Commands 5 and 6 check disk space, which matters because swap lives on disk and a full disk causes problems of its own.

Step 1. Check available memory

sudo free -h

This is the fastest way to see how your server is doing. Look at these columns:

• total: the RAM installed on the server.
• used: memory currently in use.
• available: the estimate of RAM that can be given to new processes without swapping. This is the number to watch.
• Swap: whether swap exists and how much of it is in use.

What to look for: consistently low available memory signals memory pressure. In my case, the server had 961 MiB total but only about 45 to 48 MiB available, and no swap. That is a server with no breathing room.

Note: don’t judge by the “free” column alone. Linux uses spare RAM for caching, so “free” is often small on a healthy system. “Available” is the honest figure.

Step 2. Check whether swap is enabled

sudo swapon --show

If the command prints nothing, there is no active swap. If it lists a file or partition, swap is enabled, and you can see its size.

Why swap matters: swap lets Linux use disk space as overflow when physical RAM runs low.

• A safety buffer. Short memory spikes (an image upload, a backup, a package upgrade) can be absorbed instead of triggering the OOM Killer.
• Fewer abrupt terminations. Processes are less likely to be killed mid-task.
• Cheap insurance. On a small VPS, a modest swap file costs only some disk space.

What swap is not: disk is much slower than RAM. Heavy, constant swapping makes a server sluggish. Treat swap as a safety net, not a substitute for adequate RAM.

Step 3. Identify the processes consuming RAM

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

This lists the ten processes using the most memory. Check the %MEM and RSS columns (RSS is the actual memory in use, in KB) and the COMMAND column.

On a WordPress server, the usual suspects are:

• Apache or Nginx worker processes
• PHP-FPM workers (or Apache with mod_php)
• MySQL or MariaDB
• Background tasks and other system services

What to look for: many copies of the same process (for example, a long list of PHP-FPM or Apache workers) or a single process using a very large share of RAM. These point to settings that need tuning, covered in the best practices below.

Step 4. Check whether the OOM Killer has acted

sudo journalctl -k | grep -i -E "out of memory|killed process"

When the server truly runs out of memory, the kernel’s OOM Killer terminates a process to keep the system alive. This command searches the kernel log for those events.

• Matches found: the server has run out of memory. The log line names the killed process, which often explains the failed save or upload you saw.
• No output: no OOM events are in the retained logs. That is good news, but it is not proof, because old journal entries may have been removed.

Step 5. Check available disk space

sudo df -h /

Memory and disk are connected. You need free disk space to create a swap file, install updates, and store logs. Look at Avail and Use%.

What to look for: a root filesystem above roughly 85 to 90 percent full. In my case, the disk was 89 percent used with only 1.1 GB free, which left little room for anything else.

Step 6. Find what is using the disk

sudo du -xhd1 /var

This shows the size of each directory directly under /var, where logs, caches, databases, and website files typically live. The -x option keeps the scan on one filesystem, and 2>/dev/null (optional) hides permission noise.

Two related checks are worth running:

sudo journalctl --disk-usage

sudo dpkg --audit

The first shows how much space system logs use. In my case, the journal alone took about 928 MB. The second reports any packages left in an incomplete state, which helps if an install or upgrade stalls.

Important: never delete files directly from /var/lib or /var/www to free space. These directories can hold databases, website files, and package-management data.

Recover disk space safely

If logs and caches are the problem, clean them with the tools built for the job:

sudo journalctl --rotate

sudo journalctl --vacuum-size=100M

sudo apt clean

df -h /

In my case, this recovered about 1 GB, taking free space from 1.1 GB to 2.1 GB.

Before you vacuum: this removes historical logs. If you need them for auditing or incident investigation, export or back them up first.

Add emergency swap space

If swapon –show prints nothing and you have enough free disk, create a swap file. This example creates a 512 MB file, which suits a small VPS. Choose a size that fits your RAM and disk.

1. Check that no swap file already exists

ls -lh /swapfile

2. Allocate the file

sudo fallocate -l 512M /swapfile

3. Set secure permissions

sudo chmod 600 /swapfile

4. Format it as swap

sudo mkswap /swapfile

5. Enable it

sudo swapon /swapfile

6. Verify

free -h

swapon --show

Make swap persistent after reboot

First, check whether an entry already exists:

grep -n "/swapfile" /etc/fstab

If nothing is returned, add exactly one entry:

echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab

This makes Ubuntu activate the swap file at startup.

Key points to remember

• Watch “available,” not “free.” Available memory is the real indicator of pressure.
• Slow or failing WordPress operations can be a memory problem, not only a WordPress or plugin problem.
• No swap means no buffer. A small swap file can mean the difference between a brief slowdown and a killed process.
• Swap is a safety net, not extra RAM. Constant heavy swapping means you need to tune or upgrade.
• Disk and memory are linked. A nearly full disk limits swap, updates, and logging.
• Clean up with the right tools. Use journal and APT commands rather than deleting files by hand.
• Logs are evidence. Export them before vacuuming if you may need them later.
• Empty OOM results are not a guarantee. Old log entries may already be gone.

Best practices for VPS memory

• Tune PHP-FPM. Set pm.max_children to a value your RAM can actually support. Too many workers commonly cause memory exhaustion.
• Disable unnecessary PHP extensions to reduce per-process memory.
• Configure OPcache appropriately so PHP does not recompile scripts on every request.
• Review MySQL/MariaDB memory settings, since the defaults may not suit a small server.
• Monitor regularly. Run free -h and df -h / as part of routine maintenance, and check the heaviest processes if the server feels slow.
• Set journal retention limits so logs do not quietly fill the disk again.
• Back up before maintenance. Take site, database, and configuration backups before upgrades, and schedule a maintenance window for production changes.
• Add swap as a buffer, then keep monitoring.
• Upgrade your VPS RAM when the workload genuinely requires it. Tuning and swap have limits. If memory pressure continues after you have optimized, a larger plan is the right fix.

Conclusion

Memory trouble on a VPS is easy to mistake for a WordPress, plugin, or package problem. These six commands give you a quick, safe way to tell the difference: check RAM, check swap, find the heaviest processes, look for OOM events, and confirm you have the disk space to work with. Make them part of your routine maintenance, and you will catch memory pressure before it turns into failed uploads or interrupted upgrades.