Serverkonfiguration und Umgebung

Serverkonfiguration und Umgebung

0:00 Wenn eine Datenbank langsam wird, ist der erste Reflex fast immer derselbe: Man sucht die schuldige Abfrage. Manchmal findet man sie auch. Aber erstaunlich oft liegt die Ursache eine Ebene tiefer — in einer Konfiguration, die nie zu dem Rechner gepasst hat, auf dem sie läuft. Genau da fangen wir an. In diesem Modul sehen wir uns an, wie PostgreSQL mit Arbeitsspeicher umgeht, wie es Schreibarbeit auf die Platte verteilt, warum es im Hintergrund ständig aufräumt und weshalb Verbindungen teurer sind, als die meisten erwarten.

0:30 Am Ende haben Sie das Fundament, auf dem alles Weitere überhaupt erst wirken kann.

Konfiguration und Tuning im Überblick

0:35 Beginnen wir mit der Landkarte. Bevor wir an einzelnen Schrauben drehen, lohnt sich der Blick darauf, warum es diese Schrauben überhaupt gibt — und warum die Werkseinstellung so vorsichtig ausfällt, wie sie ausfällt. In diesem Kapitel klären wir zwei Dinge: welche Bereiche in PostgreSQL überhaupt für Leistung zuständig sind, und in welcher Reihenfolge man sie anfasst.

0:56 Das klingt nach Theorie, spart aber später sehr viel Zeit — weil Sie danach wissen, wo Sie bei einem Symptom zuerst hinsehen. Stellen Sie sich einen Neuwagen vor, der ab Werk so eingestellt ist, dass er auf jeder Straße der Welt sicher fährt — auf der Schotterpiste genauso wie auf der Autobahn. Er fährt überall. Er fährt nirgends besonders gut. Genau so wird PostgreSQL ausgeliefert.

1:18 Die Voreinstellungen sind bewusst zurückhaltend, weil dieselbe Konfiguration auf dem Notebook einer Entwicklerin ebenso starten muss wie auf einem Server mit vierundsechzig Gigabyte Hauptspeicher. Tuning heißt deshalb nichts anderes, als diese Werte an die eigene Hardware, die eigene Arbeitslast und die eigene Parallelität anzupassen.

1:36 Nicht mehr, aber eben auch nicht weniger. Warum machen wir das zuerst? Weil die Konfiguration auf alle Abfragen gleichzeitig wirkt. Eine optimierte Abfrage macht eine Abfrage schneller. Ein passend eingestellter Speicher macht das ganze System vorhersehbar. Und es gibt einen zweiten Grund, der oft übersehen wird: Der Planner entscheidet anhand von Kostenwerten, die die Hardware beschreiben sollen.

2:01 Passen die nicht, wählt er systematisch die falsche Zugriffsart — und Sie können Indizes bauen, so viele Sie wollen, er wird sie ignorieren. Deshalb diese Reihenfolge. Erst die Grundlage, dann die Feinarbeit. Was hier wie fünf getrennte Probleme aussieht, ist in Wahrheit ein einziges Geflecht. Zu wenig Speicher heißt: Daten müssen von der Platte gelesen werden — und schon sieht das Speicherproblem aus wie ein I/O-Problem.

2:25 Zu enge Checkpoint-Grenzen heißt: Der Server staut Schreibarbeit auf und entlädt sie in Spitzen — und schon sieht das aus wie ein plötzlich langsamer Server. Deshalb ist die wichtigste Fähigkeit in diesem Modul nicht das Auswendiglernen von Parametern, sondern das Zurückverfolgen: Welches Symptom sehe ich, und welche dieser fünf Ecken erzeugt es wirklich?

2:46 Diese vier Fehler sehe ich am häufigsten, und der erste ist der teuerste. Es gibt im Netz sehr viele Konfigurationsempfehlungen, und die meisten sind für sich genommen nicht falsch — sie gelten nur für eine Arbeitslast, die Sie nicht haben. Der zweite Fehler ist methodisch: Wer fünf Parameter gleichzeitig ändert, weiß hinterher nicht, welcher gewirkt hat, und kann im Zweifel nichts zurücknehmen.

3:07 Und der letzte Punkt wird uns gleich noch beschäftigen: Bei Speicher pro Operation gilt eben nicht, dass mehr immer besser ist. Er wird mehrfach belegt, und dann kippt der Vorteil in einen Ausfall.

Wichtige Einstellungen inspizieren

3:19 Bevor wir irgendetwas ändern, machen wir Inventur. Das klingt banal und wird trotzdem regelmäßig übersprungen — meistens, weil man das Problem ja schon zu kennen glaubt. Ohne diesen Schritt lässt sich später aber nicht sagen, ob eine Änderung etwas gebracht hat, und ebenso wenig, wie der Zustand vorher war. In diesem Kapitel sehen wir uns an, welche Werte Sie erheben sollten und wie Sie sie in einem Rutsch bekommen.

