Linux server running slow: how to find the cause

Log in over SSH and run uptime. Three load averages appear: one, five and fifteen minutes. Compare them with the number of CPU cores from nproc. A load of four on a four core machine is busy but healthy. A load of twenty is not.

Open top, or htop if installed. Press 1 to see each core. Look at the us, sy, wa and st values. High us means your programs are busy. High wa means they are waiting on the disk. High st means a shared host is taking your time.

Sort by CPU, then by memory. Write down the top three processes and their owners. A PHP-FPM pool, a Node worker or a PostgreSQL backend each tell a different story.

Run free -h. Ignore the free column, which looks scary on any healthy Linux box because the kernel uses spare memory for cache. Read available instead.

If available is tiny and swap used keeps growing, the machine is thrashing. Run vmstat 5 and watch si and so. Steady nonzero values mean pages are moving to and from disk all the time, and everything feels slow.

Check dmesg for lines mentioning the OOM killer. If it killed a database or an app worker, you have found a cause. Then compare the memory limit on each service with what the box really has.

Run df -h first. A full root partition stops logging, breaks databases and slows everything. Then df -i, since running out of inodes looks the same. The usual culprits are old logs, core dumps, backups and uploads.

Run iostat -x 5. Look at await and %util for each device. High await with high utilisation means the disk cannot keep up. Use iotop to see which process is hammering it.

Find big directories with du -xh --max-depth=1, starting at the root and working down.

A cron job that overlaps itself, a stuck backup script or a worker in an endless loop will show up in ps aux sorted by CPU. Check how long it has been running and what started it.

Connections cause slowness without high load. Run ss -s to count sockets, and check the open files limit with ulimit -n. A web server or PostgreSQL that hits its connection ceiling queues new requests while the CPU sits idle.

Read the logs from the slow window: journalctl --since, the Nginx error log, the database log. Look for timeouts, too many open files and upstream errors.

Resize when the same resource is near its limit for hours every day, and your software is already tuned. A queue of real users on a four core machine is a capacity problem.

Fix when the pressure comes from a bug, a missing index, a log that never rotates or a job scheduled at the wrong hour. A bigger server only delays those problems and raises the bill.

Tonight, record uptime, free, df and iostat output at a quiet time. A baseline makes the next slow day far easier to read.