Langsame Website, untätiger Server. Wo die Zeit bleibt

Warum die Datenbank der übliche Verdächtige ist

Wenn eine Seite langsam wird, ist die Datenbank der Ort, an dem das Symptom zuerst sichtbar wird. Verbindungen stapeln sich, die Prozessliste füllt sich mit Queries im Zustand sending data, und das Slow Query Log beginnt zu wachsen. All das ist real, und nichts davon sagt, wohin die Zeit gegangen ist. Die Datenbank steht am Ende der meisten Anfragepfade. Eine Seite, die sie zweihundertmal statt zweimal aufruft, ein Worker, der eine Verbindung offen hält, während er auf ein Payment Gateway wartet, ein Cache, der bei jedem Hit umgangen wird: jedes davon erscheint als Datenbanklast, weil die Datenbank genau das tut, worum sie gebeten wird, öfter, als sie gebeten werden sollte.

Dasselbe gilt für den Server. Eine Maschine mit hoher Last ist eine Maschine, der Arbeit gegeben wird. Ob die Arbeit notwendig ist, ist eine Frage, die der Lastgraph nicht beantworten kann.

Verfolgen Sie eine Anfrage, nicht die ganze Website

Die Methode ist, eine langsame URL auszuwählen und ihr durch die Schichten zu folgen, mit einer Messung an jeder Grenze. Beginnen Sie von außen, von einer Maschine, die nicht im selben Netzwerk steht, und lassen Sie curl berichten, wohin die Zeit geht, bevor das erste Byte ankommt.

$ curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://www.example.com/slow-page

Wenn die Zeit bis zum ersten Byte den Großteil der Gesamtzeit ausmacht, liegt das Warten auf der Serverseite. Wenn die Gesamtzeit weit größer ist als die Zeit bis zum ersten Byte, ist die Seite schwer oder der Weg zwischen Besucher und Edge ist die Geschichte, und der Server war am Warten nicht beteiligt.

Auf der Maschine messen Sie die CPU, während die langsame Anfrage läuft, nicht eine untätige Stunde später.

$ mpstat -P ALL 1 5
$ vmstat 1 5

Ein Server, der während einer langsamen Anfrage überwiegend untätig ist, ohne iowait und ohne steal, hat sich selbst entlastet. Die Zeit wird mit Warten auf etwas verbracht, nicht mit Rechnen.

Dann die Anwendung. Die meisten Frameworks können pro Anfrage protokollieren, wie viele Queries abgesetzt wurden, wie viel Zeit insgesamt darin verging und wie viel Zeit in ausgehenden HTTP-Aufrufen. Schalten Sie das für die langsame URL ein. Zwei Zahlen beenden die Diskussion: wie viele Queries eine Seite absetzt, und wie viel der Wanduhrzeit vollständig außerhalb der Anwendung verbracht wurde.

Zum Schluss die Datenbank, mit eingeschaltetem Slow Query Log und einem Schwellenwert, der niedrig genug ist, um zu erfassen, was zählt.

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.2;
SET GLOBAL log_queries_not_using_indexes = ON;

Lesen Sie das Log für das Zeitfenster der langsamen Anfrage. Eine Handvoll Queries, die jeweils Sekunden dauern, ist ein Datenbankproblem. Tausende Queries, die jeweils eine Millisekunde dauern, sind ein Anwendungsproblem, für das die Datenbank beschuldigt wird.

Die Muster, die die Messung zeigt

Sind die Schichten getrennt, nimmt die Ursache meist eine von wenigen Formen an.

Ein Endpoint, der in einer Schleife aufgerufen wird. Ein Frontend, das bei jeder Zustandsänderung dieselbe Ressource neu lädt, oder eine Seite, die ein Query pro Zeile statt ein Query pro Seite absetzt. Die Datenbank beantwortet jeden Aufruf schnell. Die Anzahl ist das Problem.

Ein synchroner Aufruf an jemand anderen. Ein Zahlungsanbieter, ein ERP, eine Versand-API, ein Tag Manager, die im Anfragepfad hinter einem langen Timeout sitzen. Der Server ist die ganze Wartezeit über untätig, und die Seite ist so langsam wie der langsamste Dritte, von dem sie abhängt.

Ein Cache, der ausgehebelt wird. Header, die das Caching auf Seiten verbieten, die sich nicht ändern, oder kein Edge-Cache vor anonymem Traffic, der nie dynamisch war.

Pools nach Gefühl dimensioniert. Worker-, Verbindungs- und Buffer-Pools ebenso oft zu groß wie zu klein eingestellt. Ein Pool, der weit größer ist, als die Maschine gleichzeitig bedienen kann, macht aus einer Warteschlange ein Thrashing.

Echte Erschöpfung ist die letzte Form, und wenn sie auftritt, liegt sie meist stromabwärts von einer der ersten drei. Dass der Maschine etwas ausgeht, ist das Ende der Geschichte, nicht der Anfang.

Was ein größerer Server ändert

Mehr Kerne oder mehr Speicher verkürzen den Teil der Anfrage, der gerechnet hat. War dieser Teil ohnehin klein, wird die Seite nicht schneller. Das Warten zieht mit um. Die Schleife läuft weiter, der Dritte nimmt sich weiter seine Zeit, der Cache wird weiter umgangen. Das Upgrade verdeckt außerdem die Messung, die die Ursache gefunden hätte, denn der Graph, der rot war, ist jetzt orange, und das Ticket wird geschlossen.

Deshalb verfolgen wir, bevor wir ein Angebot machen. Eine gesunde Plattform bleibt langweilig, und die Arbeit besteht darin, die Schicht zu finden, der die Zeit gehört, auch wenn diese Schicht oberhalb von allem liegt, was wir betreiben, und die Messung zurückzugeben, die auf die Zeile zeigt.