Troubleshooting a Slow or Unresponsive Server

When a server is slow or unresponsive, work from the outside in: confirm what is failing, get access, then check CPU load, memory, disk space and I/O, the network, the services, and the logs, in that order. Most incidents come down to one of a few causes: memory exhaustion, a full disk, a runaway process, an I/O bottleneck, a traffic spike or a bad deploy.

Keep notes of what you check and when; they help you fix it now and prevent it next time.

Step 1: Confirm the scope

• Is the website slow, or the whole server? Can you reach it by SSH?
• Is it all sites on the server, or one?
• When did it start, and what changed just before (a deploy, an update, a traffic campaign, a cron job)?
• Check external monitoring for the exact start time. See server monitoring basics.

Step 2: Get access

• Try SSH. If it hangs, the server may be out of memory or heavily overloaded.
• Use your provider's web console if SSH does not respond.
• As a last resort, reboot from the provider panel, but understand that you may lose the evidence of what happened. Capture what you can first.

Step 3: Check load and CPU

uptime
top        # or htop

• Load far above the number of CPUs and high us CPU: a CPU-heavy process. Sort top by CPU (P) to find it.
• High load with high wa: storage I/O bottleneck (see step 5).
• High st (steal) on a VPS: the physical host is busy; contact your provider.

How to read these numbers is explained in Linux load average, CPU and memory explained.

Step 4: Check memory and the OOM killer

free -h
journalctl -k | grep -i "out of memory"     # or: dmesg | grep -i oom

• Low available memory and growing swap usage: memory pressure.
• OOM killer messages show which process was killed, often the database or PHP workers.

Common fixes: reduce PHP-FPM workers, reduce the database buffer pool, stop the leaking process, or add RAM. See server performance tuning.

Step 5: Check disk space and I/O

df -h          # space
df -i          # inodes
iostat -x 2    # I/O (from the sysstat package)

• A full disk stops databases, logs and uploads and can corrupt data. Find large files with du -sh /* | sort -h, typically logs, backups or caches.
• Inodes exhausted: millions of small files (session or cache files, mail).
• High I/O utilisation: a heavy query, backup or process saturating the disk. iotop shows which process.

Step 6: Check the network and traffic

• ss -s and ss -tn state established | wc -l show connection counts.
• Look at web server access logs for request spikes from a few IPs or user agents:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

(Adjust the log path for Apache or LiteSpeed.) Aggressive bots and attacks can be blocked or rate-limited. See brute-force attack prevention and DDoS attacks explained.

Step 7: Check the services

systemctl --failed
systemctl status nginx php8.3-fpm mariadb    # adjust names to your stack

• A crashed database or PHP-FPM pool produces 502/503 errors.
• PHP-FPM's log may show "server reached max_children", meaning requests are queuing.

Step 8: Read the logs

• Web server error log.
• PHP-FPM and application logs.
• Database error log and slow query log.
• journalctl -p err --since "1 hour ago" for system errors.

Step 9: Fix, then prevent

Apply the immediate fix (restart a service, free disk space, block abusive traffic, roll back a deploy), then address the cause:

• add alerts for the metric that would have warned you;
• adjust worker and memory settings;
• schedule heavy jobs outside peak hours;
• add resources if the workload has genuinely grown. See how to choose VPS specs.

Worked example: a full disk at 2 am

Monitoring alerts that the website returns errors. SSH works but is slow.

1. df -h shows / at 100%.
2. sudo du -xh / --max-depth=1 | sort -h points to /var (38 GB).
3. Digging further shows /var/log/nginx/access.log at 21 GB: log rotation stopped working after a configuration change months ago, and a bot flood that night made it grow faster.
4. Immediate fix: truncate the oversized log safely (sudo truncate -s 0 /var/log/nginx/access.log, after copying a portion if you need it for investigation), then restart services that failed to write.
5. Check data integrity: the database had failed to write while the disk was full; check its error log and run a table check.
6. Prevent it: fix log rotation (logrotate -d /etc/logrotate.d/nginx to debug), add a disk-space alert at 85%, and rate-limit the bot.

Total downtime: about 40 minutes. Without the alert, it would have been discovered by customers in the morning.

After the incident: a short review

Write five lines while it is fresh:

• what happened and when;
• how it was detected;
• what fixed it;
• the root cause;
• what will prevent it next time (and who will do it by when).

Over time, these notes show patterns and make the server steadily more reliable.

Quick reference

Finding	Likely cause	First action
OOM messages, swap full	Too many workers or a leak	Reduce workers, restart leaking service
Disk 100%	Logs, backups, caches	Delete or rotate safely
High wa	Disk-heavy process	Find it with iotop, reschedule or optimise
Many requests from few IPs	Bots or attack	Block or rate-limit
Service failed after update	Bad configuration or package	Check logs, roll back

Frequently Asked Questions

Should I just reboot?

A reboot often restores service quickly but destroys evidence and does not fix the cause. Capture top, free, df and recent logs first if you can.

Why is the server slow only at night?

Scheduled tasks such as backups, log rotation and reports often run at night. Check cron jobs and their timing.

Related reading

For the fundamentals, see what is a VPS. A ServerNeed managed VPS includes 24/7 server monitoring, security updates and automated backups.

Sources

• Brendan Gregg: Linux Performance
• Linux man page: journalctl(1)