3:43 Es gibt zwei Wege, an die aktiven Werte zu kommen. Der eine ist SHOW: eine Einstellung, ein Wert, schnell getippt. Der andere ist die Katalogsicht pg_settings, und die ist im Alltag der nützlichere. Sie liefert nämlich nicht nur den Wert, sondern auch die Einheit, die Quelle und — besonders wichtig — die Angabe, ob die Einstellung sich im laufenden Betrieb übernehmen lässt oder einen Neustart verlangt.

4:07 Diese eine Spalte erspart Ihnen später die Verwirrung darüber, warum eine Änderung scheinbar nicht wirkt. Der eigentliche Kniff steckt nicht in der Abfrage, sondern in der letzten Spalte. Der sogenannte context sagt Ihnen, in welche Kategorie eine Einstellung fällt: sofort wirksam, wirksam nach einem Neuladen, oder erst nach einem Neustart des Servers.

4:27 Wenn Sie sich diese Spalte gleich beim ersten Blick mitnehmen, planen Sie Ihre Änderungen anders — dann wissen Sie von Anfang an, was in der Mittagspause geht und was ins Wartungsfenster gehört. Und der zweite Punkt: Bauen Sie sich diese Abfrage einmal, speichern Sie sie, und benutzen Sie immer dieselbe. Nur dann sind zwei Messungen wirklich vergleichbar.

4:48 Der rote Faden hier ist: von außen nach innen. Zuerst die Umgebung — läuft das im Container, auf eigener Hardware, bei einem Anbieter? Das entscheidet mit, was Sie überhaupt ändern dürfen. Dann der Speicher, weil er die größte Hebelwirkung hat. Dann Verbindungen und Schreibverhalten, weil sie den Betrieb unter Last prägen.

5:07 Und zum Schluss die Kostenparameter des Planners — die sind besonders aufschlussreich, weil sie verraten, welche Speichertechnik der Server annimmt. Ganz am Ende sichern Sie den Zustand. Diese Datei ist Ihr Vorher-Bild, und ohne Vorher-Bild gibt es kein Nachher. Diese erste Aufgabe wirkt unspektakulär, und genau darin liegt ihr Wert. Sie sollen nicht optimieren, sondern lesen lernen.

5:30 Denn eine Zahl allein sagt nichts — erst zusammen mit ihrer Einheit und der Frage, woher sie stammt, wird sie zur Information. Nehmen Sie sich für die Ausbaustufe ruhig die Zeit, das Ergebnis wegzuschreiben. Sie werden am Ende dieses Moduls mehrfach dorthin zurückkehren wollen, und aus dem Gedächtnis rekonstruiert niemand einen Ausgangszustand.

5:51 Der erste Punkt kostet regelmäßig eine halbe Stunde Verwirrung: shared_buffers wird nicht in Bytes ausgegeben, sondern in Blöcken zu acht Kilobyte. Wer die Zahl für Bytes hält, hält seinen Server für lächerlich klein konfiguriert. Der dritte Punkt ist subtiler: Die Datei postgresql.conf ist nicht zwangsläufig die Wahrheit.

6:10 Wenn jemand ALTER SYSTEM benutzt hat, steht der wirksame Wert woanders — und wenn Sie in der falschen Datei suchen, ändern Sie etwas, das niemand liest. Deshalb im Zweifel immer den Server fragen, nicht die Datei.

Speichernutzung verstehen

6:24 Jetzt zum wichtigsten Bereich überhaupt. Wenn Sie aus diesem Modul nur eine Sache mitnehmen, dann bitte die Unterscheidung, um die es auf den nächsten Folien geht — nämlich die zwischen Speicher, den sich alle teilen, und Speicher, den jede Sitzung für sich belegt. An dieser einen Unterscheidung hängt ein erheblicher Teil aller Speicherprobleme, die ich in Produktivsystemen gesehen habe. Und sie ist in fünf Minuten verstanden.

6:48 PostgreSQL kennt zwei Sorten von Speicher, und die verhalten sich völlig unterschiedlich. Die eine ist wie die Gemeinschaftsküche in einer WG: Es gibt sie genau einmal, alle nutzen sie, und ihre Größe ändert sich nicht, wenn jemand einzieht. Die andere ist wie der Rucksack, den jeder Bewohner beim Losgehen packt: Jeder bekommt einen, und wenn plötzlich dreihundert Leute losgehen, brauchen Sie dreihundert Rucksäcke.

7:11 Nur die zweite Sorte wächst also mit der Parallelität. Diese Unterscheidung ist die Ursache für einen erheblichen Teil aller Speicherausfälle, die ich gesehen habe. Drei dieser vier belegen tatsächlich Speicher — einer nicht. effective_cache_size ist der Sonderfall, und den verstehen viele falsch. Dieser Wert reserviert nichts.

7:31 Er ist eine Ansage an den Planner: So viel Speicher steht dir vermutlich als Cache zur Verfügung, rechne damit. Wer ihn klein lässt, weil er Angst vor Speicherverbrauch hat, verschenkt nichts an Speicher — sondern bekommt schlechtere Pläne. Merken Sie sich die Zeile also als das, was sie ist: eine Planungsangabe, kein Verbrauch.

