How to Troubleshoot a Slow Linux Server

A slow server affects every application and user connected to it. Systematic troubleshooting identifies the root cause quickly rather than making random changes and hoping for improvement. Follow this structured approach to diagnose and resolve server performance issues.

Step 1: Identify the Symptom

Before diving into diagnostics, clarify what slow means: - Is the application responding slowly to requests? - Are SSH sessions lagging? - Are specific operations slow (database queries, file uploads)? - Is the server unresponsive? - Did performance degrade gradually or suddenly?

The nature of the symptom guides your investigation.

Step 2: Check System Load

Start with uptime to see the load average: uptime

Load average shows three numbers: 1-minute, 5-minute, and 15-minute averages. Compare these to the number of CPU cores. A load average consistently higher than the number of CPU cores indicates the system is overloaded.

For example, on a 4-core server, a load average of 8 means twice as many processes are waiting for CPU time as can be served simultaneously.

Step 3: Check CPU

Run top and observe: - The overall CPU breakdown (user, system, idle, iowait) - Which processes are consuming the most CPU - Whether high iowait indicates a disk bottleneck

If CPU is the bottleneck (user + system consistently above 90%): - Identify the consuming process - Check if it is expected behavior (peak traffic) or unexpected (runaway process) - Consider upgrading to a configuration with more vCPUs

If iowait is high (above 20% consistently): the bottleneck is disk I/O, not CPU. Move to disk diagnostics.

Step 4: Check Memory

Run free -h and check: - Available memory: if near zero, the system is under memory pressure - Swap usage: any swap usage indicates memory exhaustion

If memory is the bottleneck: - Identify which processes are consuming the most memory - Check for memory leaks (processes whose memory usage grows over time) - Consider adding swap space as a temporary measure - Plan to increase server RAM if the workload requires it

Run top and press M to sort by memory usage to identify the biggest consumers.

Step 5: Check Disk

Run df -h to check disk space. A full disk causes cascading failures: - Databases may refuse writes - Logs stop recording - Applications crash

Run iostat -x 1 to check disk I/O performance: - %util above 80%: disk is a bottleneck - await above 50ms (SSD) or 200ms (HDD): I/O latency is high

If disk space is the issue, use du to find large directories and clean up unnecessary files (old logs, temporary files, cached data).

If disk I/O is the issue: - Check which processes are performing the most I/O (iotop) - Consider moving to NVMe storage for better IOPS - Optimize database queries that cause excessive disk reads

Step 6: Check Network

Run ss -s to check connection counts. High numbers of established connections or time-wait connections may indicate network issues.

Test network connectivity: ping external hosts to measure latency and packet loss.

Check bandwidth utilization: if the network interface is saturated, application responses will be slow regardless of server resources.

Step 7: Check Application Logs

Application logs often reveal the root cause of performance issues: - Database connection timeouts - External API call failures - Memory allocation errors - Disk write failures - Authentication delays

Check logs for your web server, application, database, and any other services.

Step 8: Check for Specific Issues

Database Bottleneck

If your application is slow but server resources look fine, the issue may be database performance: - Slow queries: enable slow query logging - Connection pool exhaustion: check active database connections - Lock contention: check for lock waits - Missing indexes: analyze slow query patterns

Process Zombies

Zombie processes (defunct state in ps output) consume no resources but may indicate a parent process issue. Find and address the parent process.

File Descriptor Exhaustion

If you see too many open files errors, the process has hit its file descriptor limit. Check with: cat /proc/PID/limits | grep files

Increase limits in /etc/security/limits.conf if needed.

Step 9: Temporary Mitigation

While investigating the root cause: - Restart the problematic service to restore immediate functionality - Enable rate limiting if traffic spikes are the cause - Clear temporary files and caches if disk space is low - Kill runaway processes if identified

Step 10: Long-Term Resolution

After resolving the immediate issue: - Set up monitoring to detect the issue earlier next time - Implement alerts for resource thresholds - Plan capacity upgrades if the workload has outgrown the current server - Document the issue and resolution for future reference

Conclusion

Server troubleshooting follows a systematic pattern: check load, CPU, memory, disk, network, and application logs in sequence. This approach quickly narrows down the bottleneck. Most performance issues fall into a few categories: insufficient resources, disk I/O bottleneck, application-level problems, or network constraints.