Why 1265% CPU in top Isn’t a Crash: Decoding Linux Metrics Correctly

Common Misunderstandings When Using top

Misconception 1: %CPU cannot exceed 100%

top reports %CPU as the number of CPU cores used multiplied by 100 %. On a 16‑core system a value of 1265 % means roughly 12.6 cores are busy.

PID USER VIRT RES %CPU %MEM COMMAND
6308 mysql 220.7g 212.7g 1265 84.5 mysqld

Misconception 2: High load average means CPU is saturated

Load average counts processes that are runnable or waiting for CPU. Compare the load value with the total number of CPU cores. Example mappings:

4 cores → load ≈ 4 → near full load

16 cores → load ≈ 12 → acceptable

32 cores → load ≈ 12 → idle

Misconception 3: Low idle (id) percentage indicates a CPU problem

A line such as %Cpu(s): 39.9 us, 0.4 sy, 58.6 id shows that 58.6 % of CPU capacity is idle, i.e., more than half of the CPU is unused.

Misconception 4: Large VIRT means a memory leak

VIRT is the virtual address space a process can address; RES is the resident physical memory; SHR is shared memory. A large VIRT for MySQL is normal because of the InnoDB buffer pool, memory‑mapped files and malloc reservations.

VIRT : virtual address space the process can use

RES : resident physical memory actually used

SHR : shared memory

Misconception 5: Small “free” memory means out‑of‑memory

Linux uses free memory for caches. The relevant metric is “available” memory (Avail Mem). In the example the system shows about 30 GB available, so there is no memory pressure.

Misconception 6: top can directly pinpoint the root cause

top only shows which processes consume resources. To find why MySQL uses high CPU you must inspect MySQL queries, slow‑query logs, or other application‑level diagnostics.

Correct Usage of top

Determine the number of CPU cores, e.g. lscpu.

Compare the load average with the core count; load < cores does not indicate a performance problem.

Remember that on multi‑core systems %CPU can exceed 100 % because it reflects total core usage.

When evaluating memory, focus on the “available” column (e.g. avail Mem) rather than “free” or “buff/cache”.

Use the VIRT/RES/SHR columns to distinguish virtual address space from actual physical memory consumption.

After identifying a high‑CPU process, drill down with application‑specific tools (e.g. MySQL slow‑query log) to locate the underlying issue.