Connecting to Linux VPS via SSH
- Open a terminal or any SSH client (for example, PuTTY on Windows) on your computer.
- Connect to the server with a command like this:
ssh user@IP_your_server
3. Enter your password or use the key as configured in the panel.
Further commands are executed within this SSH session.
Install and run htop
1. Installing htop
On a server running Debian/Ubuntu, run:
sudo apt update
sudo apt install htop
On CentOS / RHEL / AlmaLinux / Rocky:
sudo yum install htop # or dnf install htop
If there are no errors, the utility is installed.
2. Launch htop
In the same SSH window, run:
htop
After that, the screen should be completely filled with the htop interface:
3. How to read the htop interface
Let’s break it down from top to bottom:
- Top CPU bars
- Each colored bar represents a separate vCPU core.
- The more colored it is, the higher the current load.
- If one or more cores are constantly “at 100%,” the processor is overloaded.
- Memory (Mem) and Swap bar
- Shows how much RAM is occupied.
- If almost all memory is occupied and Swap starts to be actively used, the server will slow down.
- Top right
- Load average — average system load for 1, 5, 15 minutes.
- If the values significantly exceed the number of vCPUs (for example, 8.0 with 2 cores), the server is overloaded.
- Main process table
- In the columns you will see:
- PID — process identifier.
- USER — on whose behalf it is running.
- %CPU — how much CPU the process is currently consuming.
- %MEM — the proportion of RAM.
- TIME+ — total processor time.
- Command — command/application.
- Bottom row of tooltips
- F6 SortBy — select the field to sort by.
- F9 Kill — terminate the process.
- F10 Quit — exit htop.
4. What to do in htop
- Press F6 and select sorting by %CPU, then by %MEM.
- Look at the top lines of the list — there will be the “heaviest” processes.
- If one process is constantly at the top with 90–100% CPU — it is the one that is loading the VPS.
- If %CPU is normal, but %MEM is very high for several processes and there is almost no free memory, the problem is with RAM.
To exit htop, press F10 or q.
Checking the disk and I/O via iostat
When the CPU and memory look normal, but the server is still slow, it is worth checking the disk subsystem — read/write delays and disk load.
1. Installing iostat (sysstat package)
On Debian/Ubuntu:
sudo apt install sysstat
On CentOS/RHEL:
sudo yum install sysstat # или dnf install sysstat
2. Launch iostat
Execute:
iostat -x 5 3
Explanation of parameters:
- -x — extended statistics.
- 5 — interval between conclusions (5 seconds).
- 3 — number of repetitions (3 times).
Example of conclusion:
First comes the avg-cpu block, followed by the Device table with disks.
3. Which fields to look at
In the device table (Device row), pay attention to:
- r/s, w/s — the number of read and write operations per second.
- rkB/s, wkB/s — read/write speed in kilobytes per second.
- await — average wait time for an I/O operation.
- %util — the percentage of time the disk is busy.
Approximate analysis algorithm:
- If await is small (milliseconds) and %util is far from 100%, the disk is coping.
- If await is large (tens and hundreds of ms) and %util is consistently 80–100%, the disk is overloaded.
- At the same time, the CPU may be free in htop — the server is running into the disk/I/O.
Repeat the command iostat -x 5 3 several times during load to see how the numbers change.
Let’s analyze everything together using atop
atop is useful when you need to see the whole picture: CPU, memory, disks, and network in a single interface.
1. Installing atop
For Debian/Ubuntu:
sudo apt install atop
For CentOS/RHEL (more often via EPEL):
sudo yum install epel-release
sudo yum install atop
2. Launching atop
sudo atop
A full-screen interface will open:
3. How to navigate atop
The top blocks are:
- PRC — general information about processes.
- CPU — processor load.
- mem — RAM usage.
- swp — swap usage.
- dsk — disk activity.
- net — network metrics.
Below is a list of processes with several columns: CPU, memory, disk, and network consumption.
4. Typical sequence of actions in atop
- Look at the CPU line — is there a constant load close to 100%?
- The mem line — how much memory is occupied, how much is free, how much cache is used.
- The dsk line — total disk activity; if the values are high, go back and check iostat again.
- In the list of processes, find those with high CPU, memory, or I/O values — they are most often the ones creating the load.
To exit atop, press q.
Let’s put everything into one diagnostic script
To make Linux VPS load monitoring understandable and reproducible, it is convenient to follow the same algorithm:
Suspected overload
The site opens slowly, the API responds with delays, the database “freezes.”
Step 1 — htop
- Run htop.
- Check CPU, memory, and swap usage.
- Find “heavy” processes by %CPU and %MEM.
Step 2 — iostat
- Run iostat -x 5 3.
- Evaluate await and %util on disks.
- If they are high, there is a bottleneck in disk/I/O.
Step 3 — atop
- Run sudo atop.
- Review the summary lines for CPU, mem, dsk, and net.
- Compare with what you already saw in htop and iostat.
Next
- If you are constantly hitting the CPU limit, optimize the application/database or increase the number of vCPUs.
- If you are running out of memory, review your service settings or add RAM.
- If the disk is overloaded, switch to a faster NVMe or a plan with better disk performance.
When it makes sense to upgrade your VPS plan
If regular monitoring shows that the server is almost always running at the limit of its CPU, memory, or disk, it is easier and more reliable to switch to a more powerful VPS plan than to constantly tweak the settings.
Conclusion
Monitoring the load on a Linux VPS is a sequence of specific steps:
- htop — shows which processes are currently loading the CPU and memory.
- iostat — answers the question “is the disk coping?”.
- atop — gives an overview of all resources and helps to link scattered indicators.
By following the steps described and referring to the images, even a novice administrator will be able to understand what is happening with the VPS at the moment of problems and what solution — optimization or tariff upgrade — is appropriate here.