How to see what is using your server resources

"The server feels slow" is not a diagnosis, it is a symptom, and the difference between guessing at a fix and actually resolving it is a handful of commands that tell you precisely what is consuming your CPU, memory and disk right now. All of them ship with the base operating system except htop, which is one small install away.

CPU and memory at a glance: top and htop

top is available on every Linux install with no setup:

top

The top section summarises load average and overall memory; the process list below is sorted by CPU usage by default, so whatever is at the top of that list is your current biggest consumer. Press q to quit.

htop shows the same information with a colour-coded, more readable layout, and lets you scroll, search, and kill a process directly from the interface:

sudo apt install htop -y      # Ubuntu / Debian
sudo dnf install htop -y      # RHEL / Rocky / AlmaLinux
htop

In either tool, watch two numbers in particular: load average (three figures — 1, 5 and 15 minute averages of how much work is queued) and the percentage of memory in use. A load average sustained well above your server's number of CPU cores means work is queuing faster than it can be processed.

Memory in detail: free -h

free -h

The -h flag prints sizes in human-readable units (MiB/GiB) instead of raw kilobytes. Read the available column, not free — Linux deliberately uses spare memory for disk caching to speed up file access, so free alone often looks alarmingly low while the system is actually fine. available is the kernel's own estimate of what could genuinely be reclaimed for a new process without swapping, and it is the number that actually tells you whether you are short on memory.

              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.2Gi       0.3Gi        45Mi        2.3Gi       2.4Gi
Swap:          2.0Gi          0B       2.0Gi

If available is consistently low and swap usage is climbing, the server genuinely needs more memory, fewer running services, or — as an immediate cushion rather than a permanent fix — more swap space.

Disk space: df -h

df -h

Lists every mounted filesystem with its size, usage and percentage full. A filesystem at 100% is a common and entirely avoidable cause of an outage — a full disk stops logs writing, stops databases committing, and can stop the server booting cleanly at all. Add -T to also show the filesystem type:

df -hT

Finding what is actually eating disk space

When a specific filesystem is full, narrow down where the space went with du (disk usage), starting broad and drilling in:

du -sh /var/* 2>/dev/null | sort -rh | head -10

This lists the ten largest top-level directories under /var — a common place for space to disappear into, since it holds logs, package caches and, on a database server, the data files themselves. Repeat the same command one level deeper inside whichever directory turns out to be the culprit. Log files that have grown unbounded are a frequent cause — see reading Linux server logs for how to check and manage them.

Finding which process owns a resource

Once top or htop has pointed you at a high-CPU or high-memory process by name, get more detail on it directly:

ps aux | grep processname

This shows the process ID (PID), the user it is running as, and its CPU and memory percentage. With the PID in hand, you can inspect it further or, if it is genuinely misbehaving, stop it:

kill PID          # ask it to stop cleanly
kill -9 PID        # force it, if it ignores the request above

Network connections: ss

If the concern is unexpected network activity rather than CPU or memory, list active connections and listening ports:

ss -tulpn

-t and -u show TCP and UDP, -l limits to listening sockets, -p shows the owning process, and -n keeps addresses numeric rather than resolving them.

Getting a longer-term view

Everything above shows a live snapshot. To understand a pattern over hours or days — a memory leak that builds up slowly, or a CPU spike that only happens overnight — you need history rather than a single reading. How to check whether your server is performing covers tools that log usage over time rather than just showing the current moment, and is the natural next step once a one-off snapshot is not enough to explain what you are seeing.