Why is the box slow? Learn to read load average, iowait, iostat and pressure stall information without drawing the wrong conclusion — and to profile with perf, flame graphs and eBPF when the metrics run out.
Most Linux performance metrics are easy to read and easy to misread. A load average of 20 can sit next to idle CPUs, because Linux counts tasks blocked in uninterruptible sleep. 60% iowait means the processors were doing nothing, not that they were busy. %util at 100% on an NVMe drive can mean the device is barely working. Each of those readings sends people to fix the wrong thing.
This track is about the second question — what does this number actually mean, and what do I check next. It walks through methodology (the USE method applied, Little's Law, the observer effect, why a dd benchmark lies), CPU and scheduling (run queue, steal time, cgroup quota and throttling), memory (page cache and reclaim, swappiness, the OOM killer's victim selection, thrashing without swap), disk I/O (await, queue depth, IOPS against throughput, inodes and reserved blocks) and tracing (strace against perf, flame graphs, tracepoints and eBPF).
It is deliberately the layer above command lookup: the commands live in the practical Linux track, while this one is about interpreting what they print. And unlike most of what an engineer memorises, it ages well — how you find out why a machine is slow reads the same in five years.
Each module is a set of flashcards — 82 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
How to approach a slow system before touching it
16 cardsReading CPU metrics that mean less than they look
17 cardsPage cache, reclaim, swap and the OOM killer
16 cardsReading iostat without drawing the wrong conclusion
17 cardsperf, flame graphs and eBPF without misreading them
16 cardsA taste of the real flashcards. Pick an answer, then reveal the explanation.
What does lowering a process's nice value actually change?
What distinguishes a major page fault from a minor one?
What time does the await column in iostat cover?
What does the x-axis of a flame graph represent?
Each card is one practical concept with multiple options. Pick what you think is right.
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
High load with idle CPUs, or iowait mistaken for a busy processor, sends teams tuning a resource that was never the bottleneck.
CPU throttling against free cores and OOM kills with RAM to spare are cgroup behaviour, and they only make sense once you read cpu.stat and memory.max.
A flame graph x-axis is not time and an on-CPU profile cannot see blocked threads — two misreadings that hide the real cost.
Queueing behaviour, page cache and the kernel scheduler outlive whatever framework or cloud you are running this year.
The practical track teaches the commands — which tool prints what. This one starts where that stops: interpreting the output, so a number like await, %si or aqu-sz points you at the right subsystem.
No, but you should be comfortable at the command line and know roughly what a process, a page and a block device are. Every card is framed around a concrete reading and what it implies.
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
It covers the host and cgroup layer that containers are built on — cpu.max, throttling, memory.high and memory.max. Kubernetes-level resource tuning lives in the Kubernetes Ops tracks.
Plant your first seed today. Ten minutes a day is all it takes to stop guessing at metrics and start reading them.