7:52 Hier ist die Rechnung, die viele überrascht. work_mem gilt nicht pro Abfrage. Es gilt pro Operation. Eine Abfrage, die zweimal sortiert und einmal einen Hash aufbaut, kann den Wert also dreimal belegen — und wenn die Abfrage parallel läuft, gilt das auch noch je Arbeitsprozess. Multiplizieren Sie das mit der Zahl gleichzeitig aktiver Sitzungen, und Sie landen sehr schnell bei einem Vielfachen dessen, was Sie eingestellt zu haben glaubten.

8:18 Eine Einstellung, die im Test mit zehn Nutzern glänzt, kann im Produktivbetrieb mit dreihundert den Server in den Speichermangel treiben. Deshalb wird work_mem nie ohne Blick auf die Parallelität gesetzt. Diese Aufgabe verlangt keine Messung, sondern eine Überschlagsrechnung — und die sollten Sie einmal im Leben von Hand gemacht haben.

8:38 Nehmen Sie Ihren aktuellen Wert, nehmen Sie eine realistische Zahl von Operationen je Abfrage, nehmen Sie Ihre Verbindungsgrenze, und multiplizieren Sie. Die Zahl, die dabei herauskommt, erschreckt in der Regel. Genau das ist die Absicht: Sie soll Ihnen ein Gefühl dafür geben, wie schnell dieser Parameter gefährlich wird.

8:56 Und die Ausbaustufe zeigt gleich den Ausweg — man kann ihn nämlich auch nur für eine einzelne Sitzung anheben. Der erste Punkt ist der klassische Fall: Ein nächtlicher Auswertungslauf braucht mehr Speicher, also wird der Wert global angehoben — und tagsüber, wenn hunderte Sitzungen aktiv sind, rächt sich das. Der zweite Punkt betrifft shared_buffers.

9:16 Es klingt logisch, der Datenbank möglichst viel Speicher zu geben, aber das Betriebssystem hält seinen eigenen Cache, und den brauchen Sie auch. Wer alles an sich zieht, hat am Ende zwei halbleere Zwischenspeicher statt eines gut gefüllten.

Die Serverkonfiguration verwalten

9:31 Wir wissen jetzt, welche Werte wichtig sind. Bleibt die Frage, wie man sie ändert, ohne den Überblick zu verlieren — und ohne den Betrieb zu stören. In diesem Kapitel geht es deshalb weniger um einzelne Parameter als um ein Vorgehen: wie man eine Änderung setzt, wie man sie wirksam macht, und woran man erkennt, dass sie tatsächlich angekommen ist.

9:51 Das ist unspektakulär und im Alltag genau das, was den Unterschied macht. Die klassische Art, PostgreSQL zu konfigurieren, ist eine Textdatei. Es gibt aber einen Weg über SQL, und der ist im Alltag der bessere: ALTER SYSTEM. Der Server schreibt die Änderung dann selbst in eine eigene Datei, und Sie müssen nicht zwischen Datenbankwerkzeug, Containerkonsole und Editor hin- und herspringen.

10:14 Wichtig ist der zweite Teil: Manche Werte greifen nach einem einfachen Neuladen, andere erst nach einem Neustart. Diese Trennung ist keine Schikane — sie hängt daran, ob eine Einstellung die gemeinsame Speicherzuteilung berührt, die beim Start festgelegt wird. Sie sehen hier zweimal denselben Ablauf mit unterschiedlichem Ausgang. Beim ersten Parameter steht nach dem Neuladen der neue Wert da — fertig.

10:38 Beim zweiten meldet der Server brav Erfolg, und trotzdem zeigt die Nachfrage den alten Wert. Das ist kein Fehler, sondern genau die Unterscheidung von eben. Und daraus folgt die wichtigste Gewohnheit dieses Kapitels: Sie prüfen nach. Immer. Eine Änderung gilt erst dann als erfolgt, wenn der Server sie Ihnen bestätigt hat — nicht, wenn das Kommando ohne Fehlermeldung durchgelaufen ist.

11:02 Diese fünf Schritte sind im Kern wissenschaftliches Arbeiten in klein: eine Hypothese, eine Änderung, eine Messung. Der entscheidende Schritt ist der zweite — genau ein Parameter. Ich weiß, dass das mühsam wirkt, wenn man drei Verdächtige hat. Aber wer alle drei gleichzeitig ändert und danach eine Verbesserung sieht, hat nichts gelernt; er hat nur Glück gehabt.

11:23 Und Schritt vier ist die eingebaute Diagnose: Steht der alte Wert noch da, wissen Sie sofort, dass Sie ein Wartungsfenster brauchen — statt es beim nächsten Neustart zufällig zu bemerken. Der erste Punkt ist der häufigste Zeitfresser überhaupt: Jemand ändert die Hauptdatei von Hand, aber ein früherer ALTER SYSTEM überstimmt den Wert.

11:42 Das Ergebnis ist eine Änderung, die nachweislich in einer Datei steht und trotzdem keine Wirkung hat — eine hervorragende Grundlage für eine halbe Stunde Zweifel an der eigenen Zurechnungsfähigkeit. Und der letzte Punkt ist eine schlichte Freundlichkeit sich selbst gegenüber: Merken Sie sich, dass es ein RESET gibt. Ein Versuch, den man nicht sauber zurücknehmen kann, ist kein Versuch.

