Ändern Sie eine Sache, messen Sie erneut. So finden Sie den echten Engpass

Wenn eine Plattform langsam ist, ist die schnellste Bestellung die nach mehr von allem. Das wirkt oft ein wenig, kostet viel und lässt die eigentliche Ursache an Ort und Stelle, damit sie bei der nächsten Verkehrsspitze erneut zubeißt. Die Alternative ist weniger aufregend und weit wirksamer: Finden Sie die eine Ressource, auf die die Workload wartet, ändern Sie eine Sache daran und messen Sie erneut. Hier sind die Methode und die Werkzeuge.

Beginnen Sie mit einer Zahl, nicht mit einem Gefühl

«Die Website ist langsam» lässt sich nicht prüfen. «Der Checkout dauert in der Abendspitze vier Sekunden und nachts unter einer» schon. Bevor Sie irgendetwas anfassen, heften Sie das Symptom an eine Messung, die Sie wiederholen können: eine Seitenzeit von außen, eine Abfragedauer, die Laufzeit eines Batch-Jobs, eine Anfragerate, bei der die Fehler beginnen. Diese Zahl ist der Weg, auf dem Sie erfahren, ob irgendetwas, das Sie geändert haben, geholfen hat. Ohne sie fühlt sich jede Änderung wie Fortschritt an.

Schreiben Sie dann den Pfad auf, den der langsame Vorgang nimmt: Client, Netzwerk, Load Balancer, Webserver, Anwendung, Cache, Datenbank, Storage. Der Engpass liegt irgendwo auf diesem Pfad, und der Pfad sagt Ihnen, wo Sie suchen müssen.

Prüfen Sie jede Ressource auf Auslastung, Sättigung und Fehler

Eine einfache Disziplin, von Brendan Gregg als USE-Methode bekannt gemacht, hält die Suche ehrlich. Stellen Sie für jede Ressource auf dem Pfad, CPU, Arbeitsspeicher, Netzwerk, Storage, drei Fragen: Wie ausgelastet ist sie, staut sich Arbeit vor ihr, und meldet sie Fehler? Eine Ressource kann gering ausgelastet und trotzdem das Problem sein, wenn sich Anfragen vor ihr stauen, deshalb zählt die zweite Frage am meisten.

CPU.

mpstat -P ALL 1
vmstat 1
pidstat -u 1

Sehen Sie sich die Auslastung pro Kern an, nicht nur den Durchschnitt. Ein Kern unter Volllast, während die übrigen leerlaufen, deutet auf einen Single-Thread-Engpass, den mehr Kerne nicht beheben. In vmstat ist eine Run Queue (r), die dauerhaft größer ist als die Zahl der Kerne, Sättigung.

Arbeitsspeicher.

free -h
vmstat 1
cat /proc/pressure/memory

Speicherdruck zeigt sich als Reclaim-Aktivität und Stall-Zeit in der Pressure-Datei. Auf einer richtig gebauten virtuellen Maschine gibt es keinen Swap, in dem er sich verstecken könnte, sodass eine Workload, die wirklich mehr Speicher braucht, als sie hat, laut scheitert, und das ist das ehrliche Ergebnis: Die Lösung ist mehr Speicher oder eine schlankere Anwendung.

Storage.

iostat -x 1
pidstat -d 1

Die Spalten, die zählen, sind die durchschnittlichen Wartezeiten für Reads und Writes und die Länge der Warteschlange. %util führt auf Flash- und SAN-Volumes in die Irre, die viele Anfragen parallel bedienen und hohe Auslastung zeigen können, während sie noch reichlich Reserve haben. Steigende Wartezeiten bei wachsender Warteschlange sind das echte Signal.

Netzwerk.

sar -n DEV 1
sar -n EDEV 1
ss -s
cat /proc/net/bonding/bond0
ethtool -S <interface> | grep -iE 'drop|err|discard'

