So macht man Postgres langsam

• Vorstellung eines experimentellen Ansatzes zu Parameterkombinationen, die die Postgres-Performance extrem verschlechtern können
• Üblicherweise werden Cache, Indizes, WAL, I/O und verschiedene andere Faktoren in die entgegengesetzte Richtung getunt
• Durch extreme Manipulation von shared_buffers, autovacuum und WAL-bezogenen Optionen wurde ein Rückgang auf das 42.000-Fache erreicht
• Auch neue Funktionen wie io_method und io_workers aus den neuen Postgres-18/19-Versionen wurden genutzt, um die Begrenzung auf einen einzelnen I/O-Thread zu testen
• Die Versuchsergebnisse zeigen, dass allein über die Postgres-Konfigurationsdatei eine extreme Leistungsverschlechterung möglich ist

---

Überblick

Dieser Beitrag beschreibt ein Experiment, das im Gegensatz zum üblichen Postgres-Tuning, das auf Beschleunigung abzielt, ausschließlich darauf ausgerichtet ist, PostgreSQL langsamer zu machen, indem nur verschiedene Konfigurationswerte verändert werden, um die Performance bis an ihre Grenzen zu verschlechtern.
Der Test basiert auf der TPC-C-Workload von BenchBase (128 Lagerhäuser, 100 Verbindungen, jeweils Versuche mit bis zu 10.000 Transaktionen pro Sekunde, aktuelles Postgres 19devel, Ryzen 7950x, 32 GB RAM, 2 TB SSD, Laufzeit 120 Sekunden).
Mit den Standardwerten lag die Leistung bei 7082 TPS; anschließend wurde schrittweise beobachtet, wie stark sie durch die jeweiligen Parameteränderungen verlangsamt wird.

Caching drastisch reduzieren

• Postgres nutzt einen starken Cache (shared_buffers), um disk I/O zu reduzieren
• Wird shared_buffers vom Standardwert (10 GB) auf 8 MB reduziert, fällt die TPS auf etwa 1/7 (1052 TPS)
• Es wurde beobachtet, dass die Cache-Hit-Rate von 99,90 % auf 70,52 % sinkt und die read-syscalls um mehr als das 300-Fache zunehmen
• Es wurde versucht, auf 128 kB zu reduzieren, aber Postgres erlaubt mindestens nur etwa 2 MB, wodurch die Leistung weiter auf 485 TPS sinkt

Mehr Hintergrundarbeit erzeugen (autovacuum-Tuning)

• Alle Schwellwerte rund um autovacuum wurden auf das Minimum gesetzt, sodass bei fast jeder Operation ein Vacuum läuft
  • Kombinationen wie autovacuum_vacuum_insert_threshold=1, autovacuum_naptime=1 usw.
  • Vacuum läuft dadurch praktisch fast jede Sekunde erneut, selbst wenn faktisch kaum Arbeit anfällt
• In diesem Zuge wurde maintenance_work_mem auf 128 kB reduziert und das komplette autovacuum-Logging aktiviert
• Das Ergebnis: Die TPS sinkt auf 293 (weniger als 1/20 des Ausgangswerts)
• Anhand der Echtzeit-Logs zu autovacuum wurde bestätigt, dass die häufige Hintergrundarbeit tatsächlich die Ursache des Performance-Einbruchs ist

WAL-Schreibvorgänge maximal verschlechtern

• Alle WAL-bezogenen Parameter wurden auf den schlechtestmöglichen Zustand eingestellt
  • wal_writer_flush_after=0, wal_writer_delay=1, wal_sync_method=open_datasync usw.
  • Checkpoints werden alle 30 Sekunden erzwungen, min/max_wal_size=32MB wird auf dem Minimum gehalten
  • wal_level=logical, wal_log_hints=on usw., sodass sogar unnötige Informationen ins WAL geschrieben werden
  • Zusätzliche Lasten wie track_wal_io_timing, summarize_wal wurden ebenfalls aktiviert
• Dadurch sinkt die TPS auf 98 (weniger als 1/70 des Ausgangswerts)
• In den Logs zeigt sich anomales Verhalten, etwa dass Checkpoints alle paar hundert ms wiederholt auftreten

Wirkung von Indizes entfernen

• Die Nutzung von Indizes wurde dadurch praktisch deaktiviert, dass alle Werte, mit denen ihre Kosten berechnet werden, auf das Maximum gesetzt wurden (random_page_cost=1e300, cpu_index_tuple_cost=1e300)
• shared_buffers wurde zur Stabilität wieder auf 8 MB erhöht, und die TPS fiel auf 0,87 (eine Verlangsamung um das 7000-Fache)

Einzelnen I/O-Thread erzwingen

• Nutzung neuer Funktionen aus Postgres 18+
• Mit io_method=worker, io_workers=1 wird sämtliches I/O auf einen einzelnen Worker-Thread beschränkt
• Die TPS fällt weiter auf 0,016 (42.000-fach langsamer)
• Im Test mit 100 Verbindungen und 120 Sekunden wurden nur 11 Transaktionen erfolgreich abgeschlossen

Fazit und Hinweise zur Reproduktion

• Es wird gezeigt, dass sich eine Produktionsdatenbank mit insgesamt nur 32 Parameter-Manipulationen praktisch in einen Zustand der „Lähmung“ versetzen lässt
• Allein durch Änderungen in postgresql.conf lässt sich die Leistungsverschlechterung maximieren
• Wer das Experiment reproduzieren möchte, sollte BenchBase Postgres, die oben genannte TPC-C-Umgebung und die vollständige Liste aller Einstellungen heranziehen
• Einige zusätzliche Parameter oder weitere Versuche zur Verlangsamung sind nicht enthalten