Wie der Planner Plattenzugriffe bewertet

12:04 Kommen wir zu einem Bereich, der besonders viele Überraschungen bereithält: den Annahmen, die PostgreSQL über Ihre Festplatten trifft. Diese Annahmen stammen zum Teil aus einer Zeit, in der sich in Festplatten noch etwas bewegte — und sie wirken bis heute darauf, ob Ihr Server einen Index benutzt oder lieber die ganze Tabelle liest.

12:23 Wenn Sie sich je gefragt haben, warum ein tadelloser Index einfach ignoriert wird: Die Antwort steht meistens in diesem Kapitel. Der Planner probiert nicht aus. Er rechnet. Für jede mögliche Strategie schätzt er einen Aufwand und nimmt dann die günstigste. Zwei Werte spielen dabei eine Hauptrolle: Was kostet es, eine Seite der Reihe nach zu lesen, und was kostet es, irgendwo mitten hineinzuspringen?

12:46 Wichtig zu verstehen: Diese Zahlen beschleunigen gar nichts. Sie sind keine Stellschraube für Geschwindigkeit, sondern eine Beschreibung Ihrer Hardware. Wenn die Beschreibung falsch ist, trifft der Planner vernünftige Entscheidungen auf einer falschen Grundlage. Diese Werte tragen ein Stück Computergeschichte in sich. Auf einer klassischen Festplatte musste sich ein Schreib-Lese-Kopf physisch bewegen — und deshalb war ein Sprung an eine beliebige Stelle um ein Vielfaches teurer als das Lesen der Reihe nach.

13:15 Die Voreinstellung bildet das getreu ab. Auf einer SSD gibt es diesen Kopf nicht mehr, der Unterschied schrumpft dramatisch, und plötzlich ist die alte Annahme nicht mehr konservativ, sondern schlicht falsch. Praktisch bedeutet das: Der Server meidet Indexzugriffe, obwohl sie auf Ihrer Hardware längst die bessere Wahl wären.

13:34 Zwei Dinge zu diesem Beispiel. Erstens: Der Wert, den Sie hier sehen, ist eine verbreitete Größenordnung für SSD-Systeme — aber er ist kein Rezept. Was für Ihre Speicherklasse passt, sagt Ihnen nur eine Messung. Zweitens, und das ist die gute Nachricht: Diese Einstellung berührt keine Speicherzuteilung, greift also nach einem einfachen Neuladen.

13:55 Sie können sie im laufenden Betrieb setzen, Ausführungspläne vergleichen und im Zweifel zurückgehen. Genau so sollte man sich diesem Parameter auch nähern: vorsichtig, mit Vorher- und Nachher-Bild. Der erste und der zweite Punkt hängen zusammen. Wer diesen Wert senkt und danach nur auf die Uhr sieht, misst Zufall. Sie müssen die Pläne vergleichen, denn genau dort entscheidet sich, ob die Änderung etwas bewirkt hat.

14:20 Und der letzte Punkt ist ein Hinweis auf das, was gerade passiert: Mit dem asynchronen Ein- und Ausgabeweg in Version 18 verschiebt sich das Bild noch einmal. Was heute eine gute Zahl ist, kann nach einem Versionswechsel neu zu bewerten sein.

Autovacuum

14:34 Jetzt zu einem Mechanismus, den PostgreSQL braucht, weil es Daten anders ändert als die meisten erwarten. Er läuft im Hintergrund, er fällt im Normalfall niemandem auf — und er ist zugleich der häufigste stille Verursacher von Problemen, die sich erst Wochen später als Leistungsverlust bemerkbar machen. Wir sehen uns an, warum es dieses Aufräumen überhaupt geben muss, welche Stellschrauben es hat und wie man es für einzelne Tabellen schärfer stellt.

14:59 Wenn Sie in PostgreSQL eine Zeile ändern, wird sie nicht überschrieben. Der Server schreibt eine neue Fassung und lässt die alte zunächst liegen, weil laufende Transaktionen sie vielleicht noch sehen dürfen. Das ist wie in einem Archiv, in dem korrigierte Blätter nicht sofort weggeworfen, sondern erst einmal danebengelegt werden.

15:18 Das funktioniert hervorragend — solange jemand regelmäßig aufräumt. Genau das tut Autovacuum: Es entfernt Fassungen, die niemand mehr sehen kann, und hält Tabellen und Indizes damit kompakt. Der Schaden entsteht schleichend, und das macht ihn tückisch. Tote Zeilen belegen Platz und werden bei jedem Durchlauf mitgelesen — Ihre Tabelle wird also langsamer, ohne dass fachlich mehr in ihr steht.

15:41 Gleichzeitig veralten die Statistiken, und der Planner beginnt, schlechtere Pläne zu wählen. Der vierte Punkt ist der wichtigste und wird uns gleich als eigenes Kapitel beschäftigen: Autovacuum räumt nicht nur auf. Es schiebt zugleich einen internen Zähler vor und verhindert damit ein Problem, das weit unangenehmer ist als ein bisschen Ballast.

