M/M/1 Queue Utilisation

Utilisation is the plainest number in queueing theory and the most misread. It is the arrival rate divided by the service rate, and it is the fraction of time the server is busy. Thirty jobs an hour into a server that can clear forty gives $\rho = 0.75$. Check it by time instead of by rate and you get the same thing: each job takes 1.5 minutes, thirty of them fill 45 of every 60 minutes.

What matters is what happens as $\rho$ approaches 1. Queue length goes as $\rho/(1-\rho)$, so at 50% busy there is 1 job in the system, at 90% there are 9, and at 99% there are 99. The curve is not steep, it is asymptotic. This is why a server at 85% utilisation feels fine and the same server at 95% feels broken, even though you only added 12% more load. It is also why capacity planners treat 70% as full: the remaining headroom is not spare capacity, it is the buffer that keeps response times finite when traffic varies.

The classic mistake is aiming for high utilisation as a virtue. A CPU pinned at 95% looks efficient on a dashboard and is a latency catastrophe underneath. Note too that $\rho \ge 1$ is not an error, it is a diagnosis: work is arriving faster than it can leave, and the queue will grow until something else breaks. The formula will report it happily, and it is telling you to add a server rather than to tune one.