Diagnosing server load (CPU, RAM, disk, network)

When your server becomes slow or stops responding, the cause is usually one of four exhausted resources: the processor (CPU), memory (RAM), the disk or the network. This guide shows the commands that find the resource to blame and what to do in each case. You run the commands on the server, over SSH, as root. You can see how the load changes over time on the “Monitoring” page of the app.blackbox.md panel (app.blackbox.md/monitoring, sidebar → “Infrastructure” → “Monitoring”).

Available to: anyone with root SSH access to a BLACKBOX server running Ubuntu, Debian, AlmaLinux or CentOS Stream. The charts in the panel: the server owner, for servers with the Monitoring add-on service active.

The blackbox.md website is available in Romanian and Russian; this article quotes the Romanian labels with their English meaning.

The server is slow or not responding: steps in order

1. Connect over SSH (Connecting to your server over SSH (Windows, macOS, Linux)):

   ssh root@SERVER_IP

2. If you can connect, even slowly, don't reboot yet: a reboot erases the traces of the problem. Run the commands in the sections below, starting with “Quick look”.

3. If SSH doesn't respond (the connection times out or the session hangs): in the panel, open “My Servers”, click “Reboot” on the server card and confirm “Reboot SERVER_NAME?”. Wait 30–60 seconds and connect again. If the panel shows power_action_failed, the server may be off: click “Start”. Details: Rebooting, stopping and starting a server.

4. If the server still doesn't respond after a few minutes, write to support (How to contact BLACKBOX support). Include the server's IP address, the order number (BBX-…) and the date and time the problem started. For an urgent issue during business hours, also call +373 78 003948, Monday–Friday, 09:00–18:00 (Moldova time).

5. Once the server responds again, find the cause: see the question “The server crashed and works again after a reboot. How do I find the cause?” at the end of this guide.

If SSH answers with Permission denied, the server is working and the problem is with authentication: I can't connect over SSH.

Note Customers have no web console or VNC, and the panel has no forced reboot (hard reset) button. If “Reboot” doesn't help, only the BLACKBOX team can step in.

Quick look: CPU, memory, processes

uptime: the load average

uptime
nproc

 10:42:01 up 12 days,  3:05,  1 user,  load average: 3.85, 2.10, 1.20
2

The three numbers after load average are the average load over the last minute, the last 5 minutes and the last 15 minutes. Compare them with the server's number of vCPUs: nproc prints it, and it also appears on the server card in “My Servers”, in the “Spec” row (for example, “2 vCPU · 4 GB · 40 GB”).

In the example, 3.85 on 2 vCPUs means overload, and a first number much higher than the third shows that the load has risen in the last few minutes. On Linux, the load also counts processes that are waiting for the disk: a high load while the CPU is almost idle points to the disk (the wa column below).

top or htop: which process is using resources

top

At the top, top shows the %Cpu(s) line (its columns are explained under vmstat) and memory; below that, it lists the processes, most active first. Useful keys: P sorts by CPU, M by memory, 1 shows each vCPU separately, q quits.

htop shows the same data, in color and easier to read. On Ubuntu and Debian, install it like this:

apt update
apt install -y htop

On AlmaLinux and CentOS Stream, the package comes from the EPEL repository:

dnf install -y epel-release
dnf install -y htop

The list of processes, sorted by CPU and by memory, which you can copy into a support ticket:

ps aux --sort=-%cpu | head -n 15
ps aux --sort=-%mem | head -n 15

free -h: memory

free -h

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       118Mi        24Mi       512Mi       356Mi
Swap:             0B          0B          0B

Look at the available column, not free: Linux uses free memory as cache (buff/cache) and releases it when applications need it. Memory is exhausted when available drops close to zero and swap, if there is any, is full. Swap: 0B means the server has no swap.

vmstat 1 5: how things change over a few seconds

vmstat 1 5

The command prints 5 lines, one second apart. The first line is the average since the server started, so read the lines after it.

The st value exists only on virtual servers, and a few percent now and then is normal. If st stays high for minutes on end even though your applications aren't putting much load on the CPU, write to support and attach the output of vmstat 1 5.

The disk: space and speed

df -h
df -i

df -h shows the space used on each partition: watch the Use% column for /. df -i shows inodes (the number of files): when IUse% reaches 100%, no new files can be created, even if there is space left. A full disk stops databases and websites. How to find what is taking up space and how to free it: The server's disk is full.

You measure the disk load with iostat, from the sysstat package. Install it on Ubuntu and Debian:

apt update
apt install -y sysstat

On AlmaLinux and CentOS Stream:

dnf install -y sysstat

Then run:

iostat -x 1 3

The command prints 3 reports, one second apart; the first is the average since boot. For the main disk (usually vda or sda), watch:

To find the process that reads or writes the most, use pidstat from the same package (the kB_rd/s and kB_wr/s columns):

pidstat -d 1 5

On the plans page, the Basic family is described with a 300 IOPS disk, and the Standard and CPU families with 3000 IOPS. If r/s and w/s added together stay close to this value, the disk's speed is limiting the server. An upgrade from the panel stays within the same plan family; for a different disk type, write to us.

The network and services

Which programs are listening on ports

ss -tulpn

Each line shows an open port and the program listening on it, for example 0.0.0.0:80 with users:(("nginx",…)). 0.0.0.0 or * means all addresses, and 127.0.0.1 means only the server itself. If the website doesn't respond and ports 80 and 443 are missing, the web server isn't running. Which ports can be reached from the internet: Firewall: network filtering and ufw/firewalld on the server.

Traffic and connections

sar -n DEV 1 5
ss -s

