Why did my server slow down? Telling CPU, RAM, disk and network bottlenecks apart

"The server is slow" is a symptom, not a diagnosis. Four different resources produce the same symptom and the fix for each one is completely different. Before you upgrade anything you have to measure which one is limiting you; the order below does that in five minutes.

One question first: where does the slowness show up?

Is everything slow, or just one application? If every operation on the server — listing files, running a command, logging in — is slow, one of the system resources has run out. If only a single application is slow, there may be no server bottleneck at all; the problem can be in a query, in a third-party service, or in the application itself.

1. Load average: look at it, but read it correctly

uptime
nproc

The three numbers in uptime are the 1, 5 and 15 minute load averages. The critical detail: on Linux the load average counts not only processes waiting for CPU but also processes waiting for disk. A high load therefore does not prove that the CPU is saturated.

Compare the number against nproc. On a 4-core machine a load around 4 means full, while 15 means a serious queue. Reading the three numbers together also gives you the direction: if the 1-minute value is above the 15-minute one the load is rising, if it is below you are on the tail of a peak that already passed.

2. Is the CPU busy, or is it waiting for the disk?

top

The %Cpu(s) line makes the distinction. us is user processes, sy the kernel, wa the share spent waiting on I/O, id idle, and st the time the hypervisor did not give you.

• High `us`: the bottleneck really is the CPU.
• High `wa`: the CPU is idle and the disk cannot keep up. Go to step 4.
• High `st`: the physical machine is not giving you the CPU time you were promised. This cannot be solved inside the server; it is a support ticket.

Pressing 1 while top is open lists the cores individually. If one core is pinned while the others are idle, your workload is single-threaded and adding cores will change nothing; the whole distinction is in how much vCPU and RAM a server needs.

3. Has memory really run out?

free -m

Look at the `available` column, not free. Linux uses spare memory as disk cache, so a low "free" figure is normal. The bottleneck indicator is available dropping to a few hundred MB at peak hour.

When memory runs out two things happen, and both leave a trace. The machine starts paging to swap — which turns a crash into a slowdown, but is not a fix. Or the kernel kills the process using the most memory:

dmesg -T | grep -i "out of memory"

If that command prints anything, your application was terminated silently; it is the most common cause behind "the server stopped on its own".

4. The disk: is it full, or is it slow?

These are two separate problems and they get confused.

df -h
df -i

If usage is pinned at 100% the problem is capacity, and finding what is eating it and clearing it safely is a job of its own: the disk is full. The inode ratio in df -i can fill up too — then there is visible free space but no new file can be created.

If capacity is fine, look at latency:

iostat -x 1 5

That command ships with the sysstat package. The two decisive columns are %util and await. If await sits at tens of milliseconds, the bottleneck is the disk. Why the expected figures are a tier apart on NVMe: what is an NVMe SSD

5. The network, or the server?

If the slowness is felt remotely but every measurement inside the server is clean, the problem is on the path rather than on the machine. On a game server the equivalent symptom is rising ping, and it needs its own diagnostic order: why did my ping go up. If there is a sudden, unexplained jump in inbound traffic, rule this out first: am I under a DDoS attack

6. If all four are clean, the problem is in the application

Slowness while the hardware looks idle almost always comes from an unindexed query, a lock, or a wait on an external service. Turning on the slow query log solves most cases on its own: MySQL performance tuning

If the measurements really do point at a hardware limit, upgrading is the right call. You can pick how much of which resource to add in the server configurator and see the monthly figure immediately, and if you have hit the ceiling of a virtual server you can check at which point a dedicated machine closes the gap, with prices. An upgrade made without measuring is usually the right money spent in the wrong place.

When to open a support ticket

In three cases there is nothing left to look for inside the server:

• st (steal) is consistently high — that is not something you can fix on your side.
• iostat shows a high await while your own processes generate no meaningful I/O.
• None of the five measurements shows a bottleneck but the slowness is objectively measurable.

Put the top and iostat -x output in the ticket, along with the time the slowness started and which operation is slow. On virtual server plans the resource graphs are kept in the panel, so a comparison against the past is possible too; the answer to "when did it start" usually halves the diagnosis.