Performance und Kapazität: messen, was wartet

Die Frage, die am Anfang steht

„Der Server läuft auf 90 Prozent CPU“ ist keine Störungsmeldung. Es ist eine Beobachtung, und sie kann bedeuten, dass eine Maschine gut ausgelastet ihre Arbeit tut. „Anfragen brauchen vier Sekunden statt zweihundert Millisekunden“ ist eine Störungsmeldung, auch wenn dabei alle Auslastungswerte niedrig sind.

Der Unterschied klingt akademisch und entscheidet in der Praxis darüber, ob eine Untersuchung zum Ziel führt. Wer bei der Auslastung anfängt, findet immer irgendeine Zahl, die hoch aussieht, und baut darauf eine Erklärung. Wer bei der Wirkung anfängt — wer wartet, worauf, wie lange —, hat ein Kriterium dafür, wann die Untersuchung beendet ist.

Auslastung und Sättigung — Auslastung ist der Anteil der Zeit, in dem eine Ressource beschäftigt war. Sättigung ist das Maß, in dem Arbeit warten musste, weil die Ressource beschäftigt war. Die erste Zahl kann bei 100 Prozent stehen, ohne dass irgendetwas wartet; die zweite kann bei niedriger Auslastung hoch sein.

Dieses Modul behandelt beides: die Messung, die eine Leistungsfrage beantwortet, und die Rechnung, die eine Kapazitätsentscheidung trägt. Die eine schaut zurück auf einen Zustand, die andere nach vorn auf eine Reserve.

Der Mittelwert versteckt genau die Fälle, um die es geht

Eine mittlere Antwortzeit von 200 Millisekunden klingt gut. Sie sagt nichts darüber, wie viele Anfragen deutlich langsamer waren — und genau die sind es, über die sich jemand beschwert. Ein einzelner Wert von sechs Sekunden verschwindet im Mittel von zehntausend schnellen Antworten praktisch spurlos.

Perzentile beantworten diese Frage. Das 95. Perzentil ist der Wert, unter dem 95 Prozent aller Messungen liegen; das 99. entsprechend. Man liest sie nicht als „Ausreißer“, sondern als Aussage über einen Anteil der Nutzung.

Drei Aussagen, die man nicht vermischen darf

Für jede Ressource — CPU, Arbeitsspeicher, Platte, Netz — lohnt es, drei getrennte Fragen zu stellen. Sie beantworten Verschiedenes, und die verbreiteten Übersichten zeigen fast nur die erste.

Auslastung

Wie viel Zeit war die Ressource beschäftigt? Hoch ist hier weder gut noch schlecht — es kommt darauf an, ob jemand darauf gewartet hat.

Sättigung

Wie viel Arbeit musste warten? Das ist die Zahl, die mit der erlebten Langsamkeit zusammenhängt.

Fehler

Wie viele Vorgänge sind gescheitert? Eine überlastete Ressource beginnt oft mit Wiederholungen und Zeitüberschreitungen, bevor die Latenz auffällt.

Der Nutzen dieser Trennung zeigt sich an zwei Fällen, die beide häufig sind. Ein Rechenlauf über Nacht bei 100 Prozent CPU ohne Wartezeit ist kein Problem, sondern eine gut genutzte Maschine — Auslastung hoch, Sättigung null. Ein Webdienst bei 40 Prozent CPU mit ständigen Zeitüberschreitungen ist ein Problem — Auslastung niedrig, aber irgendwo wartet etwas, und zwar nicht auf die CPU.

Sättigung wird ablesbar

Lange war Sättigung die schwer messbare der drei Größen: Man konnte sie aus Warteschlangenlängen und Zustandsverteilungen erschließen, aber nicht direkt ablesen. Der Kernel liefert sie inzwischen unter /proc/pressure/ — je eine Datei für cpu, memory und io.

Jede Datei enthält zwei Zeilen mit Anteilen über zehn, sechzig und dreihundert Sekunden. Ihre Bedeutung unterscheidet sich grundlegend:

some

Anteil der Zeit, in der laut Dokumentation mindestens eine Aufgabe auf diese Ressource gewartet hat. Ein Frühwarnsignal — hier beginnt die Verlangsamung.

full

Anteil der Zeit, in der alle nicht untätigen Aufgaben gleichzeitig gewartet haben. Die Dokumentation nennt diesen Zustand ausdrücklich Verschwendung von CPU-Zyklen; anhaltend gilt er als Thrashing.

Damit lässt sich die Frage „ist das noch gesund?“ zum ersten Mal ohne Umweg beantworten. Ein Host mit some bei zwanzig Prozent auf io hat ein Plattenproblem, unabhängig davon, was die Auslastungsanzeige sagt. Steht dort auch full nennenswert über null, verliert das System bereits Rechenzeit, ohne dafür Arbeit zu erledigen.

