Überwachung, Sperrverhalten und Wartung

Überwachung, Sperrverhalten und Wartung

0:00 In den ersten beiden Modulen haben wir eingerichtet und optimiert. Jetzt kommt der Teil, der darüber entscheidet, ob das auch in einem halben Jahr noch stimmt. Wir sehen uns an, wie man herausfindet, welche Anweisungen ein System wirklich belasten — und das ist oft nicht die, an die man denkt. Wir richten eine Protokollierung ein, die auch nachts hinsieht. Wir lernen, Sperrvorfälle geordnet abzuarbeiten.

0:24 Und wir verstehen, warum PostgreSQL überhaupt ständig aufräumen muss und woran man erkennt, dass es damit in Rückstand gerät.

Überwachung und Wartung im Überblick

0:32 Beginnen wir mit einer Frage, deren Antwort erstaunlich vielen Bauchgefühlen widerspricht: Welche Abfrage belastet Ihr System eigentlich am stärksten? Die meisten Teams tippen auf die, über die sich Nutzer beschweren — und liegen damit oft daneben. In diesem Kapitel klären wir, warum das so ist, womit sich Wirkung tatsächlich messen lässt und welche vier Werkzeuge uns durch den Rest des Moduls begleiten werden.

0:54 Überwachung und Wartung klingen nach zwei getrennten Aufgaben, zielen aber auf dasselbe. Die eine fragt, was gerade passiert, die andere, was gerade liegen bleibt. Und beide interessieren sich nicht für die Laufzeit einer einzelnen Abfrage, sondern für ihre Wirkung auf das Ganze. Das ist ein Perspektivwechsel gegenüber dem letzten Modul: Dort haben wir eine Abfrage unter das Mikroskop gelegt.

1:18 Hier treten wir zurück und fragen, wo die Systemzeit insgesamt hingeht. Diese Rechnung ist der Kern des Moduls. Zehn Sekunden einmal am Tag sind zehn Sekunden. Hundert Millisekunden tausendmal pro Minute sind hundert Sekunden — pro Minute. Die langsame Abfrage fällt auf, die schnelle nicht, und trotzdem ist die schnelle das größere Problem.

1:38 Genau das ist der Grund, warum Optimierung nach Bauchgefühl so oft danebengeht: Auffälligkeit und Wirkung sind zwei verschiedene Dinge, und nur eines davon lässt sich messen. Diese vier Werkzeuge beantworten unterschiedliche Fragen, und es lohnt sich, den Unterschied zu kennen. Die ersten beiden suchen Ursachen: Was hat das System belastet, und was ist passiert, als niemand hinsah?

2:01 Die letzten beiden bewerten den laufenden Zustand: Wer wartet gerade, und hält die Wartung Schritt? Wenn Sie sich diese Einteilung merken, greifen Sie im Vorfall schneller zum richtigen Werkzeug — statt der Reihe nach alles anzusehen, was Sie kennen.

Teure Abfragen mit pg_stat_statements finden

2:15 Fangen wir mit der Erweiterung an, die ich für die wichtigste in der ganzen Performance-Arbeit halte. Ohne sie optimiert man das, was zufällig aufgefallen ist — mit ihr das, was tatsächlich Zeit verbraucht. Sie führt Buch über jede Anweisungsform und liefert damit eine Rangliste, die in fast jedem System anders aussieht als erwartet.

2:34 Wir richten sie ein, werten sie aus und sehen uns an, worauf es bei der Sortierung ankommt. Diese Erweiterung führt Buch. Für jede Anweisungsform merkt sie sich, wie oft sie gelaufen ist, wie viel Zeit sie insgesamt und im Schnitt gekostet hat und wie viele Zeilen dabei herausgekommen sind. Das ist ungefähr das, was eine Kostenstellenrechnung für ein Unternehmen leistet: Nicht die einzelne Rechnung ist interessant, sondern die Summe über ein Jahr.