Zusammenfassung der Parameter

• shared_buffers = 8MB
• autovacuum-bezogene thresholds/scale_factor = auf 0–1 minimiert
• Vacuum-bezogene Kosten sowie Speicher/Logging: minimiert bzw. maximiert
• WAL-bezogene sync/flush/Logging/Level usw.: auf langsam gehalten
• Index-bezogene random_page_cost, cpu_index_tuple_cost: auf 1e300 gesetzt
• io_method = worker, io_workers = 1
• Weitere Detailwerte siehe Liste im Haupttext

Schluss

• Schon allein über die Datei postgresql.conf lässt sich ein massiver Performance-Einbruch auslösen
• In der Praxis kann diese Kombination umgekehrt als Referenz für effiziente Performance-Optimierung dienen
• Der Beitrag endet mit dem Hinweis, dass der Autor das Experiment wegen Rückenschmerzen unterbrechen musste

[GN⁺]

Hacker-News-Kommentare

• Hier wird eine Methode vorgestellt, bei der man Indizes, mehrere Tabellen, Transaktionen, Entity-Beziehungen und referenzielle Integrität komplett vergisst und wie in frühen Versionen von TRIRIGA alle Daten in einer einzigen Tabelle nutzt – wie eine KVS-NoSQL-SQL-Lösung
• Ich finde diesen Ansatz so unterhaltsam, dass daraus gern eine fortlaufende Reihe oder sogar ein Buch mit dem Titel „Wie man die Dinge noch mehr ruiniert“ werden dürfte; indem man lernt, wie es falsch geht, findet man oft die besseren Wege, und im O’Reilly-Stil sollte das Cover ein schlecht gezeichnetes Fantasy-Tier zeigen (z. B. ein Einhorn mit Köpfen an beiden Enden, das über AirPods telefoniert, einem Betrüger Geld gibt, PowerPoint baut, sich überfrisst und Drogen nimmt)
  • Im Zweiten Weltkrieg wurde so etwas tatsächlich als Strategie verwendet: Um das Überleben von Piloten zu verbessern, suchten Meteorologen zuerst nach den Bedingungen mit den höchsten Verlusten und planten Missionen dann so, dass genau diese Bedingungen vermieden wurden; siehe Suppose I wanted to kill a lot of pilots
  • In Kursen für kreatives Schreiben gab es auch Übungen, bei denen wir absichtlich schlecht geschriebene Texte lasen und analysierten oder gute Texte bewusst schlecht umschrieben; das war eine der hilfreichsten Schreibübungen überhaupt
  • Siehe auch die ORLYBooks-Parodieseite
• Ich fände es großartig, eine Produktions-Sandbox für Experimente mit Observability-Tools zu haben – ein SaaS-artiges System mittlerer Größe mit Nutzungssimulation, dazu ein einfach nur so lala konfiguriertes postgres/rabbit-Setup, an dem man Debugging-Tools oder -Strategien realistisch ausprobieren kann
• Diese Idee ist wirklich genial; wenn man gut optimieren will, ist es sinnvoll, am Anfang oder als Kontrollgruppe zuerst das genaue Gegenteil zu tun und alles komplett kaputtzumachen; man sollte sich ernsthaft fragen, ob man Datenbanken oder Systeme wirklich wissenschaftlich behandelt oder nur vage Best Practices nachläuft
  • So mache ich es jedes Mal, wenn ich einen neuen Cloud-Service nutze: Erst probiere ich so schnell wie möglich die Series A aus, und danach kümmere ich mich um die Optimierung der Cloud-Kosten
• The Defence of Duffer's Drift ist ein frühes Beispiel dieses Genres: In der ersten Geschichte vermasselt der Protagonist die Truppentaktik so sehr, dass er den Großteil seiner Leute verliert; in den späteren Geschichten werden die taktischen Bedingungen schrittweise verändert und die Ergebnisse entsprechend besser. Neuere Taktikbücher wie Musicians of Mars 2 verfolgen denselben Ansatz. Die erste Team-Badger-Geschichte ähnelt Duffer's Drift stark, ist aber je nach Position, Ausrüstung und Technik variiert. Die relevanten PDFs sind The Defence of Duffer's Drift und Musicians of Mars 2. Eindrucksvoll ist, wie der Team-Badger-Kommandeur nach seiner vernichtenden Niederlage nachvollzieht, warum er trotz seines Selbstvertrauens und seiner Vorbereitung so katastrophal verloren hat
  • Filme mit einem ähnlichen Motiv sind Groundhog Day und besonders Edge of Tomorrow; außerdem ist auch diese moderne Hommage aus einem britischen Militärblog einen Blick wert: Defence Baltic Bridge Dreams
• Die Erwähnung von Deadlocks fand ich interessant; ich frage mich, ob auch das Anpassen der Einstellungen für Transaction Isolation Levels behandelt wird
• Ich habe mich gefreut, B Sanderson erwähnt zu sehen
• Es wirkte wie eine Mischung aus Hyperbole and a Half und einem db admin; das Lesen hat Spaß gemacht, und ich habe sogar ein paar Dinge dabei gelernt
• Der Schreibstil und die Art, wie die Gedanken entfaltet wurden, waren wirklich hervorragend; sehr angenehm und unterhaltsam zu lesen

[sonic0987]

Großartig. Ich mag diesen Ansatz sehr.