How to Troubleshoot a Slow Linux Server: A Step-by-Step Production Checklist

One of the most common complaints from application teams is:

“The server is slow.”

However, “slow” can mean many different things. It could be caused by high CPU utilization, memory pressure, excessive disk I/O, network latency, application bottlenecks, or even database locks.

Many administrators immediately restart services or reboot the server without identifying the root cause. While this may temporarily restore performance, it doesn’t solve the underlying problem.

In this guide, I’ll walk you through the exact troubleshooting process I follow in production environments whenever a Linux server becomes slow.

Pro Tip: Never reboot a production server before collecting evidence. Commands like uptime, top, vmstat, and journalctl help identify the root cause, while a reboot can hide it.

What You’ll Learn

• How to identify the real cause of a slow Linux server
• Which commands to run first
• How to interpret command output
• Common performance bottlenecks
• Real-world troubleshooting tips
• Best practices to avoid future incidents

Linux Performance Troubleshooting Flow

User reports "Server is Slow"

            │
            ▼
Check Uptime & Load Average
            │
            ▼
Check CPU Utilization
            │
            ▼
Check Memory & Swap
            │
            ▼
Check Disk Space
            │
            ▼
Check Disk I/O
            │
            ▼
Check Running Processes
            │
            ▼
Check Network
            │
            ▼
Check Application Logs
            │
            ▼
Identify Root Cause

Never assume the CPU is the problem. Always follow a systematic approach.

Step 1 – Check Server Uptime and Load Average

The first command I run whenever a Linux server becomes slow is:

uptime

This command provides a quick overview of the server’s uptime and Load Average, helping you determine whether the system is under excessive load.

If you’re unfamiliar with Load Average or how to interpret its values, I recommend reading my detailed guide: Linux Load Average Explained: What It Means and How to Troubleshoot High Load.

Example output:

10:15:42 up 45 days, 3:20, 2 users, load average: 3.12, 2.95, 2.87

This tells you:

• Current time
• Server uptime
• Logged-in users
• Load Average for:
  • Last 1 minute
  • Last 5 minutes
  • Last 15 minutes

How to Interpret Load Average

Suppose your server has 4 CPU cores.

Load Average	Status
0–4	Normal
5–8	High
Above 8	Investigate immediately

Tip: High Load Average doesn’t always mean high CPU usage. Processes waiting for disk I/O also contribute to the load average.

Step 2 – Check CPU Utilization

Run:

top

or

htop

Example:

%Cpu(s): 75 us, 15 sy, 5 id, 3 wa, 2 st

Important CPU fields:

Field	Meaning
us	User CPU
sy	System CPU
id	Idle CPU
wa	I/O Wait
st	Steal Time (Virtual Machines)

High I/O Wait?

If wa is high, the CPU isn’t the problem.

Your storage is.

Step 3 – Find High CPU Processes

ps -eo pid,user,%cpu,%mem,command --sort=-%cpu | head

Example:

PID USER %CPU COMMAND

4521 apache 95.4 httpd

7890 mysql 65.8 mysqld

1122 java 55.3 java

Investigate:

• Infinite loops
• Java applications
• Apache workers
• MySQL queries

Step 4 – Check Memory Usage

Run:

free -h

Example:

              total        used        free      shared  buff/cache   available
Mem:           16Gi        10Gi       500Mi       300Mi        5Gi         5Gi
Swap:           2Gi       200Mi       1.8Gi

Don’t panic if free memory is low.

Linux uses available memory for caching.

The important field is:

available

Step 5 – Check Swap Usage

High swap usage can make the server extremely slow.

Check:

vmstat 1 5

Look at:

si
so

If they’re continuously increasing, the server is swapping heavily.

Step 6 – Check Disk Space

Run:

df -h

Look for partitions above:

• 80%
• 90%
• 95%

Also check inode usage:

df -i

Sometimes the filesystem has free space but no inodes.

Step 7 – Check Disk I/O

This is where many administrators stop troubleshooting.

Run:

iostat -x 1 5

Pay attention to:

Field	Meaning
%util	Disk utilization
await	Average wait time
r/s	Reads per second
w/s	Writes per second

Example:

Device  %util  await

nvme0n1 99.8 150 ms

If %util remains close to 100% with high await, your storage is the bottleneck.

Step 8 – Check Running Processes

top

Sort by:

• CPU
• Memory

Also use:

ps aux --sort=-%mem | head

Large memory-consuming applications often indicate memory leaks.

Step 9 – Check Network Connections

ss -tulpn

Useful for:

• Too many established connections
• Unexpected listening ports
• Port exhaustion

Step 10 – Review System Logs

Never skip logs.

journalctl -xe

Also check:

dmesg

Common issues:

• Out Of Memory Killer
• Filesystem errors
• Kernel panic messages
• Disk failures

Step 11 – Check Application Logs

Sometimes Linux is healthy.

The application isn’t.

Examples:

Apache

tail -100 /var/log/httpd/error_log

Nginx

tail -100 /var/log/nginx/error.log

PHP

tail -100 /var/log/php-fpm/error.log

MySQL

tail -100 /var/log/mysqld.log

Production Scenario

Recently, an application team reported that their website was taking more than 20 seconds to load.

Initial observations:

• CPU Usage: 18%
• Memory Usage: Normal
• Load Average: 14
• Disk Utilization: 100%
• I/O Wait: 48%

At first glance, the CPU looked healthy. However, iostat revealed the root cause: the EBS volume had become saturated, causing requests to queue. Increasing storage performance and optimizing write operations resolved the issue.

The lesson? High load average doesn’t always mean the CPU is overloaded.

Common Causes of a Slow Linux Server

• High CPU utilization
• Excessive memory consumption
• Swap activity
• Full disk
• High disk I/O
• Too many Apache workers
• Database locks
• Long-running queries
• Network latency
• Hardware limitations
• Misconfigured applications

Best Practices

• Monitor CPU, memory, and disk continuously.
• Configure alerts before users report issues.
• Keep sufficient free disk space.
• Review logs regularly.
• Avoid unnecessary services.
• Use visudo for sudo configuration changes.
• Test performance changes in a staging environment.
• Document recurring incidents and their solutions.

Conclusion

Troubleshooting a slow Linux server isn’t about running random commands or restarting services. It’s about following a structured process to identify the real bottleneck. By checking load average, CPU, memory, disk, network, and application logs in sequence, you can isolate the root cause quickly and resolve issues with confidence.

Whether you’re a Linux administrator, DevOps engineer, or cloud professional, developing a consistent troubleshooting workflow will save valuable time during production incidents and reduce unnecessary downtime.