3:00 Eine Besonderheit noch: Sie muss beim Serverstart geladen werden, ist also nichts, was Sie mal eben nebenbei einschalten. Zwei Schritte verdienen Aufmerksamkeit. Der zweite ist der, den man einplanen muss: Es braucht einen Neustart, also ein Wartungsfenster. Und Schritt vier ist der, der über die Qualität Ihrer Daten entscheidet — eine repräsentative Zeitspanne. Wer nach zehn Minuten auswertet, sieht zehn Minuten.

3:24 Was Sie wissen wollen, ist aber, was in einer typischen Woche passiert, mit Monatsabschluss, Nachtläufen und Lastspitzen. Und Schritt fünf ist die Regel, um die es im ganzen Kapitel geht: nach Gesamtzeit sortieren, nicht nach Mittelwert. Auf diese Abfrage kommt es an, und zwar auf die Sortierung. Was Sie hier bekommen, ist eine Rangliste nach tatsächlichem Verbrauch — und die sieht in fast jedem System anders aus, als das Team vermutet hätte.

3:51 Oft steht ganz oben eine völlig unauffällige, kurze Abfrage, die einfach sehr häufig läuft. Das Zurücksetzen am Ende ist ebenfalls nützlich: Vor einem Lasttest einmal die Zähler leeren, danach auswerten — dann messen Sie den Test und nicht die letzten drei Wochen. Der Lerneffekt dieser Aufgabe steckt im zweiten Teil: der Begründung.

4:11 Für den Spitzenreiter Ihrer Liste sollen Sie sagen können, ob er wegen seiner Laufzeit oder wegen seiner Häufigkeit dort steht. Das ist deshalb wichtig, weil die Maßnahme jeweils eine andere ist. Bei einer langsamen Abfrage optimieren Sie den Plan. Bei einer sehr häufigen fragen Sie zuerst, ob sie wirklich so oft laufen muss — manchmal ist die beste Optimierung ein Zwischenspeicher in der Anwendung.

4:34 Der erste Punkt ist der häufigste Anwendungsfehler und macht den ganzen Nutzen zunichte. Wer nach dem Mittelwert sortiert, bekommt oben die seltenen Sonderfälle und übersieht genau die Abfragen, die das System tragen. Der letzte Punkt ist eine Eigenheit, die man kennen muss: Die Sicht fasst Anweisungen mit gleicher Form zusammen und ersetzt konkrete Werte durch Platzhalter.

4:54 Sie sehen dort also nicht einen bestimmten Aufruf, sondern ein Muster — und das ist genau richtig, aber beim ersten Blick verwirrend.

Protokollierung verstehen

5:02 Bisher haben wir gemessen, was gerade läuft. Jetzt geht es um das, was passiert, wenn niemand hinsieht — nachts, am Wochenende, im Monatsabschluss. Genau dort liegen erfahrungsgemäß die Vorfälle, die man später rekonstruieren muss und für die dann die Belege fehlen. Wir richten deshalb eine Protokollierung ein, die auffällige Anweisungen von selbst festhält, ohne dass jemand daneben sitzen muss.

5:26 Überwachung und Protokollierung ergänzen sich, weil sie unterschiedliche Zeiträume abdecken. Die Statistiksichten zeigen den Augenblick oder eine Summe. Das Protokoll zeigt die einzelnen Ereignisse mit Zeitstempel. Für die Ursachensuche brauchen Sie beides: Die Statistik sagt Ihnen, dass etwas teuer ist, das Protokoll sagt Ihnen, wann genau es teuer wurde — und ob das mit einem Nachtlauf, einem Import oder einer bestimmten Uhrzeit zusammenfällt.

5:52 Die erste Zeile ist die wichtigste und zugleich die eleganteste Idee dieser Liste: eine Schwelle. Sie sagen dem Server, ab welcher Laufzeit ihn eine Anweisung interessieren soll — und bekommen dann genau die auffälligen, ohne im Rauschen zu ertrinken. Der letzte Eintrag hat eine Besonderheit, die man einplanen muss: Er verlangt einen Neustart, weil er die Art der Ausgabe ändert.

