High CPU or memory usage: find the cause and fix it

A slow server is always busy with something: computing, waiting for the disk, swapping memory or waiting for the hypervisor. This guide shows you how to see which one, find the process behind it and fix it. Commands are for Ubuntu and Debian; a Windows section follows.

Before you start

• Log in over SSH, or through the web console if the server is too slow for SSH.
• Note when the slowness happens. A problem at 03:00 every night points to a scheduled job; one at peak hours points to traffic.

Step 1: Get the overview

uptime
nproc
top

• Load average (uptime, three numbers for 1, 5 and 15 minutes): compare it with nproc. Below the CPU count is fine; well above for a long time means tasks are waiting.
• In top, the CPU line shows where time goes: us user programs, sy the kernel, wa waiting for disks, st steal time. Press P to sort by CPU and M to sort by memory; q quits.

Read the pattern:

Step 2: Find the processes

ps -eo pid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 15
ps -eo pid,user,%cpu,%mem,rss,cmd --sort=-%mem | head -n 15

For a service, see its own resource use and logs:

systemctl status nginx
sudo journalctl -u nginx --since "30 minutes ago"

Typical fixes:

• A web application under load: caching, fewer or slower PHP-FPM workers so they fit in memory, database indexes for slow queries.
• A stuck job: restart the service with sudo systemctl restart and the service name, then find out why it hung.
• A scheduled job at the wrong time: move backups or reports to quiet hours (crontab -l, systemctl list-timers).
• An unknown process you did not start: do not just kill it. See what to do if your server is hacked.

Step 3: Check memory and swapping

free -h
vmstat 1 10

In free -h, the available column is what programs can still use; free being low is normal because Linux uses spare memory as cache. In vmstat, non-zero si and so columns mean the server swaps actively, which makes everything slow.

Check whether the kernel had to kill processes:

sudo journalctl -k | grep -i -E 'out of memory|oom-kill'

Pressure stall information shows how long tasks waited for memory or I/O (if your kernel has PSI enabled):

cat /proc/pressure/memory
cat /proc/pressure/io

Step 4: Fix memory problems

Limit the memory of a service

systemd can cap a service so it cannot take the whole server:

sudo systemctl set-property myapp.service MemoryMax=1G

Replace myapp.service with the unit name. When the service exceeds the limit, only it is affected.

Add a swap file

Swap does not replace memory, but it gives the server room for short peaks instead of killing processes. On ext4:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Verify: swapon --show lists /swapfile, and free -h shows the swap. On Btrfs, a swap file needs special preparation; check your file system with df -T / first.

Step 5: When the plan is the limit

If your applications are tuned and the server still runs out of CPU or memory at normal load, or steal time stays high at your busy hours, the workload has outgrown the plan. Move to a bigger plan or line: upgrade or downgrade a service and VPS vs VDS vs dedicated server.

Windows Server

• Task Manager (Ctrl + Shift + Esc) › Processes and Performance; Resource Monitor (resmon) shows CPU, memory, disk and network per process.
• In PowerShell, list the top consumers:

Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, Id, CPU, WorkingSet
Get-Counter '\Processor(_Total)\% Processor Time' -SampleInterval 2 -MaxSamples 5

• Check Event Viewer › Windows Logs › System for low-memory warnings (resource exhaustion events).
• Windows Update and Defender scans cause short peaks after restarts; sustained load usually comes from an application or SQL Server.

Troubleshooting

top shows high load but low CPU use. Tasks are waiting for disks (wa) or are stuck in uninterruptible I/O. Check iostat -x 1 5 (package sysstat) and whether the disk is full: disk full.

The server becomes unreachable at peak times. Memory runs out and the OOM killer stops important services. Limit services, add swap or move to a bigger plan.

Load is high every night. Backups, log rotation or updates run at that time. Spread them out.

Next steps

• Website returns errors under load? Website 502, 503 and 504 errors.
• Measure before you upgrade: VPS vs VDS vs dedicated server.