Der unterschaetzte Preis der Auslastung - Warum 10% Leerlauf lebenswichtig sind
"Die sitzen 10% der Zeit nur rum!" - Ein Satz, der in Fuehrungsetagen gerne faellt. Er klingt logisch. Er ist mathematisch nachweisbar falsch. Und er hat schon viele Systeme zum Kollaps gebracht.
Die Warteschlangen-Theorie (Queueing Theory) ist ein Teilgebiet der Wahrscheinlichkeitsrechnung, das beschreibt, wie sich Systeme unter zunehmender Last verhalten. Das einfachste Modell heisst M/M/1:
M - Markov-Ankuenfte
Kunden/Aufgaben kommen zufaellig (Poisson-verteilt) an. Kein fester Takt - mal viel, mal wenig. Genau wie Datenbankabfragen, Kassenanfragen oder Anrufe im Callcenter.
M - Markov-Bedienung
Auch die Bearbeitungszeit ist zufaellig (exponentialverteilt). Manche Abfragen dauern 1ms, andere 500ms. Der Durchschnitt ist bekannt, der Einzelfall nicht.
1 - Ein Server
Ein Bearbeiter, ein CPU-Kern, eine Kassierin, ein DB-Thread. Das Modell laesst sich auf mehrere Server (M/M/c) erweitern - das Prinzip bleibt gleich.
Dieses Modell gilt ueberall: Kassiererinnen im Supermarkt, Sicherheitskontrollen am Flughafen, CPU-Kerne im Server, Datenbankverbindungen im Connection Pool, HTTP-Worker in einem Webserver. Die Mathematik dahinter ist dieselbe.
Die zentrale Kennzahl ist die Auslastung rho:
Die durchschnittliche Anzahl wartender Kunden (Queue Length) berechnet sich mit:
Was diese Formel fuer verschiedene Auslastungsgrade liefert, ist alarmierend:
| Auslastung ρ | Leerlauf | Lq (wartende Einheiten) | Wartezeit-Faktor | Bewertung |
|---|---|---|---|---|
| 50% | 50% | 0.5 | Basis | Sehr komfortabel |
| 70% | 30% | 1.6 | 3x | Gut |
| 80% | 20% | 3.2 | 6x | Akzeptabel |
| 90% | 10% | 8.1 | 16x | Grenzwertig |
| 95% | 5% | 18.1 | 36x | Kritisch |
| 99% | 1% | ~98 | 196x | Kollaps |
| 100% | 0% | ∞ | ∞ | System steht still |
Eine Baeckerei hat eine Kassiererin. Im Schnitt kommen 9 Kunden pro Minute, sie schafft 10 pro Minute. Auslastung: 90%. Nach der Formel warten im Schnitt 8,1 Kunden.
Der Filialleiter beschliesst: "Wir stellen eine schnellere Kassiererin ein - 11 Kunden pro Minute. Auslastung sinkt auf 82%." Ergebnis: Warteschlange sinkt auf 3,7 Kunden - fast halbiert, obwohl die Kapazitaet nur um 10% stieg.
Sein Chef sagt: "Zu teuer! Wir kuerzen die Pausen - jetzt schafft sie 10,5 statt 10. Auslastung 86%." Ergebnis: Warteschlange steigt auf 5,2 Kunden. Mehr Stress, laengere Schlangen, kein Gewinn.
Ein Flughafen betreibt Kontrollspuren mit 95% Auslastung. Ein Reisebus mit 40 Passagieren trifft ein - eine kurze, vorhersehbare Spitze. Das System hat kaum Puffer. Die Folge: Schlangen explodieren, Fluege werden verpasst, Stress eskaliert.
Mit 90% Auslastung (eine Spur mehr, oder etwas weniger Durchsatz geplant) haette dieselbe Spitze das System kaum bemerkt. Die Mitarbeiter schienen 10% der Zeit unbeschaftigt - diese "Verschwendung" war die Versicherung gegen den Kollaps.
Ergaenzend zur M/M/1-Formel gilt Little's Law - universell, unabhaengig von der Verteilung:
Direkte Konsequenz: Wer die Wartezeit halbieren will, muss entweder die Ankunftsrate halbieren oder die Systemgroesse verdoppeln. Es gibt keinen Trick.
Warteschlangen-Theorie ist keine abstrakte Mathematik - sie beschreibt exakt das, was in jedem IT-System passiert.
Ein Connection Pool mit max. 100 Verbindungen, 90 aktiv belegt: Auslastung 90%. Nach M/M/1 warten im Schnitt 8 Anfragen auf eine freie Verbindung. Steigt die Last auf 95 aktive Verbindungen, warten bereits 18 Anfragen - Timeouts drohen.
Ein SQL Server laeuft dauerhaft bei 92% CPU. Das klingt effizient. Tatsaechlich wartet fast jede Query durchschnittlich 11 Query-Laengen in der Warteschlange. Eine kurze Spitze - ein grosser Report, ein Batch-Job - und die Antwortzeiten brechen ein.
Zielbereich fuer produktive SQL Server: Dauerlast max. 70-80% CPU. Der "Leerraum" ist kein Luxus - er ist die Reaktionsreserve.
Dasselbe Prinzip gilt fuer die Redo Queue beim AlwaysOn Secondary: Wenn der Log-Sender dauerhaft nahe seiner Kapazitaet arbeitet (Netzwerkband fast voll), akkumuliert sich bei jeder Lastspitze ein ueberproportional grosser Rueckstand. Kleine Lastspitzen werden zu grossen RPO-Verletzungen.
Webserver (HTTP Worker)
IIS/Apache mit 100 Worker-Threads, dauerhaft 95 belegt: jede neue Anfrage wartet im Schnitt auf 18 freie Threads. Unter Last: 404/503 Fehler.
Message Queues
Kafka, RabbitMQ, Service Broker: Bei dauerhafter Ueberlast wachsen die Queues unbegrenzt. Erst langsam, dann ploetzlich exponentiell.
Disk I/O
Speichersubsystem bei 90% Auslastung: Jede I/O-Spitze (z.B. Checkpoint) fuehrt zu stark erhoehten Latenzen. SSD hilft - aber das Prinzip gilt auch hier.
CPU: max. 70-80% Dauerlast | RAM: max. 80% belegt | Disk I/O: max. 70% | Connection Pool: max. 80% | Netzwerk: max. 70%
Die Warteschlangen-Theorie liefert die mathematisch praezise Antwort: Diese 10% sind nicht Verschwendung - sie sind die Versicherung gegen den Systemkollaps.
Hohe Auslastung sieht effizient aus. In einer deterministischen Fabrik (immer gleiche Aufgaben, immer gleiche Zeit) waere sie es auch. Aber die reale Welt ist stochastisch: Ankunftszeiten und Bearbeitungszeiten variieren. Und in stochastischen Systemen gilt:
Echte Effizienz misst sich am Durchsatz bei akzeptabler Wartezeit - nicht an der Auslastung. Ein System, das bei 75% Auslastung laeuft und kurze Wartezeiten liefert, ist effizienter als eines, das bei 98% betrieben wird und staendig im Stau steckt.
Falsche Frage
"Wie koennen wir die Auslastung maximieren?"
Richtige Frage
"Welche Auslastung erlaubt uns, Lastspitzen abzufangen und trotzdem kurze Wartezeiten zu garantieren?"
Die letzten 10 Prozentpunkte Auslastung sind die teuersten: Sie kosten exponentiell mehr Wartezeit, Stress und Fehleranfaelligkeit - und bringen kaum mehr Durchsatz. Ein System, das von 80% auf 90% getrieben wird, schafft nicht 12,5% mehr Output. Es schafft vielleicht 2% mehr Output - bei 2,5-facher Warteschlange.
Fazit: Die strategische Reserve
Warteschlangen-Theorie ist keine akademische Spielerei. Sie beschreibt praezise das Verhalten jedes Systems unter Last - ob Backer, Flughafen oder SQL Server.
Die 10% Leerlauf sind kein Versagen der Planung. Sie sind das Ergebnis kluger Planung. Sie sind der Schmierstoff, der verhindert, dass jede kleine Schwankung das System in die Knie zwingt.
Das naechste Mal, wenn jemand sagt "Die stehen ja nur rum!", ist die korrekte Antwort:
Weiterführend: Little's Law (1961) | Kendall's Notation | Erlang-C Formel fuer Call-Center | M/M/c Modelle fuer Multi-Server-Systeme