What to Do When My Root Server or VPS Is Lagging?

Your server is responding slowly, connections are hanging or services are sluggish? This guide helps you systematically find the cause and fix it. We go step by step from the most common to the more specific causes.

Note: Detailed subpages on monitoring and optimization can be found in the left navigation.

1. Check current resource usage

Your first look should always be at current server usage. Connect via SSH and run the following commands:

htop – the most important starting point

htop

Here you can see CPU and RAM usage in real time. Unlike the simpler top, htop shows colored bars and can be operated with the mouse. Watch for:

• CPU usage: The top bars show usage per core. If one core is constantly at 100% and the others are almost idle, you have a single-thread problem – typical for game servers like Minecraft or Arma 3. If all cores are evenly loaded, a multi-threaded process like a web server or database is running at its limit
• RAM: The colored bar at the top shows memory usage. Green = used, Blue = buffers, Yellow = cache. Only when the green area reaches the right edge and swap becomes active do you have a RAM problem
• Load Average: The three numbers at the top right (e.g. 2.15 1.89 1.45) show the average load over the last 1, 5 and 15 minutes. If the 1-minute value is higher than your core count, the server is overloaded. If it's far below, current load is not the problem
• Swap: If swap is being used (visible in the upper area), you're low on RAM. Occasional swap usage is normal, constant swap usage massively slows down the server

Sort and analyze processes

In htop press F6 and select PERCENT_CPU or PERCENT_MEM to sort. The top processes are the culprits. Common troublemakers:

• mysqld / mariadbd: A single database query is blocking everything
• php-fpm: A broken PHP script is running in an endless loop
• java: Minecraft or other Java applications with too little RAM
• fail2ban: Processing thousands of log entries simultaneously

2. Check disk space

A full or nearly full hard drive can slow down the server extremely. Check with:

df -h

The output shows all partitions with size, used and available space. Pay special attention to:

• / (Root partition): If it's 90% full or more, it's becoming critical. The system needs space for temporary files and logs
• /var: This is where logs, databases and mail spoolers live. This partition often fills up first
• /tmp: Temporary files. A full /tmp folder can prevent sessions from being saved

Find space hogs

du -sh /* 2>/dev/null | sort -rh | head -10

Shows the 10 largest folders in the root directory. Usually these are:

• /var/log: Old log files that were never rotated
• /home: User data, old backups
• /var/lib/docker: Docker images and container data
• /var/www: Websites with lots of media uploads

Quick cleanup

# Delete old logs (older than 30 days)
find /var/log -type f -name "*.log" -mtime +30 -delete

# Limit journald logs to 500 MB
journalctl --vacuum-size=500M

# Clean up Docker (unused images, containers, volumes)
docker system prune -af

# Clear apt cache (Debian/Ubuntu)
apt clean

3. High CPU load – the most common causes

A single process as the culprit

With htop sort by CPU usage. If one process stands at the top with 80-100%, that's the troublemaker. Common scenarios:

• MySQL/MariaDB: Open the MySQL console and enter SHOW FULL PROCESSLIST;. You'll see all running queries. Queries with time > 10 seconds are suspicious. Use EXPLAIN SELECT ... to analyze them
• PHP-FPM: A broken script can cause an endless loop. Check PHP-FPM logs at /var/log/php*-fpm.log or in the web server error log
• Web server: Too many simultaneous connections. Check with ss -tan state established | wc -l the number of active connections

Many small processes

In htop press Shift+H to hide threads and show only main processes. If there are hundreds of similar processes (e.g. php-fpm workers), the cause is often in the configuration. Reduce the number of workers in the respective configuration file.

Cronjobs as hidden brakes

# Show all cronjobs for all users
for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done

Check if multiple cronjobs start at the same minute and block each other. Spread them out with minute intervals.

4. High RAM usage – what to do?

Identify RAM consumers

# Top 10 processes sorted by RAM
ps aux --sort=-%mem | head -11

Understand cache vs. real usage

Linux uses free RAM as disk cache. This is normal and desired. Only when the "available" value in free -h approaches zero do you have a real RAM problem. Example:

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       8.2Gi       1.3Gi       234Mi       6.1Gi       6.8Gi

Here 6.8 GB are available – although "used" shows 8.2 GB. The server has no RAM problem.

Analyze swap usage

If swap is used, you're low on RAM:

# View swap usage in real time
watch -n 1 free -h

# Which process uses how much swap?
for file in /proc/*/status ; do
    awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file
done | grep -v " 0 kB" | sort -k 2 -n -r | head -10

Free up RAM (if necessary)

# Clear caches (temporary only – they fill up again)
sync && echo 3 > /proc/sys/vm/drop_caches

Important: This is only a temporary solution. The caches help the system run faster. Long-term you need more RAM.

5. I/O wait – when the hard drive slows things down

If htop shows high values under "wa" (I/O wait), the CPU is waiting for the hard drive. Install iotop for analysis:

iotop -o

Shows only processes that actually cause I/O. Common causes:

• Backup is running: rsync, tar or mysqldump writing large amounts of data
• Database write operations: Many INSERT/UPDATE commands at once
• Faulty hard drive: Check with smartctl -a /dev/sda
• No SSD storage: HDDs have high access times. Upgrading to NVMe SSD often brings a 10x+ improvement

6. Identify network problems

Latency and packet loss

ping -c 100 google.com

At the end you'll see the statistics. Packet loss over 1% or fluctuating latency indicates network problems.

Analyze network path with mtr

mtr google.com

mtr combines ping and traceroute in real time. You see every hop between you and the target with latency and packet loss. A single hop with high loss is often the problem.

Real-time bandwidth usage

iftop -i eth0

Shows which connections are using how much bandwidth. Useful to see if a single client is flooding the server.

7. DDoS attack as the cause?

Detect suspicious connections

# Top 20 IPs by connection count
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20

Many connections from a single IP (especially on a single port) are a strong indicator of an attack.

Detect SYN flood

netstat -ant | grep SYN_RECV | wc -l

Hundreds or thousands of SYN_RECV connections indicate a SYN flood attack. At NexoraHost, Arbor DDoS protection kicks in automatically in this case – you don't need to do anything.

8. VPS specific: Is overselling noticeable?

With VPS, you share the host with other users. Their load can affect your performance. Signs include:

• Performance fluctuates strongly without a recognizable cause on your side
• Regularly slower at certain times of day
• CPU "steal" value in htop or top: Shows how much CPU time the hypervisor assigns to other servers. Constantly above 5-10% is problematic

Solution: Upgrade to a root server with dedicated resources. There, the entire hardware performance belongs to you alone.

9. Set up continuous performance monitoring

So you can detect problems early:

# Install Netdata (lightweight monitoring)
bash