sar (also from sysstat) shows, every second, the traffic received and sent on each interface, in the rxkB/s and txkB/s columns. ss -s counts the open connections. The addresses with the most connections:

ss -tn state established | awk 'NR>1 {print $4}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head

SSH password-guessing attempts

On Ubuntu and Debian:

journalctl -u ssh --since "1 hour ago" | grep -ciE "failed password|invalid user"

On AlmaLinux and CentOS Stream:

journalctl -u sshd --since "1 hour ago" | grep -ciE "failed password|invalid user"

The result is the number of failed login attempts in the last hour. Hundreds or thousands mean that bots are trying passwords on your server. Install an SSH key, then disable password login from the panel with the “Disable password login” button (Enabling and disabling SSH password login), and install fail2ban (Protection against password-guessing attempts with fail2ban). If the server is receiving a lot of traffic from many addresses and the network is saturated, write to support.

Failed services and errors in the log

systemctl --failed
journalctl -p err -b

systemctl --failed lists the services that have failed; 0 loaded units listed. means there are none. journalctl -p err -b shows the errors since the last boot (exit with q). For a service in the list, check its status and latest messages, then restart it:

systemctl status SERVICE_NAME
journalctl -u SERVICE_NAME -n 50 --no-pager
systemctl restart SERVICE_NAME

Running out of memory (OOM)

When the RAM and the swap run out, the Linux kernel forcibly stops a process, usually the one using the most memory (the OOM killer). This is usually the database or the application: the website goes down suddenly, with no error in the application. Check:

journalctl -k | grep -i "out of memory"
dmesg -T | grep -iE "out of memory|killed process"

A line like this one confirms the cause:

Out of memory: Killed process 1234 (mysqld) total-vm:2457600kB, anon-rss:1503232kB, …

What to do:

1. Start the stopped service again with systemctl restart (see the section above).
2. Add swap as a reserve for short spikes: Adding swap space.
3. Reduce the memory the application uses: fewer PHP-FPM processes (pm.max_children), a smaller buffer for MariaDB/MySQL (innodb_buffer_pool_size), memory limits for Docker containers.
4. If the application constantly needs more memory, move to a larger plan: Server upgrade: moving to a larger plan.

Common causes

If the process belongs to a service (nginx, php-fpm, mariadb, etc.), restart the service:

systemctl restart SERVICE_NAME

Otherwise, ask the process to stop (PID is the number in the first column of top):

kill PID

Only if the process is still running after a few seconds, force it to stop:

kill -9 PID

Warning Before you stop a process, find out what it is with ps -fp PID or systemctl status PID. Don't stop the ssh service (sshd on AlmaLinux and CentOS Stream): you would lose access. The alloy process is the agent of the Monitoring service; without it, the charts in the panel stop. An unknown process that keeps the CPU busy may be a sign that the server has been compromised: Your server was hacked or is under attack: what to do.

The charts in the panel

The commands show what is happening right now. To see when the problem started, use the “Monitoring” page in the panel. For servers with the Monitoring service active, the “Trends” block shows the “CPU usage (%)”, “RAM usage (%)”, “Disk usage (%)”, “Network (bytes/s)”, “Load average (1m)” and “Processes” charts, over ranges from “1 h” to “90 days”. Metrics are kept for about 15 days. On the same page, the “Alerts” card shows the alerts for your servers and can send you emails.

• What the page shows: The “Monitoring” page.
• Alerts and emails: Alerts and email notifications.
• How to get the service: The Monitoring service: the agent installed on the server.

Without the Monitoring service, the page has no data about the server; diagnose it with the commands in this guide.

What to send to support

If you can't find the cause, open a support ticket: “Contul meu” (My account) → “Ajutor și suport” (Help and support) → “Tichet nou” (New ticket) (Opening a support ticket). In the “Server (opțional)” (Server (optional)) field, enter the server's IP address. In “Descrieți problema” (Describe the problem), say when the problem started and what you have tried, then paste the output of these commands:

uptime
free -h
df -h
vmstat 1 5
ps aux --sort=-%cpu | head -n 15

The description accepts at most 10,000 characters, and longer text is cut off without warning. Don't send passwords, private keys or API tokens.

Frequently asked questions

The load average is 4 and the server has 2 vCPUs. Is that serious? Processes are waiting in a queue. If it lasts only a short time (a backup, an update), it's not a problem. If it goes on and the website responds slowly, look for the process with top; if it's your application's normal load, you need a larger plan.

free -h shows almost 0 in the free column. Is the server running out of memory? Not necessarily. What matters is the available column: the memory in buff/cache is released when applications need it.

The server crashed and works again after a reboot. How do I find the cause? Look at the errors from the previous boot and at any processes stopped for lack of memory:

journalctl --list-boots
journalctl -b -1 -p err
journalctl -k -b -1 | grep -i "out of memory"

If journalctl --list-boots shows only one boot, the log is not kept across reboots. In that case, look for the messages in /var/log/syslog (Ubuntu, Debian) or /var/log/messages (AlmaLinux, CentOS Stream), if the file exists, and in the “Monitoring” charts, if the server has the Monitoring service. To keep the log from now on, create its permanent directory:

mkdir -p /var/log/journal
systemctl restart systemd-journald

The iostat, pidstat, sar or htop command doesn't exist. Install the sysstat package (for the first three) or htop, with the commands in the sections above.

Can I see the server's load without SSH? In the panel, only on the “Monitoring” page, for servers with the Monitoring service. The panel doesn't even show whether the server is on or off. An AI assistant connected to your account can also run the commands in this guide for you: Running commands on the server through AI.