16:01 Die ersten beiden Zeilen entscheiden gemeinsam, wann überhaupt losgelegt wird — ein prozentualer Anteil plus eine Mindestzahl, damit winzige Tabellen nicht ständig bearbeitet werden. Die dritte reguliert, wie stark sich das Aufräumen in den laufenden Betrieb drängt. Und die vierte ist die, an die zuletzt gedacht wird und die am häufigsten das eigentliche Problem ist: Wenn Sie viele große Tabellen haben, hilft ein niedrigerer Schwellwert gar nichts, solange schlicht keine Arbeitskraft frei ist.

16:27 Bei einem Rückstand also zuerst dort nachsehen. Der entscheidende Gedanke hier ist nicht die Syntax, sondern die Ebene. Sie könnten den Schwellwert für den ganzen Server senken — dann räumen Sie aber auch bei tausend Tabellen häufiger auf, die das gar nicht nötig haben. Viel besser ist die tabellenbezogene Einstellung: eine Tabelle, die sich ständig ändert, bekommt ihre eigene, schärfere Regel.

16:49 Und beachten Sie, warum der Anteil bei großen Tabellen so tückisch ist: Zwanzig Prozent von zehn Millionen Zeilen sind zwei Millionen tote Zeilen, die sich erst einmal ansammeln dürfen. Hier geht es um eine Entscheidung, die Sie im Betrieb immer wieder treffen werden: global oder lokal? Die Faustregel lautet, so global wie nötig und so lokal wie möglich — denn eine globale Änderung wirkt auf alles, auch auf das, was Sie gar nicht im Blick hatten.

17:14 Der Nachweis ist dabei genauso wichtig wie die Einstellung selbst. Erst wenn die Statistiksicht zeigt, dass tatsächlich ein Lauf stattgefunden hat und die toten Zeilen zurückgegangen sind, wissen Sie, dass Ihre Einstellung mehr ist als eine gute Absicht. Der erste Punkt ist der gefährlichste Ratschlag, den man im Netz findet: Autovacuum abschalten, weil es gerade stört.

17:35 Das verschafft eine ruhige Stunde und schafft ein Problem für nächsten Monat. Der dritte Punkt ist der, den man selbst mit den schärfsten Einstellungen nicht umgeht: Eine seit Stunden offene Transaktion blockiert das Aufräumen komplett, weil ihre Sicht auf die alten Zeilenfassungen respektiert werden muss. Wenn nichts hilft, suchen Sie also nicht weiter an den Schwellwerten, sondern nach der offenen Sitzung.

Transaction-ID-Wraparound vermeiden

17:57 Jetzt kommt das Thema, das ich eben angekündigt habe — der Grund, warum das Aufräumen im Hintergrund keine Kosmetik ist, sondern eine Sicherheitsfunktion. Es geht um einen Zähler, der irgendwann überläuft, und um die Vorsichtsmaßnahme, mit der PostgreSQL sich davor schützt. Diese Vorsichtsmaßnahme ist unangenehm, denn sie besteht darin, keine Schreibzugriffe mehr anzunehmen. Die gute Nachricht vorweg: Vorsorge kostet hier eine einzige Abfrage.

18:25 Jede Transaktion bekommt eine Nummer, und diese Nummer hat zweiunddreißig Bit — gut vier Milliarden mögliche Werte. Das klingt nach unendlich viel. Aber es ist ein Zähler, der irgendwann herumläuft, so wie ein Kilometerzähler, der wieder bei null anfängt. Wenn alte Nummern nicht rechtzeitig als endgültig eingefroren markiert werden, kann der Server irgendwann nicht mehr sicher entscheiden, welche Zeile für wen sichtbar ist.

18:49 Und weil das ein Datenintegritätsproblem wäre, tut er das einzig Vernünftige: Er verweigert Schreibzugriffe, bevor es dazu kommt. Vier Milliarden Transaktionen sind auf einem stark belasteten System keine Frage von Jahren, sondern von Tagen. Das Unangenehme daran ist der Verlauf: Es passiert nichts, es passiert nichts, es passiert nichts — und dann steht die Anwendung.

19:12 Der Server warnt zwar vorher im Protokoll, aber diese Warnung sieht nur, wer hinschaut. Die gute Nachricht ist das Verhältnis von Aufwand und Nutzen. Der Notfall kostet ein Wartungsfenster und eine unangenehme Nacht. Die Vorsorge kostet eine Abfrage, die Sie einmal einrichten. Diese beiden Abfragen liefern Ihnen dieselbe Kennzahl auf zwei Ebenen: einmal je Datenbank für den schnellen Gesamtblick, einmal je Tabelle für die Ursachensuche.

19:37 Und der Blick auf die Tabellenebene lohnt sich, denn dort zeigt sich das Muster. Meistens ist es nicht die ganze Datenbank, die zurückfällt, sondern eine einzelne auffällige Tabelle — und dann wissen Sie auch schon, wo Sie suchen müssen. Wichtig ist weniger der absolute Wert als sein Verlauf: Steigt er dauerhaft, arbeitet das Aufräumen langsamer, als Ihre Anwendung schreibt.