Vergleichen Sie den Verkehr pro Mitglied eines Bonds: Ein Mitglied ausgelastet, während das andere leerläuft, ist ein Hashing-Problem, kein Bandbreitenproblem. Drops und Fehler in den Interface-Zählern deuten unter das Betriebssystem, auf Kabel, Optiken oder den Switch.

Datenbank. Viele langsame Plattformen sind eine Datenbank, die von der Platte liest, was sie aus dem Speicher lesen sollte. Vergleichen Sie unter MySQL oder MariaDB die logischen Reads mit den Reads, die auf den Storage gehen mussten:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Wächst Innodb_buffer_pool_reads (Reads, die den Speicher verfehlt haben) im Verhältnis zu Innodb_buffer_pool_read_requests schnell, passt das Working Set nicht in den Buffer Pool. Das Slow Query Log, mit einer vernünftigen Schwelle, sagt Ihnen, welche Abfragen dafür bezahlen.

Ändern Sie eine Sache

Sobald eine Ressource heraussticht, bilden Sie eine Hypothese, die die ursprüngliche Zahl erklärt, und nehmen Sie eine einzige Änderung vor, die sie prüft: ein Buffer Pool, der auf das Working Set dimensioniert ist, eine Hash-Policy für den Bond, ein Cache vor der teuren Seite, eine Abfrage, die den Index bekommt, den sie braucht, eine VM, die so verkleinert wird, dass sie in einen CPU-Sockel passt. Eine Änderung nach der anderen, denn wenn Sie drei Dinge ändern und die Zahl sich verbessert, wissen Sie nicht, welches geholfen hat, und Sie haben vielleicht zwei behalten, die die Lage verschlechtert haben.

Messen Sie erneut, auf dieselbe Weise

Wiederholen Sie die Messung von vorn, unter denselben Bedingungen: dieselbe Tageszeit oder dieselbe synthetische Last, derselbe Test, dieselben Werkzeuge. Eine Änderung, die nicht geholfen hat, ist trotzdem ein Ergebnis, denn sie schließt etwas aus. Machen Sie sie rückgängig und gehen Sie zurück zu den Ressourcen.

Wiederholen Sie das, bis das ursprüngliche Symptom verschwunden ist oder der nächste Engpass etwas ist, das wirklich mit Geld gelöst werden sollte. Dann ist der Kauf von Hardware die richtige Antwort, und Sie wissen genau, welche Ressource Sie kaufen müssen.

Wie es in der Praxis aussieht

Einige der wirksamsten Einstellungen sind eine Zeile lang. Wir dimensionieren die Speicherpuffer von Datenbanken so, dass die heißen Daten im RAM leben und der Flash echte Arbeit leistet, und jeder Server mit Bond, den wir bauen, hasht auf Adressen und Ports, damit beide Leitungen Verkehr tragen. Beides sind feste Regeln auf jeder Plattform, die wir betreuen.

Wie wir es machen

Performance-Arbeit ist die Art, wie wir jede Plattform betreiben, die wir betreuen, kein separates Produkt. Wir messen auf jeder Ebene, vom I/O pro Volume auf den Arrays und den Zählern pro Port auf Bonds und Switches über die Slow Logs der Datenbanken bis zur Zeitmessung von außen nach innen durch das CDN, bevor wir eine Ursache benennen. Feste Regeln, die zuverlässig richtig sind, etwa Bonds, die beide Leitungen nutzen, Flash, der als Flash behandelt wird, und VMs, die in einen Sockel passen, werden auf jeden Build angewendet. Wenn eine Plattform wirklich mehr Kapazität braucht, sagen wir Ihnen welche Ressource, wie viel und warum.

Wenn Ihre Plattform langsam ist und der einzige Vorschlag bisher ein größerer Server war, lassen Sie uns zuerst messen.

Mit einem Ingenieur sprechen

Related

Verwandt: Performance- und Kapazitäts-Engineering · Bare-Metal-Server auf HPE und Dell · Enterprise-SAN-Storage auf HPE 3PAR, All-Flash