Enterprise hosting · Built for gamers
Server Lagging – Check CPU, RAM & Disk Immediately
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. UseEXPLAIN SELECT ...to analyze them - PHP-FPM: A broken script can cause an endless loop. Check PHP-FPM logs at
/var/log/php*-fpm.logor in the web server error log - Web server: Too many simultaneous connections. Check with
ss -tan state established | wc -lthe 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 <(curl -Ss https://my-netdata.io/kickstart.sh)
Netdata runs on port 19999 and shows detailed graphs for CPU, RAM, I/O, network and much more. Ideal for recognizing patterns over days and weeks.
10. Quick checklist from top to bottom
- htop: Check CPU, RAM, Load Average, Swap
- df -h: Check disk space, clean up if needed
- MySQL SHOW FULL PROCESSLIST: Identify slow queries
- iotop: Analyze disk I/O
- mtr: Test network path
- netstat: Check for suspicious connections
- Cronjobs: Find time overlaps
- Unused services: Stop and disable
- Logs: Delete old logs, set up rotation
- VPS: Check CPU steal, upgrade to root server if needed
Detailed guides on each point can be found in the articles in the left navigation. If problems persist, contact our support via the customer panel.
See also: Server monitoring · Tune root server · Optimize Pterodactyl · Game server hub
NexoraHost
Root & VPS servers
Ryzen power at Maincubes FRA01 – full root access, NVMe, DDoS protection included.
nexorahost.com · Maincubes FRA01 · 1 Tbit/s DDoS · 99,9 % Uptime