The processor shows a hundred percent: the question to ask before reading a number

You look at the panel and the processor looks high. Before you do anything there is a single question to ask: what period does this number describe?

Because three different numbers wear the same name, and the three say different things.

Three numbers with the same name

The average since boot. If the machine was busy for three days two months ago, that busyness is still sitting inside this average. It does not answer "right now".

The accumulated total. It never goes down. It tells you about the past, not about today.

The difference between two samples. Two measurements are taken and the change between them is read. Only this one answers "right now".

The classic trap

The standard tool that lists processes shows the since-boot average on its first screen. If you look at that first screen and act, you have intervened in the past rather than in today.

The right way is to take at least two samples and read the second one. The tool itself is not wrong; the way it is read is.

The same mistake takes the same shape everywhere

We have seen this shape twice already in this wiki.

On disk wear we said not the percentage but the slope: eighty five percent left means ten years on one disk and eight months on another.

On dropped packets we said not the total but the rate: a machine that had one bad hour last year is made to look guilty for life by its counter.

On the processor it is not the average but the difference. Three different places, one reading error.

It can be written as a general rule: a number without a stated time window is not a measurement. Before acting on any number, ask which window it covers.

When the processor really is high

Then a second distinction is needed: is one machine busy, or is the server short?

It is normal for a virtual machine to use the whole share it was given. If you gave it two cores and it has filled those two cores, the system is working exactly as designed.

The problem is the moment the server saturates: guests start not getting what they ask for and all of them slow down together.

There is also something often confused: load is not processor usage. Load counts things that are waiting, and some of those may be waiting not for the processor but for the disk. It is possible for load to be high while the processor is idle, and that tells you to look somewhere else.

What Atlas does

When Atlas lists the server's most processor-hungry processes it deliberately takes two samples and reads the second one.

The reason is exactly the trap above: the first sample carries the since-boot average and showing it would be misleading. The difference is not a small detail; a list sorted by the first sample presents a process that was busy months ago as today's culprit.

Another small but honest detail: the result of this measurement is kept briefly and requests arriving at the same time are tied to a single measurement. The reason: while the card is open it refreshes every few seconds, and starting a new measurement on every refresh puts needless load on the server.

This is the same principle as in the heat article: the thing that watches should not be the thing that costs.