Why Is My Server Slow? Finding Performance Problems
Why is my server slow? Steps to find Linux slowdowns caused by CPU, RAM and swap, disk, network or the app with uptime, htop, free, iostat and dmesg.
When a server slows down, the cause is almost always one of four resources: the CPU, memory (RAM), the disk or the network. Sometimes the problem is none of these but the application itself. With the right commands, you can find which one is the bottleneck in a few minutes and fix it based on data, not guesswork.
This guide covers how to find out step by step why a Linux server is slow, which command to use to check each resource and fixes for the most common problems.
First look: uptime and load average
After connecting to the server with SSH, the first command is:
uptime
The three numbers at the end of the output are the load average: the average load over the last 1, 5 and 15 minutes. These numbers show the count of tasks that are using the CPU or waiting their turn (including those stuck on the disk or network), and they're read together with the number of cores:
nproc
- If the load average is below the number of cores, the server is comfortable.
- If it's close to the number of cores, the CPU is running at full capacity.
- If it's clearly above the number of cores, work is waiting in line; there's a bottleneck somewhere.
If the 1-minute value is much higher than the 15-minute value, the problem has just started; the opposite means the load is going down.
CPU
htop
htop shows how busy the CPU cores are, memory usage and the processes using the most resources, live (if it isn't installed, run sudo apt install htop). Press F6 to change the sort order and find the process using the most CPU.
Things to watch for:
- A single process using one core at 100%: Game servers and many applications do their main work on a single core. Even if total usage looks low, the application slows down when that core is full. In this case, a CPU with high single-core speed makes a difference.
- All cores are full: The server is doing more work than it can handle. Look at which processes are creating the load.
- Unexpected processes: A process you don't recognize that constantly uses CPU can be a sign of a compromised server (for example, malware mining cryptocurrency).
The st (steal) value in the top output shows the time the CPU on a virtual server spends waiting on other work instead of yours. If you see a constantly high steal value, contact your provider.
Memory (RAM) and swap
free -h
In the free output, look at the "available" column. Because Linux uses idle memory as disk cache, it's normal for the "free" value to look low; the memory your applications can actually use is the "available" value.
When memory runs short, two things happen:
- Swap usage goes up. Because swap lives on disk, it's much slower than RAM and the server becomes noticeably sluggish.
- The OOM killer steps in. When memory fills up completely, the kernel forcibly kills a process to keep the system running. If your application shuts down "on its own", this is most likely the reason:
sudo dmesg -T | grep -i "killed process"
Adding a swap file: On small servers with no swap, you can add a swap file to keep applications from being killed during short memory spikes:
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
Swap is a safety net, not a fix. If the server is using swap all the time, the real fix is to reduce memory usage or move to more RAM.
Disk
Disk space: A full disk is behind the strangest errors on a server; the database can't write, logs stop and applications crash.
df -h
df -i
sudo du -sh /var/* | sort -h
df -h shows disk space and df -i shows the file count limit (inodes); millions of small files can use up the inodes even when the disk looks empty. The du command helps you find the folders taking up the most space; the most common culprits are old logs, backups and unused Docker images.
Speed and waits: If the disk isn't full but the server is slow, look at disk waits:
sudo apt install sysstat
iostat -x 2
If the %util column stays close to 100 and the await values are high, the disk can't keep up. A high wa (iowait) value in the top output means the same thing. To see which process is loading the disk, you can use sudo iotop. Heavy database writes, large backups and log files that grow without limit are typical causes.
Network
If the server's resources look fine but users are seeing slowness, the problem may be in the network:
- Latency and packet loss: Use
mtrto measure every hop toward an address where your users are. We explain where latency increases in our What is ping? article. - Bandwidth usage: See the server's live traffic with
nloadoriftop. Unexpectedly high traffic can be a sign of an attack or a large backup. - Connection count:
ss -sshows the total number of connections. An unusual number of connections can be a symptom of a DDoS attack; we explain the types of attacks in our What is DDoS? article.
Slowness caused by the application
If all resources look normal, the problem is most likely inside the application:
- Check the logs.
journalctl -u service-name -for the application's own log file shows errors and warnings. - Slow database queries: Turn on MariaDB's slow query log and find which queries take a long time; a missing index is often all it takes to fix it. We cover its settings in our How to install MariaDB guide.
- External services: An API or payment service that doesn't respond makes pages load slowly even while your server is idle.
- Game servers: Lots of plugins, large worlds and servers that haven't been restarted in a long time make the tick time longer. We cover regular restarts in our What is cron? article.
- Websites: For missing caching and heavy pages, take a look at our How to speed up a website guide.
Quick troubleshooting table
| Symptom | Command to check | Possible fix |
|---|---|---|
| Load average above the number of cores | htop | Find the process creating the load and optimize |
| One core constantly at 100% | htop | Optimize the application, faster CPU |
| The application shuts down on its own | dmesg -T | Reduce memory usage, add more RAM |
| Swap is used all the time | free -h | Add more RAM |
| Disk is full | df -h, du -sh | Clean up logs and old backups |
| High iowait | iostat -x, iotop | Schedule disk-heavy jobs, faster disk |
| Resources normal, users see slowness | mtr, ss -s | Check the network path and possible attacks |
Performance on Nodesty servers
Nodesty AMD Ryzen 9 9950X VPS plans, with single-core speeds up to 5.7 GHz, suit game servers and applications that rely on a single core, while AMD EPYC 7763 VPS plans, with their large amounts of RAM, suit databases and many services. All plans include NVMe storage and L3–L7 nShield DDoS protection. CPU usage on virtual servers is subject to our Fair Use Policy; if your resources aren't enough after optimizing your application, moving to a bigger plan is the fastest fix.
Frequently Asked Questions
What load average means there's a problem?
Load average is read together with the server's number of cores. On a 4-core server, a value around 4 means the CPU is fully busy, and values clearly above that mean work is waiting in line. You can find the number of cores with the nproc command.
My RAM usage shows 90 percent. Is that a problem?
Usually not. Linux uses idle memory as disk cache and releases it when needed. The available column in the free -h output shows the memory your applications can actually use. The problem is when the available value drops very low and swap usage keeps growing.
Does adding swap fix a lack of RAM?
Swap is a safety net that keeps applications from being killed when memory fills up for a short time, but because it lives on disk, it's much slower than RAM. If the server is using swap all the time, the real fix is to reduce the application's memory usage or move to more RAM.
My application shuts down on its own. Why?
When memory fills up completely, the Linux kernel kills one of the processes using the most memory to keep the system running; this is called the OOM killer. The command sudo dmesg -T | grep -i killed shows which process was killed and when. The fix is to reduce memory usage or add more RAM.
The server is slow but resource usage looks low. Why?
The problem may be in the network, the disk or outside the server. Check network latency with mtr and disk waits with iostat. On websites, a slow database query or an external service that doesn't respond also makes pages load slowly while the server is idle.
How do I know if I need to move to a bigger plan?
If, even after optimizing your application, the CPU is constantly high, available memory regularly runs out and swap gets used, or the disk is always busy, your resources aren't enough for your workload. In that case, moving to a plan with more cores, RAM or disk is the fastest fix.
About the author
Nodesty Team · Infrastructure & Support
The Nodesty team runs our servers, network and DDoS protection day to day and answers customer support requests around the clock. These guides come from that work.
Related articles
How to Upgrade Ubuntu Server to the Next LTS Release
How to upgrade an Ubuntu server to the next LTS release: backups, preparation, do-release-upgrade, SSH access, post-upgrade checks and a clean install.
What Is a Load Balancer and How Does It Work?
What is a load balancer and what does it do? Balancing methods, health checks, session handling, load balancing with Nginx, HAProxy and when you need one.
How to Deploy a Laravel App to a VPS
How to deploy Laravel to a server: PHP-FPM, Composer, .env, the database, file permissions, Nginx, queue workers, the scheduler, SSL and shipping updates.