Ohne Vorher ist jede Zahl bedeutungslos

„Die Antwortzeit liegt bei 800 Millisekunden“ ist keine Aussage, solange niemand weiß, wo sie letzte Woche lag. Fast jede Leistungsuntersuchung ohne Vergleichswert endet damit, dass jemand eine Zahl für zu hoch hält, ohne begründen zu können, warum.

Eine brauchbare Vergleichsmessung braucht wenig, aber sie braucht es dauerhaft und automatisch — nachträglich lässt sie sich nicht herstellen:

• Antwortzeit als Perzentile, nicht als Mittelwert, gemessen an der Stelle, an der jemand wartet
• Durchsatz in Vorgängen je Zeiteinheit — sonst ist unklar, ob die Last gestiegen ist oder die Leistung gefallen
• Fehlerrate, getrennt nach fachlichen Fehlern und Zeitüberschreitungen
• Sättigung je Ressource aus /proc/pressure/
• Der übliche Tagesverlauf: Eine Messung um 14 Uhr ist mit einer um 3 Uhr nicht vergleichbar

Der letzte Punkt entwertet die meisten spontanen Vergleiche. Wer nach einer Änderung misst und mit einer Erinnerung vergleicht, misst vor allem den Unterschied zwischen zwei Tageszeiten.

Was die Plattenanzeige nicht sagt

Bei Plattenmessungen gibt es eine Zahl, die häufiger falsch gelesen wird als jede andere: die prozentuale Belegung des Geräts, in iostat -x die Spalte %util. Sie gibt laut Dokumentation den Anteil der Zeit an, in der Anfragen an das Gerät ausgestellt waren.

Für ein Gerät, das Anfragen nacheinander bearbeitet, bedeutet ein Wert nahe 100 Prozent tatsächlich Sättigung — so entstand die Faustregel. Für Geräte, die Anfragen parallel bearbeiten, sagt die Dokumentation ausdrücklich, dass diese Zahl ihre Leistungsgrenze nicht abbildet. Genannt werden RAID-Verbünde und moderne SSDs; ein NVMe-Laufwerk kann bei 100 Prozent stehen und dabei einen Bruchteil dessen leisten, was es könnte.

Aussagekräftig sind stattdessen zwei andere Spalten. r_await und w_await geben die mittlere Zeit an, die eine Lese- beziehungsweise Schreibanfrage bis zur Erledigung gebraucht hat — laut Dokumentation einschließlich der Wartezeit in der Warteschlange. Und aqu-sz gibt die mittlere Länge dieser Warteschlange an. Steigt die Wartezeit zusammen mit der Warteschlange, wartet Arbeit; bleibt beides niedrig, ist die Platte trotz hoher Belegungsanzeige nicht der Engpass.

Beim Netz gilt dieselbe Unterscheidung mit anderen Zahlen. Die übertragene Datenmenge je Sekunde ist eine Auslastungsangabe und sagt nichts darüber, ob etwas gewartet hat. Die Sättigungssignale sind Wiederholungen und Verwürfe: erneut gesendete Pakete, verworfene Pakete an der Schnittstelle, wachsende Warteschlangen an den Sockeln. ss -ti zeigt sie je Verbindung.

Warteschlangen wachsen nicht gleichmäßig

Der Grund, warum ein System bei steigender Last nicht allmählich, sondern plötzlich langsam wird, liegt nicht in der Software. Er steckt in der Mathematik von Warteschlangen: Die Wartezeit wächst nicht proportional zur Auslastung, sondern beschleunigt, je näher man der Grenze kommt.

In einem einfachen Warteschlangenmodell verhält sich die Wartezeit wie 1 geteilt durch (1 minus Auslastung). Bei 50 Prozent Auslastung ist sie doppelt so lang wie bei einem leeren System, bei 80 Prozent fünffach, bei 90 Prozent zehnfach. Der Sprung von 80 auf 90 Prozent Auslastung — zwölf Prozent mehr Last — verdoppelt die Wartezeit.

Daraus folgt eine unbequeme Betriebsregel. Eine Maschine dauerhaft auf 90 Prozent zu fahren, sieht nach guter Ausnutzung aus und ist tatsächlich ein Betrieb kurz vor dem Knick: Jede zusätzliche Last, jeder ausgefallene Nachbar, jede unerwartete Anfragenspitze führt nicht zu etwas mehr Wartezeit, sondern zu einem Vielfachen.

Kapazität ist Reserve, nicht Maximum

Eine Kapazitätsentscheidung beantwortet nicht die Frage „wie viel schafft die Maschine?“, sondern „wie viel Reserve brauchen wir, wie lange reicht sie, und wie lange dauert es, neue zu bekommen?“. Die letzte Größe wird am häufigsten vergessen und ist oft die längste.

