Introduction: “turn it off and on again” is not a method

“The site loads slowly.” “The database is sluggish.” “SSH is lagging.” These are the most common complaints.

A beginner’s reaction is to reboot. That’s “treating the symptom.” The problem disappears for an hour, then comes back, because you never found the cause. On top of that, in an enterprise environment a reboot means downtime and lost money.

The “architect of the future” acts like a diagnostician. They have a checklist of metrics. They don’t guess — they measure.

In this guide we’ll walk through the USE method (Utilization, Saturation, Errors) and 5 tools that show you the truth in 60 seconds.

Step 1. The big picture: load average

The first thing we type is uptime or top.

Bash

$ uptime
 14:30:05 up 10 days,  4:15,  1 user,  load average: 0.50, 10.05, 25.30

Look at load average (the average load over 1, 5, and 15 minutes).

• What is it? The number of processes that are either using the CPU or waiting in line for it (or for disk!).
• How to read it: if you have 4 cores, an LA of 4.0 means 100% utilization.
  • LA < core count: everything’s fine.
  • LA > core count: the queue is growing, the server is choking.

The architect’s view: if LA is high (say, 25.30 on 4 cores), don’t rush to blame the CPU. Often the real problem is disk.

Step 2. CPU or disk? (top / htop)

Run top. Don’t look at the process list — look at the header, the %Cpu(s) line.

Plaintext

%Cpu(s): 10.5 us,  5.2 sy,  0.0 ni, 80.0 id,  4.1 wa,  0.0 hi,  0.2 si

Decoding the magic:

1. us (user): useful work (your programs: PHP, MySQL, Java). If this is at 100%, look below in the process list for the culprit.
2. sy (system): the kernel itself. If this is high, the problem is likely drivers or a huge number of system calls.
3. wa (iowait): THE MOST IMPORTANT ONE. Time the CPU spends idle, waiting for the disk to respond.

Diagnosis:

• High us? -> the CPU is busy computing (a miner? a looping script?).
• High wa? -> the CPU isn’t the problem! The problem is disk. The disk can’t keep up with reads/writes.

Step 3. Memory: “did Linux eat all my RAM?”

Look at free -m.

Bash

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7976        2000         500          10        5476        5800
Swap:          2047           0        2047

Beginners panic: “Oh no, free is only 500 MB!”

The architect stays calm.

1. used: memory actually held by programs.
2. buff/cache: Linux isn’t dumb. It uses free memory to cache files from disk, so the system flies. This memory is released instantly the moment applications need it.
3. available: this is your real free memory. If it’s close to zero, that’s a problem (the OOM Killer is about to come start killing processes).

A red flag: if Swap is in use (used > 0) and keeps growing. That means RAM is short, and the system is spilling data onto slow disk. This kills performance (hello, high iowait).

Step 4. Who’s killing the disk? (iotop)

If Step 2 showed high wa (iowait), you need to know who the culprit is. Plain top won’t show you that.

You need iotop (install it: apt install iotop / yum install iotop).

Run: sudo iotop -oPa

• -o: show only processes that are actually generating disk load.
• -P: show processes, not threads.
• -a: accumulate statistics (shows who’s written the most data since the tool started).

You’ll immediately see: “Ah, it’s mysqld running a heavy SELECT and reading gigabytes” or “It’s rsync running a backup and hammering the disk.”

Step 5. Network and bottlenecks (iftop / ss)

If CPU, RAM, and disk are all fine but “everything is still slow,” the network link might be saturated.

1. iftop (like top, but for the network): shows in real time who is talking to whom, and at what speed.
   • Example: you’ll see the server pushing a backup out at 1 Gbps, saturating the whole link — which is why the site won’t load.
2. ss -s: a quick socket summary.
   • If you see thousands of connections stuck in TIME-WAIT or SYN-RECV, you might be getting DDoS’d, or your web server (Nginx/Apache) is misconfigured.

Conclusion: the architect’s algorithm

Next time someone says “the server is slow,” don’t reboot it. Follow the algorithm:

1. uptime: check load average. High? Dig further.
2. top: check %Cpu.
   • High us? -> find the hungry process.
   • High wa? -> the problem is disk.
3. iotop: (if disk is the problem) find the process hammering it.
4. free -m: check available and swap. Have we started swapping?
5. iftop: check whether the link is saturated.

In 60 seconds you’ll have found the cause. And instead of a blind reboot, you can make a precise, surgical fix: optimize a database query, move the backup to run at night, or add more RAM.

That’s the path from “IT guy” to systems architect.

Tags: #linux #troubleshooting #performance #sysadmin #devops #top #diagnostics #server

Want to become tomorrow’s architect instead of just an admin? This article is only the tip of the iceberg. On our Telegram channel “Admin Future” we publish systems-thinking guides, ready-to-use scripts, AI tips, and checklists every day that you won’t find on Google. We don’t just post commands — we’re building a knowledge library for people who want to grow from admin to architect. Subscribe and become the expert in the room: Admin Future