6:13 Die Schwelle selbst dagegen lässt sich im laufenden Betrieb setzen. Eine halbe Sekunde ist ein guter Startwert — hoch genug, um Ruhe zu haben, niedrig genug, um das Interessante zu sehen. Der Trick beim Einführen ist, konservativ anzufangen und dann zu senken, statt umgekehrt. Und beachten Sie, was im Protokolleintrag steht: die gemessene Dauer und der Anweisungstext.

6:35 Erst beides zusammen ist ein Beleg, mit dem Sie arbeiten können — die Dauer allein wäre nur eine Zahl, der Text allein nur eine Vermutung. Der erste Punkt ist der Anfängerfehler mit den größten Folgen: Eine Schwelle von null bedeutet, dass jede Anweisung protokolliert wird — auf einem belasteten System füllt das den Datenträger in erstaunlicher Geschwindigkeit.

6:57 Und der letzte Punkt ist eine Frage der Disziplin: Schärfere Protokollierung ist ein Werkzeug für die Analyse, kein Dauerzustand. Nehmen Sie sie zurück, wenn die Frage beantwortet ist — sonst tut es irgendwann der Datenträger für Sie.

Sperren und Blockaden im Betrieb behandeln

7:10 Im letzten Modul haben wir gelernt, Blockaden zu erkennen. Jetzt geht es darum, sie im laufenden Betrieb aufzulösen — geordnet, in Stufen und mit dem mildesten Mittel zuerst. Das ist ausdrücklich auch eine Frage der Nerven, denn solche Vorfälle passieren unter Zeitdruck und mit Publikum. Ein festes Vorgehen hilft dann mehr als jedes einzelne Kommando, und genau das nehmen wir uns in diesem Kapitel vor.

7:34 Die meisten Sperren dauern Millisekunden und fallen niemandem auf. Zum Vorfall wird es erst, wenn eine Sitzung hält, was eine andere braucht. Und das Verwirrende daran ist die Außenwirkung: Für die Anwendung sieht das aus wie ein überlasteter Server, während der Server in Wahrheit gar nichts tut. Wenn Sie also einmal eine träge Anwendung bei entspannter Auslastung sehen — das ist die Signatur. Dann suchen Sie nicht nach teuren Abfragen, sondern nach Wartenden.

8:01 Diese Reihenfolge ist bewusst so gewählt, und Schritt drei ist der, den man in der Hektik überspringt. Bevor Sie irgendetwas beenden, sehen Sie sich an, wer da eigentlich hängt und wie lange schon. Es macht einen Unterschied, ob Sie eine vergessene Konsole vor sich haben oder eine laufende Wartungsaktion, die gerade sinnvolle Arbeit tut.

8:19 Und die Schritte vier und fünf sind zwei Stufen: erst nur die Anweisung abbrechen, die Verbindung aber stehen lassen — und erst, wenn das nicht reicht, die Sitzung beenden. Zwei Funktionen, zwei sehr unterschiedliche Härtegrade. Die erste bittet den Server, die laufende Anweisung abzubrechen; die Verbindung bleibt bestehen, die Anwendung merkt im besten Fall wenig davon.

8:40 Die zweite beendet die Sitzung komplett und rollt ihre offene Transaktion zurück. Beide brauchen die Prozesskennung, und die sollten Sie unmittelbar vorher ermitteln — Kennungen werden wiederverwendet, und im Vorfall ist eine Verwechslung schnell passiert. Der dritte Punkt ist der, der über den Vorfall hinausweist. Wenn die Ursache im Anwendungscode sitzt — eine Transaktion, die nicht sauber geschlossen wird —, dann haben Sie mit dem Beenden nur Zeit gekauft.

