Utilisation against latency, the queueing knee

1. State the knee as a ratio before any tool is opened: "at 90% busy, expect about ten times the work on average, and a p99 near forty-six times". It explains most "traffic went up a little and latency exploded" incidents in one sentence (the curriculum's pro tip), and it holds only for random arrivals and varying work (steps 9–10). When: someone reads a 90% CPU graph as "10% to spare" (steps 5–8). Verify: tip 4.1's run at 90% busy: mean 9.7x the work · p99 45.1x · formula 10.0x and 46.1x Status: RAN.

Every graded script checks each hash and asserts the passage it relies on before it runs. No item is keyed on a quoted passage; every key is executed. Valid as of 2026-10-02.

• Google SRE book, Alejandro Forero Cuervo, "Handling Overload": https://sre.google/sre-book/handling-overload/ (sre-handling-overload.txt). The curriculum row's named source. Quoted: "In a majority of cases (although certainly not in all), we've found that simply using CPU consumption as the signal for provisioning works well"; "As utilization approaches configured thresholds, we start rejecting requests based on their criticality (higher thresholds for higher criticalities)" (that rejection is scale-backpressure-admission-shedding's; this lesson only names utilisation as the signal). Supports steps 1 and 13.
• Google SRE book, Rob Ewaschuk, "Monitoring Distributed Systems": https://sre.google/sre-book/monitoring-distributed-systems/ (sre-monitoring.txt). Quoted: saturation is "How "full" your service is"; "Note that many systems degrade in performance before they achieve 100% utilization, so having a utilization target is essential."; "Latency increases are often a leading indicator of saturation."; "page a human when one signal is problematic (or, in the case of saturation, nearly problematic)"; "If you run a web service with an average latency of 100 ms at 1,000 requests per second, 1% of requests might easily take 5 seconds." Supports steps 8, 12–14.
• Wikipedia, M/M/1 queue: https://en.wikipedia.org/wiki/M/M/1_queue (wp-mm1-queue.txt). Quoted: "arrivals are determined by a Poisson process and job service times have an exponential distribution"; "We write ρ = λ/μ for the utilization of the buffer and require ρ < 1 for the queue to be stable."; "The average response time or sojourn time (total time a customer spends in the system) … can be computed using Little's law as 1/(μ − λ)"; for first come, first served, "the response time they experience (the sum of both waiting time and service time) has Laplace transform (μ − λ)/(s + μ − λ)", an exponential time with mean 1/(μ − λ), whose p99 is that mean × ln 100. Supports steps 1, 4, 8 and 11.
• Wikipedia, Kingman's formula: https://en.wikipedia.org/wiki/Kingman's_formula (wp-kingman.txt). Quoted: "an approximation for the mean waiting time in a G/G/1 queue"; "The formula is the product of three terms which depend on utilization (U), variability (V) and service time (T)."; "ca is the coefficient of variation for arrivals … and cs is the coefficient of variation for service times." With random arrivals (cₐ = 1) it gives the exact mean for any work; this lesson runs it for cₛ = 1 and cₛ = 0. Supports steps 9–10.
• Wikipedia, Kendall's notation: https://en.wikipedia.org/wiki/Kendall's_notation (wp-kendall.txt). Quoted: "A M/M/1 queue means that the time between arrivals is Markovian (M), i.e. the inter-arrival time follows an exponential distribution of parameter λ." Supports the M/M/1 label in step 4.
• Not fetched: Leonard Kleinrock, Queueing Systems, Vol. 1: Theory (1975), the row's first source. It is a book and not fetchable as text, so it keys and quotes nothing here; the formulas above are checked against the saved Wikipedia text and against the runs.