19:59 Der eigentliche Lerneffekt dieser Aufgabe steckt im zweiten Teil: dem Schwellwert. Eine Kennzahl ohne vereinbarte Grenze ist nämlich nur eine Zahl, die irgendwo in einem Werkzeug steht und die niemand bemerkt. Erst wenn festgelegt ist, ab welchem Wert jemand tätig wird — und wer dieser Jemand ist —, wird daraus eine Überwachung. Nehmen Sie sich dafür bewusst ein paar Minuten.

20:20 Diese Frage beantwortet man besser in Ruhe als im Vorfall. Der zweite Punkt ist der, den man sich selbst zufügt: eine Konsole, in der man vor drei Stunden eine Transaktion geöffnet und dann Feierabend gemacht hat. Diese eine Sitzung kann sämtliches Einfrieren im ganzen Cluster blockieren. Und der dritte Punkt ist eine Warnung vor zu viel Eifer: Die Freeze-Schwellwerte sind sorgfältig gewählt.

20:43 Wer sie verstellt, weil eine Kennzahl unschön aussieht, verschiebt in der Regel nur das Problem — die Ursache liegt fast immer woanders.

Checkpoints verstehen

20:52 Wir wechseln zum Schreibverhalten. Wenn Ihr System alle paar Minuten kurz stockt und Sie dafür bisher keine Erklärung hatten, dann finden Sie sie mit hoher Wahrscheinlichkeit in diesem Kapitel. Es geht darum, wann PostgreSQL gesammelte Änderungen auf die Platte schreibt, warum das in Schüben passiert und wie man aus diesen Schüben einen gleichmäßigen Strom macht.

21:11 Vier Parameter reichen dafür — man muss nur wissen, wie sie zusammenwirken. Geänderte Daten wandern nicht sofort auf die Platte. PostgreSQL sammelt sie im Speicher und schreibt sie gebündelt weg — beim Checkpoint. Das ist ungefähr so wie mit dem Abwasch: Sie können jedes Glas einzeln spülen oder einmal am Abend alles zusammen.

21:31 Das Bündeln ist effizienter, hat aber den bekannten Nachteil, dass der Abend dann sehr voll wird. Zugleich setzt der Checkpoint eine Marke: Ab hier muss nach einem Absturz nichts mehr nachgespielt werden. Er ist also beides — Aufräumaktion und Sicherungspunkt. Jeder Checkpoint erzeugt eine Schreibspitze, und in dieser Spitze warten alle anderen Zugriffe.

21:52 Wenn die Grenzen zu eng gesetzt sind, passiert das nicht nur nach Zeitplan, sondern zusätzlich immer dann, wenn viel geschrieben wird — also ausgerechnet unter Last. Das ist die Rückkopplung, die Systeme in die Knie zwingt. Die Gegenmaßnahme klingt paradox: Man erlaubt dem Server, mehr Schreibprotokoll anzusammeln. Damit verteilt sich dieselbe Schreibmenge gleichmäßiger über die Zeit, statt sich in Stößen zu entladen.

22:17 Diese vier arbeiten paarweise. Die ersten beiden sind zwei Auslöser für dieselbe Sache: Der eine sagt „nach so viel Zeit", der andere „nach so viel Schreibprotokoll" — und es gewinnt immer der, der zuerst greift. Genau deshalb bringt es nichts, nur an einem zu drehen. Der letzte Wert ist der eleganteste im Bunde: Er bestimmt, über welchen Anteil des Intervalls die Schreibarbeit verteilt wird.

22:39 Er macht aus einer Spitze eine Rampe, ohne dass Sie irgendetwas anderes ändern müssten. Die Kennzahl, auf die es hier ankommt, ist ein Verhältnis. Es gibt Checkpoints, die nach Zeitplan kommen, und solche, die angefordert werden, weil eine Grenze erreicht ist. Wenn die zweite Sorte überwiegt, sagt Ihnen der Server damit sehr deutlich, dass seine Grenzen für diese Arbeitslast zu eng gesetzt sind.

23:03 Das Kommando am Ende erzwingt einen Checkpoint von Hand — nützlich, um in der Übung die Zähler wandern zu sehen, im Produktivbetrieb aber mit Bedacht einzusetzen. Der erste Punkt ist eine Falle der Versionsgeschichte: Die Zähler sind mit Version 17 in eine eigene Sicht umgezogen. Die alte gibt es noch, sie enthält diese Werte nur nicht mehr — wer das nicht weiß, sucht lange.

23:24 Der zweite Punkt ist der klassische Halbschritt: Das Zeitintervall zu verlängern bringt nichts, solange die Protokollgrenze weiter dazwischenfunkt. Und der dritte Punkt ist die Kehrseite, an die man denken sollte: Größere Abstände bedeuten auch, dass nach einem Absturz mehr nachgespielt werden muss.

Write-Ahead-Logging steuern

