Understanding the Linux top Command
A practical field-by-field guide to load average, CPU states, memory, process columns and the top questions that appear in Linux and DevOps interviews.
A realistic top screen
toptop - 19:18:43 up 12 days, 4:27, 2 users, load average: 1.82, 1.41, 1.16
Tasks: 248 total, 2 running, 245 sleeping, 0 stopped, 1 zombie
%Cpu(s): 12.4 us, 3.1 sy, 0.0 ni, 82.8 id, 1.4 wa, 0.0 hi, 0.3 si, 0.0 st
MiB Mem : 15936.2 total, 1024.7 free, 10821.4 used, 4090.1 buff/cache
MiB Swap: 2048.0 total, 1536.0 free, 512.0 used. 4268.5 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18432 app 20 0 4.2g 1.8g 18432 R 96.7 11.6 42:18.21 java
2187 mysql 20 0 6.8g 2.1g 24576 S 24.3 13.5 188:42.09 mysqld1 — Header: time, uptime, users and load average
19:18:43 is current system time, up 12 days, 4:27 is uptime, and 2 users is the number of logged-in user sessions. The three load averages represent approximately 1, 5 and 15 minutes.
What to check: compare the recent value with the longer windows and CPU count, but do not call load “CPU percentage.” Linux load includes runnable tasks and tasks waiting in uninterruptible sleep. A 1-minute value rising well above the 5/15-minute values tells you pressure is increasing, not which resource caused it.
Next: inspect CPU states and, when load is high while CPUs are relatively idle, investigate I/O or blocked tasks.
2 — Tasks line
total is the task count; running means runnable/running; sleeping usually means waiting; stopped means stopped/traced; zombie means a child exited but its parent has not yet collected its status.
Interview point: a zombie is not a process consuming CPU indefinitely. The process has already exited; its parent must reap the exit status. A growing zombie count points toward parent-process handling.
3 — CPU states: us, sy, ni, id, wa, hi, si, st
| Field | Meaning | What it can suggest |
|---|---|---|
us | User-space CPU time | Application computation |
sy | Kernel/system CPU time | Kernel work, syscalls, networking or driver activity |
ni | User CPU time for niced tasks | CPU used by processes with adjusted nice priority |
id | Idle CPU | How much CPU time is not busy |
wa | I/O wait | CPU idle while outstanding I/O exists; investigate I/O rather than declaring a CPU bottleneck |
hi | Hardware interrupt time | Hardware interrupt processing |
si | Software interrupt time | Softirq work such as networking |
st | Steal time | Virtual CPU time unavailable because the hypervisor ran something else |
4 — Memory: free is not the same as available
free is completely unused RAM. buff/cache includes memory Linux can use for caching. avail Mem estimates how much memory can be supplied to new workloads without swapping heavily. Therefore low free by itself is not proof that a server is out of memory.
What to check: available memory, swap use/activity, memory pressure and whether a process is steadily growing. For an OOM incident, historical/kernel evidence is stronger than a healthy-looking snapshot after the victim has already been killed.
5 — Process columns
| Column | Meaning |
|---|---|
PID | Process ID |
USER | Effective owner |
PR | Scheduling priority shown by top |
NI | Nice value; user-space priority adjustment |
VIRT | Total virtual address space mapped/available to the process; not physical RAM usage |
RES | Resident memory currently in RAM |
SHR | Resident memory that may be shared |
S | Process state, such as R running or S sleeping |
%CPU | CPU usage; a multithreaded process can exceed 100% depending on top mode/system |
%MEM | Resident-memory share of physical RAM |
TIME+ | Accumulated CPU time used by the task |
COMMAND | Process/command name or command line depending on display mode |
VIRT vs RES — a common interview question
A process showing VIRT=8g does not mean it occupies 8 GiB of RAM. Virtual address space can include mapped files, shared libraries, reserved address space and pages not resident in physical memory. RES is closer to the current resident physical footprint, although shared pages mean it should not be blindly summed across processes.
6 — Useful interactive keys
| Key | Action |
|---|---|
P | Sort by CPU |
M | Sort by memory |
1 | Toggle per-logical-CPU display |
H | Toggle thread display |
c | Toggle command name/full command line |
q | Quit |
k key sends a signal to a process. That changes system state and can interrupt a production workload. Identify the process and use the application/service manager’s normal control path when appropriate.7 — A practical reading order
- Is load rising or stable?
- Are CPUs actually busy? Which CPU state dominates?
- Is available memory healthy?
- Which process dominates CPU or resident memory?
- Is that process expected to consume the resource?
- Use a second tool such as
ps,pidstat,iostat,freeor application diagnostics to confirm the hypothesis.