Your fast server suddenly is not. Pages crawl, jobs overrun, and nothing in the deploy log explains it. Most of the time the cause is one process overusing the CPU, the RAM, or the disk, and the quickest way to catch it in the act is htop: an interactive process viewer that sorts the heaviest offenders to the top of your terminal and lets you deal with them on the spot.

Install it

On Debian, Ubuntu, and their relatives:

sudo apt install htop

On Red Hat family distros like Rocky Linux, htop lives in the EPEL repository, so enable that first:

sudo dnf install epel-release
sudo dnf install htop

Both routes were run on clean containers for this post and land the same current release:

htop 3.3.0

Run it with sudo

sudo htop

The sudo matters more than it looks. Without it, htop still shows you everything, but you can only send signals to processes owned by your own user. Run it with sudo and you can act on anything on the box, including the runaway service started by root or another account, which is usually exactly the process you came for.

Find the CPU hog

htop sorts by CPU usage by default, so the heaviest processes sit at the top the moment it opens. Read the CPU% column with one rule in mind: 100% means one full core, constantly busy. On a multi-core machine the number keeps going: 200% is two full cores, 400% is four. A single process pinned at a high multiple while everything else idles is your suspect.

Kill it politely, then firmly

Move the selection bar onto the process with the arrow keys and press F9 (there is also a clickable F9 Kill label along the bottom; htop takes mouse input). A list of signals opens on the left with signal 15 SIGTERM already selected. Press Enter. SIGTERM is the polite request: "please wrap up and exit", and a healthy process will finish its work, save its data, and shut down cleanly.

A process stuck in a loop may ignore the request. If it is still there, select it again, press F9, and this time choose signal 9 SIGKILL. The kernel removes it immediately, no cleanup, no chance to save anything, which is exactly why SIGKILL stays the last resort rather than the first click.

Nothing hogging the CPU? Sort by memory

Click the MEM% column heading, or press F6 and pick the memory field from the sort menu. Now the RAM-heavy processes rise to the top, and a leaking service is suddenly very visible. Dealing with it works the same way: arrow down, F9, choose your signal.

Catch the disk hammerers

CPU and memory clean, but the server still drags? Press Tab to switch to htop's I/O screen (screens appear as tabs along the top). The DISK R/W column shows each process's combined read plus write throughput right now, which is how you catch the backup job or log-flooding service that is saturating your storage while barely registering on CPU. Killing from this screen is unchanged: select and F9.

When you are done, press q (or F10) to quit.

The takeaway

One tool answers all three "why is it slow" questions: open sudo htop, read the default CPU sort, re-sort by MEM% for memory, and Tab over to the I/O screen for disk. Ask nicely with SIGTERM, insist with SIGKILL, and the mystery slowdown usually has a name and a PID within a minute of logging in.

FAQs