23:41 Checkpoints und Schreibprotokoll gehören untrennbar zusammen; das eine setzt die Marken, das andere führt Buch. Sehen wir uns deshalb die andere Hälfte dieses Paares an. In diesem Kapitel geht es darum, was das Schreibprotokoll eigentlich leistet, warum es die Grundlage für Dauerhaftigkeit und Wiederherstellung ist — und warum es auf einem belasteten System oft mehr Schreiblast erzeugt als die Tabellen selbst.

24:04 Das Prinzip ist einfach und uralt: Bevor der Server eine Datenseite anfasst, schreibt er auf, was er vorhat. Ungefähr wie ein Kassenbuch, das geführt wird, bevor das Geld die Schublade wechselt. Passiert unterwegs etwas, lässt sich alles rekonstruieren. Das ist die Grundlage dafür, dass eine bestätigte Transaktion auch wirklich bestätigt bleibt.

24:25 Der Preis dafür ist ständige Schreibaktivität — und zwar auch dann, wenn die eigentlichen Datenseiten noch längst im Speicher liegen. Der interessanteste Eintrag ist der erste. Er bestimmt, wie ausführlich mitgeschrieben wird, und das hat Folgen weit über die Performance hinaus: Erst ab einer bestimmten Stufe sind Replikation und die Wiederherstellung auf einen bestimmten Zeitpunkt überhaupt möglich.

24:48 Das heißt umgekehrt, dass dieser Wert keine reine Leistungsfrage ist, sondern eine Frage Ihrer Betriebsstrategie. Die beiden Größenangaben kennen Sie schon aus dem Checkpoint-Kapitel — hier sehen Sie sie aus der anderen Richtung. Der Ablauf ist bewusst schlicht: messen, Last erzeugen, wieder messen. Der Effekt, den Sie dabei sehen sollen, ist der aus der Definitionsfolie — die Zähler steigen auch dann, wenn die betroffenen Datenseiten die Platte gar nicht sehen.

25:14 Daraus folgt eine praktische Einsicht für die Planung: Schreiblast auf einem PostgreSQL-System ist selten nur Tabellenlast. Wer die Speicherplanung nur an der Größe seiner Tabellen ausrichtet, unterschätzt das Schreibaufkommen regelmäßig. Der erste Punkt ist der teuerste: Eine höhere Protokollstufe schreibt dauerhaft mehr mit — wenn Sie sie nicht für Replikation oder Wiederherstellung brauchen, zahlen Sie ohne Gegenwert.

25:38 Der zweite Punkt sorgt regelmäßig für Verwirrung in Gesprächen: Das Schreibprotokoll und das Serverprotokoll sind zwei völlig verschiedene Dinge — das eine ist ein binärer Datenstrom, das andere sind Textzeilen für Menschen. Und der letzte Punkt ist ein Hinweis für die Systemplanung: Diese beiden Schreibströme auf denselben knappen Datenträger zu legen, ist sparsam gedacht und teuer bezahlt.

Datenbankverbindungen verwalten

25:59 Ein letzter großer Konfigurationsbereich, und einer, bei dem PostgreSQL sich anders verhält als viele andere Datenbanksysteme. Es geht um Verbindungen — darum, was eine Verbindung technisch wirklich ist, warum sie mehr kostet, als man annimmt, und weshalb im PostgreSQL-Umfeld praktisch überall ein Verbindungspool im Spiel ist.

26:17 Wenn Sie aus einer anderen Datenbankwelt kommen, ist das erfahrungsgemäß der Punkt, an dem sich die Gewohnheiten unterscheiden. Jede Verbindung bekommt in PostgreSQL einen eigenen Betriebssystemprozess. Nicht einen Thread in einem Pool, sondern einen vollwertigen Prozess. Das ist architektonisch eine sehr robuste Entscheidung — stürzt einer ab, reißt er die anderen nicht mit.

26:39 Es bedeutet aber auch, dass eine Verbindung deutlich mehr kostet, als die meisten annehmen. Und dieser Preis fällt auch dann an, wenn die Sitzung die meiste Zeit gar nichts tut, sondern nur wartet. Anwendungen öffnen typischerweise sehr viel mehr Verbindungen, als sie gleichzeitig wirklich benutzen. In einem System mit Thread-Pool fällt das kaum auf. Hier fällt es auf.

27:02 Je mehr Prozesse existieren, desto mehr Zeit verbringt das Betriebssystem damit, zwischen ihnen umzuschalten — Arbeit, die niemandem nützt. Deshalb ist ein Verbindungspool im PostgreSQL-Umfeld kein Luxus, sondern Standardausstattung. Er bündelt viele Anwendungsverbindungen auf wenige, dafür gut ausgelastete Sitzungen. PgBouncer ist dabei der verbreitetste Weg.

27:25 Diese kleine Abfrage ist im Alltag Gold wert, weil sie eine Diagnose in einer Zeile liefert. Was Sie sehen wollen, ist das Verhältnis: Wie viele Sitzungen arbeiten gerade wirklich, und wie viele halten nur einen Platz besetzt? Ein großer Anteil untätiger Sitzungen bei wenigen aktiven ist das klassische Bild für eine Anwendung ohne Pool.

