Diagnose Linux performance

Coming soon. This course is planned; lessons and labs are not available yet. No release date has been announced.

Trace a slow client request through workload, queues and Linux resource evidence, then test a bounded intervention.

Intermediate · Latency and resource diagnosis

Before you begin

Know how a client reaches a Linux service and how to inspect processes, logs and basic network behavior.

The planned project

The planned project asks you to explain a service slowdown from measured evidence, test a change and verify correct responses under a changed workload.

Course scope

One Linux service under controlled load; the emphasis is diagnosis and preserved correctness.

Planned course outline

3 planned chapters and 6 lesson outlines.

1. Define and measure the symptom

   Use a repeatable request and a controlled workload before naming a bottleneck.

   1. Planned lesson: Set a client-visible baseline

      Planned task: Record response correctness, latency distribution, throughput and the load conditions.

      Changed case to investigate: A second client has a tighter deadline; decide which baseline answers its question.

   2. Planned lesson: Reproduce slow requests

      Planned task: Run a bounded workload and locate slow requests without hiding the tail in an average.

      Changed case to investigate: A brief burst creates a long tail; separate the burst from steady-state behavior.

2. Locate the constraint

   Compare the request path with resource pressure and queue evidence.

   1. Planned lesson: Read CPU, memory and I/O pressure

      Planned task: Inspect process, cgroup and stall signals alongside service behavior.

      Changed case to investigate: CPU is quiet while latency rises; investigate memory or I/O wait before adding CPU.

   2. Planned lesson: Explain queue growth

      Planned task: Relate arrivals, service time and pending work to a measured backlog.

      Changed case to investigate: A different traffic mix fills a downstream queue; revise the original bottleneck hypothesis.

3. Change and verify

   Test one intervention while preserving correct responses and resource limits.

   1. Planned lesson: Bound retries and timeouts

      Planned task: Choose a client budget and verify retries do not multiply work during a slowdown.

      Changed case to investigate: The dependency becomes slow instead of failing outright; recheck the retry load.

   2. Planned lesson: Test a resource tradeoff

      Planned task: Compare an intervention with the baseline under the same workload and correctness checks.

      Changed case to investigate: A larger input moves the bottleneck; remeasure rather than repeating the earlier fix.

See available courses