Linux / DevOps · 5 modules

Linux Performance & Troubleshooting

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.

flashcards
82
flashcards
per day
~10 min
per day
level
Advanced
level
modules
5
modules
About this topic

What does performance troubleshooting actually involve?

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.

What you'll learn

5 modules, seed to bloom

Each module is a set of flashcards — 82 in total. Answer, review, and watch your knowledge grow from seed to full bloom.

Methodology

How to approach a slow system before touching it

16 cards

CPU & Scheduling

Reading CPU metrics that mean less than they look

17 cards

Memory

Page cache, reclaim, swap and the OOM killer

16 cards

Disk & I/O

Reading iostat without drawing the wrong conclusion

17 cards

Tracing & Profiling

perf, flame graphs and eBPF without misreading them

16 cards
Try before you plant

Sample questions

A taste of the real flashcards. Pick an answer, then reveal the explanation.

Sample · Linux Performance & Troubleshooting

What does lowering a process's nice value actually change?

  • AIts relative weight when competing for CPU, which only matters while cores are contended
  • BIts reserved share of CPU time, which the scheduler guarantees whatever else is running
  • CIts maximum runtime per scheduling period, after which it is stopped until the next one
  • DIts placement priority, so the scheduler prefers cores that are currently unoccupied
Permalink & share
Sample · Linux Performance & Troubleshooting

What distinguishes a major page fault from a minor one?

  • AThe major fault has to read from a backing device; the minor one is satisfied from RAM
  • BThe major fault touches an unmapped address; the minor one touches a mapped page
  • CThe major fault happens in kernel space; the minor one happens in userspace code
  • DThe major fault kills the process; the minor one is retried transparently by the kernel
Permalink & share
Sample · Linux Performance & Troubleshooting

What time does the await column in iostat cover?

  • AQueue time plus service time — the full wait from issue to completion of a request
  • BService time only — the interval the device itself spent working on the request
  • CQueue time only — the interval before the device began working on the request
  • DCompletion time only — the delay between the device finishing and the caller waking
Permalink & share
Sample · Linux Performance & Troubleshooting

What does the x-axis of a flame graph represent?

  • AThe population of sampled stacks, sorted alphabetically to merge identical frames
  • BThe passage of time, so a frame's horizontal position shows when it was executing
  • CThe call order within each stack, from the first function called to the most recent
  • DThe cumulative cost, so frames are placed left to right from cheapest to most expensive
Permalink & share
How Gnoseed works

Learn it once, keep it for good

1

Answer a question

Each card is one practical concept with multiple options. Pick what you think is right.

2

Get the full answer

See the correct option plus a clear explanation, and a link to deeper docs when one is available.

3

Review at the right time

A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.

Why learn this

Why performance analysis is worth your time

Stop fixing the wrong thing

High load with idle CPUs, or iowait mistaken for a busy processor, sends teams tuning a resource that was never the bottleneck.

Diagnose containers properly

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.

Read a profile correctly

A flame graph x-axis is not time and an on-CPU profile cannot see blocked threads — two misreadings that hide the real cost.

Knowledge that does not expire

Queueing behaviour, page cache and the kernel scheduler outlive whatever framework or cloud you are running this year.

FAQ

Common questions

How is this different from the practical Linux track? +

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.

Do I need a performance background? +

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.

Is it free? +

Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.

Does it cover containers and Kubernetes? +

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.

Ready to find out why it is slow?

Plant your first seed today. Ten minutes a day is all it takes to stop guessing at metrics and start reading them.

Start learning free