Spitzenlast statt Mittel

Ausgelegt wird auf die Spitze, die man bedienen will — der Tagesmittelwert kommt in keinem Zwischenfall vor.

Ausfallreserve

Fällt ein Knoten von vieren aus, tragen drei die volle Last. Wer auf 80 Prozent auslegt, hat nach dem Ausfall 107 Prozent.

Wachstum

Der Zuwachs der letzten Monate, fortgeschrieben — nicht auf eine Zahl genau, aber als Größenordnung.

Beschaffungszeit

Die Reserve muss bis zur nächsten möglichen Erweiterung reichen. Bei eigener Hardware sind das Wochen bis Monate.

Die zweite Zeile ist die, an der die meisten Auslegungen scheitern. Sie ist auch die, die man vorher nachrechnen kann: Bei n Knoten und dem geplanten Ausfall eines einzelnen darf die Auslastung im Normalbetrieb höchstens (n-1)/n der tragbaren Last betragen — bei vier Knoten also 75 Prozent, bei zwei Knoten 50.

Eine Messung, die eine Entscheidung trägt

Zwischen „wir haben etwas geändert und es fühlt sich schneller an“ und einer belastbaren Aussage liegen ein paar Regeln, die alle denselben Zweck haben: die Zahl der möglichen Erklärungen auf eine zu reduzieren.

• Eine Variable je Messung. Zwei gleichzeitige Änderungen erzeugen ein Ergebnis, das keiner von beiden zugeordnet werden kann
• Gleiche Last vorher und nachher — sonst misst man den Unterschied zwischen zwei Uhrzeiten
• Lange genug messen, dass regelmäßige Ereignisse hineinfallen: Sicherungen, Zeitpläne, das Ablaufen von Zwischenspeichern
• Den Zustand der Zwischenspeicher notieren. Ein zweiter Lauf auf warmem Cache ist immer schneller
• Prüfen, ob das Messwerkzeug selbst die Grenze ist — ein Lastgenerator auf demselben Host misst am Ende sich selbst

Der Engpass wandert

Jedes System hat zu jedem Zeitpunkt genau einen Engpass — die Ressource, die als Erste knapp wird. Beseitigt man ihn, wird eine andere zum Engpass. Das ist kein Zeichen einer schlechten Analyse, sondern das erwartete Ergebnis.

Praktisch bedeutet das zweierlei. Erstens: Eine Verbesserung an einer Stelle, die nicht der Engpass ist, verändert das Gesamtverhalten überhaupt nicht — schnellere Platten in einem Host, der auf das Netz wartet, kosten Geld und ändern keine Zahl. Zweitens: Nach jeder wirksamen Maßnahme muss neu gemessen werden, denn die vorherige Diagnose gilt nicht mehr.

Daraus folgt auch, wann man aufhört. Nicht dann, wenn kein Engpass mehr da ist — es ist immer einer da —, sondern dann, wenn die erlebte Wirkung wieder im vereinbarten Rahmen liegt. Ohne diesen Rahmen hat eine Leistungsuntersuchung kein Ende.

Die häufigsten Selbsttäuschungen

Messung auf dem leeren System

Ein Host ohne Konkurrenzlast liefert Werte, die im Betrieb nie erreicht werden. Der Vergleich zweier solcher Messungen ist trotzdem aussagekräftig — der absolute Wert nicht.

Zu kurz gemessen

Dreißig Sekunden treffen keine Sicherung, keinen Zeitplan und keinen Zwischenspeicher, der abläuft. Genau diese Ereignisse erzeugen aber die Beschwerden.

Mittelwert über alles

Ein Mittelwert über verschiedene Anfragearten mischt eine schnelle Statusabfrage mit einer teuren Suche und beschreibt danach keine von beiden.

Der Client als Grenze

Ein Lastwerkzeug, das selbst am Anschlag läuft, meldet die Antwortzeiten seiner eigenen Warteschlange. Erkennbar daran, dass mehr Last keinen höheren Durchsatz mehr erzeugt.

Allen vier gemeinsam ist, dass sie plausible Zahlen liefern. Eine Messung wird nicht dadurch falsch, dass sie unsinnige Werte ausgibt — sie wird dadurch falsch, dass sie eine andere Frage beantwortet als die gestellte.

Die Reihenfolge beim Nachgehen

Der erste Schritt ist der, den man am liebsten überspringt, und der, der am meisten Zeit spart. Solange die Wirkung nicht benannt ist, gibt es kein Kriterium dafür, welche Beobachtung dazugehört — und dann findet man in jeder Übersicht etwas Auffälliges.