9:07 Morgen steht dieselbe Sitzung wieder da. Deshalb gehört zu jedem gelösten Sperrvorfall die Frage, warum er entstanden ist. Und der erste Punkt ist der praktische Grund für Zurückhaltung: Die Anwendung bekommt einen Verbindungsabbruch, und nicht jede verkraftet den elegant. Der ungewöhnliche Teil dieser Aufgabe ist die Notiz — und die ist mir wichtig.

9:27 Ein Vorfall, den Sie auflösen und nicht festhalten, ist ein Vorfall, der sich wiederholen wird, ohne dass jemand das Muster erkennt. Ein paar Zeilen reichen: Wer wartete, wer blockierte, wie alt war die Transaktion, was haben Sie getan und warum. Beim dritten Mal sehen Sie dann in Ihren eigenen Notizen, dass es immer derselbe Auslöser ist.

9:48 Der erste Punkt ist der klassische Griff daneben unter Zeitdruck: Man beendet die Sitzung, die auffällig hängt — also das Opfer, nicht den Verursacher. Danach wartet einfach der Nächste. Und der dritte Punkt ist der, der eine gute Absicht in einen Ausfall verwandelt: Nicht jede lange laufende Sperre ist ein Problem. Ein Indexaufbau oder eine große Wartungsaktion hält ihre Sperre aus gutem Grund. Deshalb Schritt drei aus dem Ablauf — erst hinsehen, dann handeln.

MVCC in den Griff bekommen

10:16 Jetzt der Mechanismus, der PostgreSQLs gute Nebenläufigkeit erklärt — und zugleich, warum Tabellen wachsen, ohne dass mehr in ihnen steht. Wir haben das Prinzip im ersten Modul kurz gestreift; hier sehen wir uns die andere Seite davon an und machen den Effekt mit einem sehr kleinen Versuch sichtbar. Danach klären wir die Frage, die im Betrieb regelmäßig falsch beantwortet wird: welches Wartungsmittel wofür zuständig ist.

10:40 Wir hatten das Prinzip im ersten Modul kurz gestreift, hier ist die andere Seite davon. Weil eine Änderung eine neue Fassung schreibt statt die alte zu überschreiben, stören sich Lesende und Schreibende nicht gegenseitig. Wer liest, bekommt die Fassung, die zu seinem Zeitpunkt passt, und muss auf niemanden warten. Das ist ein großer Vorteil im Alltag.

11:00 Der Preis dafür sind die alten Fassungen, die zunächst liegen bleiben — und um die geht es in diesem Kapitel. Der erste Punkt ist der, der Kollegen regelmäßig irritiert: Die Tabelle wächst, obwohl die Zeilenzahl gleich bleibt. Fachlich sind es zehntausend Datensätze, physisch liegen dort dreißigtausend Fassungen. Und der dritte Punkt erklärt, warum das nicht nur eine Platzfrage ist: Alles, was gelesen wird, wird mitgelesen.

11:25 Ihre Durchläufe werden also langsamer, ohne dass jemand mehr Daten angelegt hätte. Das ist der Grund, warum das Aufräumen keine Kosmetik ist. Das mittlere Kommando sieht aus wie ein Scherz — es setzt jeden Wert auf sich selbst. Genau das ist der Punkt: Fachlich passiert nichts, physisch bekommt jede einzelne Zeile eine neue Fassung.

11:45 Wenn Sie danach die Kennzahlen ansehen, ist die Zahl toter Zeilen sprunghaft gestiegen und die Tabelle größer geworden. Ich finde diesen kleinen Versuch sehr lehrreich, weil er zeigt: Es geht nicht darum, wie viel Sie ändern, sondern wie oft. Diese vier Zeilen sind die Zuordnung, um die es im Rest des Moduls geht. Achten Sie auf den Unterschied zwischen der zweiten und der vierten.