27:44 Und achten Sie auf einen bestimmten Zustand — Sitzungen, die innerhalb einer offenen Transaktion untätig sind. Die sind doppelt teuer, denn sie halten zusätzlich Sperren und blockieren das Aufräumen. Diese Aufgabe zielt auf eine Diagnose, keine Zahl. Die eigentliche Frage lautet nämlich nicht „Wie viele Verbindungen haben wir?", sondern „Woran liegt es, dass es so viele sind?".

28:06 Erst diese Unterscheidung führt zur richtigen Maßnahme — die Grenze anzuheben oder die Zahl zu senken sind zwei völlig verschiedene Antworten. Und nehmen Sie die Ausbaustufe mit: Der Zustand, den ich gerade erwähnt habe, verdient eine eigene Betrachtung, weil er mehr Schaden anrichtet als bloßes Untätigsein. Der erste Punkt ist der Reflex, den es zu unterdrücken gilt: Die Grenze anzuheben löst kein Verbindungsproblem, es verschiebt nur die Wand, gegen die man läuft.

28:33 Der zweite Punkt ist der, den man schmerzhaft lernt — es gibt eine kleine Reserve für administrative Zugänge, und wenn Sie die aufbrauchen, sperren Sie sich in genau dem Moment aus, in dem Sie den Zugang am dringendsten bräuchten. Und der letzte Punkt betrifft die Konfiguration des Pools selbst: Die Betriebsart muss zu dem passen, was Ihre Anwendung tut, sonst schaffen Sie sich neue, subtilere Probleme.

Virtualisierung und PostgreSQL 18

28:55 Zum Abschluss des Moduls ein Blick auf die Umgebung — und darauf, warum Tuning-Rezepte in der Cloud anders zu lesen sind als auf eigener Hardware. Wir klären, welche Effekte in geteilten Umgebungen Ihre Messungen verzerren, was Sie dort überhaupt beeinflussen können, und was sich mit dem asynchronen Ein- und Ausgabeweg in Version 18 gerade verschiebt.

29:15 Danach lesen Sie fremde Empfehlungen mit gesünderer Skepsis. Alles, was wir bis hierhin besprochen haben, setzt stillschweigend voraus, dass die Datenbank die Hardware kennt, auf der sie läuft. In virtualisierten und verwalteten Umgebungen stimmt das nicht mehr. Rechenzeit, Speicher und Ein-/Ausgabe werden geteilt, teils begrenzt, und manchmal ändert sich das über den Tag.

29:37 Dieselbe Konfiguration verhält sich dort schlicht anders — nicht schlechter oder besser, aber weniger vorhersagbar. Und das ist eine Einsicht, die Sie beim Lesen jeder Tuning-Empfehlung im Hinterkopf behalten sollten. Der bekannteste Effekt ist der laute Nachbar: Eine andere Arbeitslast auf derselben physischen Maschine zieht Ihnen Ein-/Ausgabe und Rechenzeit weg, ohne dass Sie das sehen könnten.

29:59 Dazu kommen Instanzmodelle, die unter Dauerlast gedrosselt werden — Ihr System ist dann nicht langsam geworden, es wird gebremst. Und schließlich geben verwaltete Dienste einen Teil der Parameter gar nicht frei. Das ist kein Grund zur Klage, aber ein Grund, die eigenen Messungen skeptischer zu lesen: Nicht jede Schwankung ist eine Eigenschaft Ihrer Datenbank.

30:20 Hier passiert gerade etwas Bemerkenswertes. Traditionell hat ein Prozess einen Lesezugriff angestoßen und dann gewartet, bis die Platte antwortete — bei einer mechanischen Festplatte war das auch vernünftig. Moderne SSDs können aber viele Anfragen gleichzeitig bedienen, und das blieb bisher weitgehend ungenutzt. Mit Version 18 kann PostgreSQL diese Wartezeiten überlappen.

30:42 Das macht Tuning nicht überflüssig, aber es passt zu einem größeren Trend: Die Datenbank wird von Version zu Version besser darin, sich selbst an moderne Hardware anzupassen. Der erste Punkt fasst dieses Kapitel zusammen: Wer in einer geteilten Umgebung misst, misst immer auch die Nachbarn mit. Der zweite ist der Grund, warum ich gegenüber fremden Empfehlungen so beharrlich skeptisch bin — ohne die Speicherklasse darunter ist eine Zahl bedeutungslos.

31:09 Und der letzte Punkt ist schlicht Handwerk: vor dem Versionswechsel messen, nach dem Versionswechsel messen. Sonst haben Sie hinterher ein Gefühl, aber kein Ergebnis.

Die Grundlage steht

31:19 Damit steht das Fundament. Sie wissen jetzt, wie PostgreSQL Speicher aufteilt, wie es Schreibarbeit verteilt, warum es im Hintergrund aufräumen muss und was eine Verbindung wirklich kostet. Vor allem aber haben Sie ein Vorgehen: einzeln ändern, laden, prüfen, messen — und erst dann weitermachen. Im nächsten Modul wechseln wir die Ebene.

31:38 Dort geht es um Ausführungspläne, um Indizes und um die Frage, warum die Form einer Abfrage oft mehr entscheidet als jede Einstellung, die wir heute besprochen haben.