A server is slowing down, but top does not always show a process that is 100% blocked. With vmstatYou can see in a few seconds whether the tasks are waiting on the processor, the disk, or the memory. Provided, of course, that you don’t draw any conclusions from the first line.

free, iostat

Run vmstat on multiple samples

vmstat usually belongs in the package procps Or procps-ngStart by taking a reading every second, with six lines in total:

vmstat 1 6

The first line summarizes the activity since the start. It doesn’t precisely describe the second line that just elapsed. To diagnose an ongoing slowdown, focus on reading the following lines. The option -w widens the columns if the values ​​become difficult to read:

vmstat -w 1 6

Keep a second terminal open as well. Start the reading, reproduce the slow action, and then note the columns that change at the same time. A single spike during a save or compile operation doesn’t carry the same weight as a queue that remains high for several minutes.

Read r, b and the CPU columns together

In the group trials, r This indicates the number of executable tasks that are running or waiting for processor time. Compare this value to the number of logical processors:

nproc
uptime

r remains well above the number of available CPUs and that us Or sy If the high levels are high, the machine is probably lacking processor time. us corresponds to the code executed in user space, while measures the work of the core. A value sy Unusually high can come from a large number of system calls, interrupts, or context changes.

The column b This includes tasks stuck in an uninterruptible sleep state, often waiting for input or output. If ride with waCheck the storage before blaming the CPU. wa represents the time during which the processor is idle while an input/output operation is pending.

• id CPU idle time;
• wa : waiting for entry/exit;
• st : time taken by the hypervisor on a virtual machine.

On a VPS, a st load average under Linux This reading is complete, because the load also includes some blocked tasks and is not limited to a CPU percentage.

Recognizing true memory pressure with if and only if

The columns swpd, free, buff hidden provide a compact view of memory. They are not sufficient to indicate saturation. Linux reuses part of the RAM as a cache, and In vmstat does not replace the column available of the order .

free -h
swapon --show

swpd indicates the amount of swap used. A non-zero value does not prove that the system is still exchanging pages. Pay particular attention to this. if And so based on recent samples:

• if : data read from swap to RAM;
• so : data moved from RAM to swap.

Repeated values ​​in if Or so, a memory available free and available RAM details the role of the cache, while the article on the swap under Linux explains why you shouldn’t empty it reflexively.

In the section io, bi And bo represent the blocks received and sent per second. They show overall activity, but not the responsible device or its response time. If remain high, switch to iostat

iostat -xz 1 5

Look in particular , the queue and %util for each disk. Don’t rely on a single threshold: an NVMe SSD can handle multiple operations in parallel, whereas a hard drive degrades quickly with random access. Compare the values ​​to the machine’s usual behavior and the current processing.

The article on iostat under Linux explains how to connect these counters to the correct device. If the slowdowns are accompanied by errors, also check the kernel messages:

journalctl -k -b -p warning..alert
systemctl --failed

Retrieve the process before restarting a service

vmstat Indicates the likely nature of the blockage, not the process name. Then sort the tasks according to the suspected resource:

ps -eo pid,user,stat,ni,pcpu,pmem,comm --sort=-pcpu | head
ps -eo pid,user,stat,ni,pcpu,pmem,comm --sort=-pmem | head
htop

In STAT, a state D This generally corresponds to uninterruptible sleep. It can explain a column b The PID is high, but don’t kill it immediately. First, identify its service, open files, and logs:

ps -fp PID
systemctl status service-concerned --no-pager
journalctl -u service-concerne -n ​​100 --no-pager

A database can consume a lot of RAM without leakage, and a process in a state

Decide based on overlapping counters

The diagnosis becomes usable when several columns tell the same story:

• CPU saturated : r remains high compared to nproc, with us Or sy high and little id ;
• memory pressure available stay low, if Or so return on several samples and the latency increases;
• disk waiting : b And wa rise, then iostat confirms a slow device;
• virtualization contention : st remains visible on a VM despite moderate internal load.

To search for an OOM killer instance, use the kernel logs:

vmstat manual page describes each field. That of details storage metrics. Keep your readings before and during the slowdown: without comparison over time, even a high counter remains difficult to interpret.

sudo apt update && sudo apt upgrade