Sample questions
Linux Performance Monitoring Resource LimitsDifficulty 1
In the output of uptime or top, three load average numbers are shown, e.g. load average: 2.15, 1.80, 1.42. What do these three numbers represent?
- aThe average number of processes runnable or waiting on I/O over the last 1, 5, and 15 minutes, in that order✓
- bThe CPU temperature readings taken 1, 5, and 15 minutes ago. In practice, this framing does not match how the mechanism is documented to behave.
- cThe percentage of total RAM used 1, 5, and 15 minutes ago. This description sounds intuitive but conflicts with how the underlying system actually operates.
- dThe number of users logged into the system in the last 1, 5, and 15 minutes. Many engineers assume this at first, but it does not hold up once the tool's real behavior is checked.
Explanation:The three load average figures are exponentially-weighted moving averages of the number of processes in the runnable or uninterruptible-sleep (I/O-wait) state, sampled over the last 1, 5, and 15 minutes respectively. Comparing the three lets an operator see whether load is rising, falling, or steady.
Linux Performance Monitoring Resource LimitsDifficulty 1
A server has 8 CPU cores and uptime reports a load average of 4.00, 3.80, 3.50. What is the most reasonable interpretation?
- aThe system is critically overloaded, since any load average above 1.0 means the CPU is saturated. This description sounds intuitive but conflicts with how the underlying system actually operates.
- bThe system has headroom, since load averages roughly track demand for runnable/waiting work relative to the number of cores, and 4 is well below the 8 cores available✓
- cThe load average is meaningless on multi-core systems and should always be ignored. Many engineers assume this at first, but it does not hold up once the tool's real behavior is checked.
- dThe server is definitely swapping heavily, since load average only rises due to memory pressure. This is a common shortcut explanation that breaks down under closer technical scrutiny.
Explanation:As a rule of thumb, a load average close to (or below) the core count means demand is roughly keeping up with available CPU capacity; here 4 out of 8 cores suggests moderate, non-saturating demand. (a) wrongly applies a single-core rule of thumb to an 8-core box; (c) and (d) both misstate what the metric captures.
Linux Performance Monitoring Resource LimitsDifficulty 2
In top's CPU summary line: %Cpu(s): 22.0 us, 5.0 sy, 0.0 ni, 70.0 id, 3.0 wa, 0.0 hi, 0.0 si, 0.0 st, what do us and sy represent?
- a
us is time spent in the USB subsystem, sy is time spent syncing disks. Many engineers assume this at first, but it does not hold up once the tool's real behavior is checked. - b
us is uptime seconds, sy is system boot count. This is a common shortcut explanation that breaks down under closer technical scrutiny. - c
us is the percentage of CPU time spent running user-space processes, sy is the percentage spent running kernel (system) code on their behalf✓ - d
us and sy are two different ways of naming the exact same idle-time measurement. It is a plausible-sounding guess rather than something confirmed by the kernel or tool documentation.
Explanation:us (user) tracks CPU cycles spent executing normal user-space program code, while sy (system) tracks cycles spent in the kernel handling system calls, interrupts, and other kernel-side work triggered by those processes. Together with id (idle) and wa (iowait) they should sum to roughly 100%.
Linux Performance Monitoring Resource LimitsDifficulty 1
In top, what does the %wa (iowait) figure in the CPU summary line indicate?
- aThe percentage of CPU cores that are physically powered off. This is a common shortcut explanation that breaks down under closer technical scrutiny.
- bThe percentage of processes waiting for a user to type input on the keyboard. It is a plausible-sounding guess rather than something confirmed by the kernel or tool documentation.
- cThe percentage of time the CPU spends running virtualization/hypervisor code. In practice, this framing does not match how the mechanism is documented to behave.
- dThe percentage of time the CPU was idle while at least one process was waiting on a pending disk (or other block) I/O operation to complete✓
Explanation:%wa measures idle CPU time during which the CPU had nothing to execute specifically because outstanding I/O requests hadn't completed yet. A high and sustained %wa is a classic sign that disk (or network storage) I/O, not CPU, is the bottleneck.
Linux Performance Monitoring Resource LimitsDifficulty 1
What is the most commonly cited practical difference between top and htop for a Linux operator?
- a
htop provides an interactive, scrollable, color-coded interface (per-core bars, easier process search/kill/sort) built on top of the same underlying data top shows✓ - b
top only works on remote servers, while htop only works on the local desktop. It is a plausible-sounding guess rather than something confirmed by the kernel or tool documentation. - c
htop reads a completely different, more accurate kernel data source than top, so their numbers frequently disagree. In practice, this framing does not match how the mechanism is documented to behave. - d
top cannot show memory usage at all, only htop can. This description sounds intuitive but conflicts with how the underlying system actually operates.
Explanation:Both tools read the same kernel-exposed process/CPU/memory data (mainly via /proc); htop just presents it more conveniently — a scrollable, colorized, mouse-friendly view with per-core CPU bars and easier interactive process management. top is more minimal but ships virtually everywhere by default.
Linux Performance Monitoring Resource LimitsDifficulty 2
Given
free -h output:
total used free shared buff/cache available
Mem: 15Gi 2.1Gi 500Mi 200Mi 12Gi 12Gi
Why is
available (12Gi) so much larger than
free (500Mi)?
- aIt's a bug;
free and available should always be equal on a healthy system. In practice, this framing does not match how the mechanism is documented to behave. - bMost of the memory is used for buffer/cache, which the kernel can reclaim on demand for applications, so
available accounts for that reclaimable memory while free only counts completely unused memory✓ - c
available includes swap space, while free does not count swap at all. This description sounds intuitive but conflicts with how the underlying system actually operates. - d
available is measured in a different unit than free, which is why the numbers differ. Many engineers assume this at first, but it does not hold up once the tool's real behavior is checked.
Explanation:Linux aggressively uses spare RAM for the page/buffer cache to speed up disk access, since that memory would otherwise sit idle. That cached memory is reclaimable — the kernel can evict it instantly if an application needs RAM — so available (free + reclaimable cache) is the more useful figure for judging real memory pressure than the narrow free column.