12:07 Das normale Aufräumen gibt Platz zur Wiederverwendung frei — die Datei auf der Platte bleibt gleich groß, aber der Server kann den Raum darin wieder nutzen. Nur die vierte Variante schreibt die Tabelle neu und gibt Platz an das Betriebssystem zurück. Dafür sperrt sie die Tabelle vollständig, und das gehört ins Wartungsfenster, nicht in den Dienstagvormittag.

12:27 Der erste Punkt ist der teuerste Irrtum in dieser Liste, und er passiert regelmäßig aus gutem Willen: Jemand sieht eine aufgeblähte Tabelle, kennt das Kommando mit FULL und führt es im Betrieb aus. Danach steht die Anwendung. Der letzte Punkt ist die Erklärung für die Fälle, in denen gar nichts hilft: Solange eine alte Transaktion offen ist, darf der Server die alten Fassungen nicht entfernen — sie könnten ja noch gebraucht werden.

Autovacuum überwachen

12:51 Damit sind wir bei der eigentlichen Aufgabe im Betrieb — und die besteht nicht aus Handarbeit, sondern aus Hinsehen. In einem gesunden System erledigt die Automatik ihre Arbeit, und niemand muss eingreifen. Ihre Aufgabe ist zu prüfen, ob sie mitkommt. Wir sehen uns an, mit welchen wenigen Kennzahlen das geht, woran man einen Rückstand erkennt und ab wann sich ein Eingriff tatsächlich lohnt.

13:14 In einem gesunden System merken Sie von der Wartung nichts. Sie läuft, sie hält Schritt, und niemand muss etwas tun. Ihre Aufgabe ist deshalb nicht, von Hand aufzuräumen — das wäre ungefähr so, als würden Sie die Spülmaschine beaufsichtigen. Ihre Aufgabe ist zu prüfen, ob die Automatik mitkommt. Und einzugreifen nur dann, wenn sie es nachweislich nicht tut. Diese Haltung erspart eine Menge unnötiger Wartungsbefehle.

13:40 Diese Abfrage ist die, die ich morgens ansehen würde. Zwei Angaben zusammen ergeben das Bild: die Zahl toter Zeilen und der Zeitpunkt des letzten Laufs. Eine hohe Zahl allein ist noch kein Problem, wenn gerade eben aufgeräumt wurde. Eine mittlere Zahl mit einem Zeitstempel von vor drei Wochen dagegen schon. Und ein leerer Zeitstempel bedeutet nur, dass die Schwelle für diese Tabelle noch nicht erreicht war — das ist kein Alarm, sondern der Normalfall bei ruhigen Tabellen.

14:08 Alle vier Punkte haben eines gemeinsam: Sie sind Verläufe, keine Momentaufnahmen. Ein Wert für sich sagt wenig — erst die Richtung sagt etwas. Steigt der Anteil toter Zeilen über Tage, statt nach jedem Lauf zu fallen, arbeitet die Automatik langsamer als Ihre Anwendung schreibt. Und der letzte Punkt ist der Hinweis aus Modul eins: Wenn dauerhaft alle Arbeitsprozesse belegt sind, hilft ein niedrigerer Schwellwert nicht — es fehlt schlicht Kapazität.

14:35 Diese Aufgabe soll etwas hervorbringen, das Sie behalten: eine Abfrage, die Sie regelmäßig ausführen. Der zweite Teil ist wieder die Begründung — für eine auffällige Tabelle sollen Sie eine Maßnahme vorschlagen können. Und die Ausbaustufe schließt den Bogen zum ersten Modul: Nehmen Sie das Transaktionsalter mit in dieselbe Übersicht.

14:54 Beide Kennzahlen haben dieselbe Ursache, wenn sie schlecht aussehen, und dann sehen Sie das auf einen Blick. Der erste Punkt ist die falsche Reaktion auf ein richtiges Signal: Autovacuum ist in Rückstand, also stört es — und wird abgeschaltet. Damit ist der Rückstand nicht weg, sondern nur unsichtbar. Der dritte Punkt ist eine häufige Lücke im Blick: Die Automatik pflegt auch die Statistiken, nicht nur den Platz.

