Skip to main content
A slow Linux server with high load has more work queued than it can handle. Compare the load average from uptime with the number of CPU cores from nproc: a load well above the core count for minutes means overload. Then run top to see whether one process eats the CPU, the disk is too busy (wa), memory is swapping, or the hypervisor is short of CPU (st), and fix that cause.

​
Before you start

  • If SSH is too slow to use, log in through the VNC console, and look at the graphs in resource usage.
  • The three load numbers are averages over 1, 5 and 15 minutes. Rising numbers mean it is getting worse. See what is load average.
  • Commands use sudo. As root, leave it out.

​
Step 1: Is the load really too high?

On a server with 4 cores, a load of 4 means fully busy and 9.84 means work is waiting. A load below the core count is usually fine, even if it looks big.

​
Step 2: Read the CPU line in top

Press P in top to sort by CPU, M to sort by memory, and q to quit.

​
Cause 1: A process uses all the CPU

Check:
Fix: depends on what it is:
  • Your app or game server after an update or under heavy use: restart it (sudo systemctl restart myapp), check its log, and cap it if needed with CPU and memory limits.
  • A stuck script or cron job (php, python, backup.sh): stop it with kill and fix the schedule.
  • A process you don’t recognise, with a random name or running from /tmp: treat it as a possible compromise. Follow what to do if your server is hacked.

​
Cause 2: The disk is the bottleneck

High wa and processes in state D (waiting for the disk) mean storage can’t keep up. Check which disk is busy and which process causes it (both tools come in the sysstat package: sudo apt install sysstat or sudo dnf install sysstat):
In iostat, a %util near 100 and a high w_await or r_await (milliseconds) show an overloaded disk. pidstat -d lists processes by kB_rd/s and kB_wr/s. Fix: move backups and large copies to quiet hours, add database indexes for slow queries, and stop swapping (Cause 3). See check disk I/O performance.

​
Cause 3: Memory is full and the server swaps

When RAM runs out, Linux moves memory to swap on disk, which is very slow. Check:
Values that stay above 0 in the si and so columns (swap in and out) mean active swapping. Fix: lower the memory settings of the largest programs or add RAM. See processes killed by the OOM killer and check memory usage.

​
Cause 4: A traffic spike or attack

Many visitors, a crawler or a flood of requests creates many web or PHP workers. Check:
The second command counts requests per IP (use /var/log/apache2/access.log or /var/log/httpd/access_log for Apache). Fix: block abusive IPs, rate-limit with Fail2ban or CrowdSec, add caching, and use the DDoS filters for network floods.

​
Cause 5: CPU steal time

st is CPU time your VPS wanted but the host gave to other work. A few percent now and then is normal. Check:
The st column under cpu shows it each second. Fix: if st stays high (for example above 10%) for a long time while your own usage is normal, open a ticket with the vmstat output and the time it happened.

​
How to check it worked

The 1-minute load should drop below your core count within a few minutes of the fix, followed by the 5- and 15-minute values.

​
Frequently asked questions

​
Load is high but CPU is idle. How?

Load also counts processes waiting for the disk (state D). High load with high wa and low us points to storage, not CPU (Cause 2).

​
What load is “too high” for my server?

Divide the load by nproc. Up to about 1.0 per core is busy but fine. Consistently above that, work waits and the server feels slow.

​
Should I just reboot?

A reboot clears the symptom, not the cause. Collect the top and vmstat output first so you can find out why it happened.

VPS and dedicated server guides

Every guide in this section.

What is load average?

The three numbers explained.

Find what uses CPU

Track down busy processes.

Monitor with htop

A friendlier live view.

Check disk I/O performance

Measure and read iostat.
Checked against the official procps top, vmstat and proc_loadavg manuals and the sysstat documentation on 4 November 2026; every command on this page was run on Ubuntu 24.04 LTS to confirm its syntax and output columns. The ticket threshold for steal time is a rule of thumb, not a FREAKHOSTING limit.

​
Need Extra Help?

If you encounter any issues, our support team is ready to assist:

​
Save on Your Hosting

Ready to upgrade your hosting? Use code KB20 at checkout for 20% off your first order!
Last Updated: November 2026