15:18 Wer nur auf tote Zeilen sieht, übersieht die Hälfte ihrer Arbeit — und wundert sich später über schlechte Ausführungspläne.

Wachsende Beobachtbarkeit nutzen

15:26 Zum Abschluss des Moduls die Zuordnung von Symptom zu Mittel. Die vier Wartungsbefehle sind schnell gelernt; die Schwierigkeit ist die Frage, wann welcher dran ist. Wir gehen das der Reihe nach durch, damit Sie im Ernstfall nicht raten müssen. Und danach werfen wir noch einen kurzen Blick darauf, wohin sich die Bordmittel von PostgreSQL gerade entwickeln — und was das für Ihre Überwachungsabfragen bedeutet.

15:50 Die Wartungsbefehle sind schnell gelernt; es sind vier. Die eigentliche Schwierigkeit ist die Zuordnung. Und die Richtung ist wichtig: erst das Problem benennen, dann das Mittel wählen. Wer es umgekehrt macht — also ein Kommando kennt und nach einer Gelegenheit sucht, es anzuwenden —, richtet mehr Aufwand als Nutzen an. Das gilt in der Datenbankpflege genauso wie überall sonst in der Technik.

16:13 Diese Zuordnung würde ich mir aufschreiben. Schlechte Pläne mit falschen Schätzungen bedeuten Statistik, nicht Platz. Wachsende tote Zeilen bedeuten Aufräumen. Ein aufgeblähter Index braucht einen Neuaufbau, kein Aufräumen der Tabelle. Und wenn Platz wirklich an das Betriebssystem zurück soll, dann eben die harte Variante — im Wartungsfenster.

16:33 Der letzte Schritt ist der, der am meisten Disziplin verlangt: Wenn nichts davon passt, ist Weitermessen die richtige Antwort und nicht ein Wartungsbefehl auf Verdacht. Hier steckt eine gute Nachricht und eine Warnung. Die gute Nachricht: PostgreSQL wird von Version zu Version auskunftsfreudiger. Wartezustände, Ein- und Ausgabeverhalten, Wartungsaktivität — vieles davon lässt sich heute belegen, wofür man vor einigen Jahren noch raten musste.

17:00 Die Warnung steht im letzten Punkt: Diese Sichten ändern sich dabei. Spalten wandern, Namen ändern sich, wie wir es bei den Checkpoint-Zählern gesehen haben. Ihre Überwachungsabfragen sind deshalb Code, der gepflegt werden will. Der erste Punkt fasst dieses Kapitel zusammen: Wartung nach Kalender statt nach Befund ist verschwendete Zeit und manchmal schädlich.

17:22 Der zweite ist ein sehr praktischer Hinweis — auch der Neuaufbau eines Index hat eine nebenläufige Variante, und die sollten Sie im Betrieb verwenden. Und der letzte Punkt ist der, der Überwachungsprojekte scheitern lässt: Daten ohne vereinbarte Schwellwerte erzeugen Bildschirme, die alle für hübsch halten und niemand liest.

Der Betrieb im Blick

17:40 Halten wir fest: Wirkung misst sich in Laufzeit mal Häufigkeit — und deshalb ist die auffälligste Abfrage selten die teuerste. Die Statistiksichten zeigen den Augenblick, das Protokoll belegt die Vergangenheit, und für die Ursachensuche brauchen Sie beides. Blockaden sind Wartezeit und kein Rechenaufwand, deshalb sind sie mit Optimierung nicht zu beheben. Und die Wartung erledigt sich meistens selbst — Ihre Aufgabe ist, das zu prüfen.

18:05 Im letzten Modul geht es um die andere Hälfte eines belastbaren Systems: um seine Absicherung.