News zu PostgreSQL Datenbank
Bereinigt Autovacuum große Tabellen schneller, wenn zusätzliche Worker die Indexarbeit übernehmen? Wir haben die Parallelisierung in PostgreSQL 19 untersucht. Das Ergebnis: Die parallelen Worker wurden zuverlässig gestartet – ein reproduzierbarer Geschwindigkeitsvorteil blieb unter den gewählten Laborbedingungen jedoch aus.
Autovacuum gehört zur laufenden Wartung einer PostgreSQL-Datenbank. Es sorgt unter anderem dafür, dass Speicherplatz nicht mehr benötigter Zeilenversionen wiederverwendet werden kann. Solche sogenannten Dead Tuples entstehen beispielsweise durch Updates und Löschungen.
In PostgreSQL 19 ist es mit Autovacuum möglich, bestimmte Arbeiten an Indizes parallel auszuführen. Ob zusätzliche Worker auch die gesamte Bereinigung beschleunigen, hängt jedoch von der Tabelle, ihren Indizes und den verfügbaren Systemressourcen ab.
Die Parallelisierung betrifft die Index-Vacuum- und Index-Cleanup-Phasen. Sie verteilt nicht sämtliche Arbeiten eines Autovacuum-Durchlaufs auf mehrere Prozesse.
Dabei sind zwei Einstellungen zu unterscheiden:
autovacuum_max_workers begrenzt die gleichzeitig laufenden regulären Autovacuum-Worker, die unterschiedliche Tabellen bearbeiten können.autovacuum_max_parallel_workers begrenzt die zusätzlichen parallelen Worker, die ein einzelner Autovacuum-Worker für die Indexbearbeitung einsetzen kann. Der dokumentierte Standardwert ist 0; damit ist diese Parallelisierung deaktiviert.
Über den Tabellenparameter autovacuum_parallel_workers lässt sich die Parallelität zusätzlich pro Tabelle begrenzen. Wie viele Worker tatsächlich zum Einsatz kommen, hängt unter anderem von geeigneten Indizes und verfügbaren Worker-Kapazitäten ab. Eine konfigurierte Obergrenze garantiert daher keine entsprechende Anzahl gestarteter Prozesse.
Die Versuche liefen auf einer einzelnen PostgreSQL-19beta3-Instanz in einer virtuellen Maschine mit 16 vCPUs und 64 GB RAM. Untersucht wurden drei Tabellenklassen:
|
Tabellenklasse
|
Zeilen vor dem Löschen
|
Indexstruktur
|
Gelöschte Zeilen (Dead Tuples)
|
|---|---|---|---|
|
Kleine Tabellen
|
10.000 je Tabelle
|
Vier Indizes mit jeweils ca. 600 kB
|
Ca. 1.428 je Tabelle
|
|
Große Tabelle mit großen Indizes
|
10 Millionen
|
Vier vollständige Indizes mit jeweils ca. 563 MB
|
1.428.571
|
|
Große Tabelle mit kleinen Indizes
|
10 Millionen
|
Vier partielle Indizes mit jeweils ca. 5,7 MB
|
1.428.571
|
Die partiellen Indizes erfassten nur jede hundertste Zeile. Die Löschmenge wurde jeweils über das Muster id % 7 = 0 erzeugt.
Getestet wurden drei Einstellungen:
Bei den großen Tabellen wurde nach einem vorbereitenden `VACUUM (FREEZE, ANALYZE)` die definierte Löschmenge erzeugt. Anschließend bereinigte Autovacuum die entstandenen Dead Tuples. Die Laufzeiten stammen aus den PostgreSQL-Abschlusslogs. Ergänzend wurden CPU- und I/O‑Daten mit `vmstat` und `iostat` erfasst.
|
Testszenario
|
P0
|
P2
|
P4
|
|---|---|---|---|
|
Kleine Tabellen
|
Median 0,11 s
|
Median 0,06 s
|
Ca. 0,07 s je Tabelle
|
|
Große Tabelle mit großen Indizes
|
Median 974,30 s
|
Median 1.140,31 s
|
Median 1.027,73 s
|
|
Große Tabelle mit kleinen, partiellen Indizes
|
Median 979,28 s
|
Median 1.005,33 s
|
Median 1.033,17 s
|
Bei den kleinen Tabellen waren die Vacuum-Laufzeiten sehr kurz. Dadurch hatten WAL-Aufkommen, Checkpoints, Cache-Zustand und die Messauflösung einen relativ großen Einfluss. Die P4-Reihe wurde mit vier kleinen Tabellen durchgeführt und ist deshalb nur eingeschränkt mit den Einzeltabellenläufen vergleichbar.
Bei den großen Tabellen zeigten die `vmstat`- und `iostat`-Daten deutliche Schwankungen bei I/O‑Wartezeit, Schreiblatenz und Geräteauslastung. Diese Unterschiede traten auch innerhalb derselben Konfiguration auf und waren teilweise größer als der erwartete Effekt der Parallelisierung. Bei der großen Tabelle mit partiellen Indizes lagen beispielsweise bereits die P0-Laufzeiten zwischen 816,40 und 1.477,53 Sekunden.
Die PostgreSQL-Abschlusslogs bestätigen, dass die parallelen Worker tatsächlich eingesetzt wurden. Bei P2 wurden jeweils zwei Worker gestartet. Bei P4 wurden trotz der Einstellung von maximal vier Worker jeweils nur drei geplant und gestartet (bedingt durch die Konfiguration oder Anzahl der verfügbaren Indizes).
In einer zweiten Testphase – welche wir zu gegebener Zeit ebenfalls hier veröffentlichen werden – wollen wir die Parallelisierung unter realistischeren Betriebsbedingungen untersuchen. Geplant sind dedizierte oder stark isolierte Systeme und ein paralleler OLTP-Workload mit INSERT-, UPDATE-, DELETE- und SELECT-Operationen. Dabei sollen mehrere Tabellen mit unterschiedlichen Änderungsraten und Indexstrukturen gleichzeitig betrachtet werden.
Die Varianten P0, P2 und P4 sollen automatisiert, in wechselnder Reihenfolge und mit mehreren Wiederholungen getestet werden. Neben der Dauer des Autovacuum-Laufs wollen wir auch den Einfluss auf die Anwendung messen: etwa Transaktionsdurchsatz, Antwortzeiten sowie p95- und p99-Latenzen. Ergänzend erfassen wir PostgreSQL-interne Werte, WAL-Aufkommen, Checkpoints und Systemmetriken wie CPU-Auslastung, I/O‑Wartezeiten und Storage-Latenzen.
So soll eine belastbare Entscheidungshilfe entstehen: Unter welchen Ressourcen- und Lastbedingungen lohnt sich die Parallelisierung – und wann konkurrieren die zusätzlichen Worker vor allem um dieselben Ressourcen?
Der Test bestätigt, dass PostgreSQL 19 parallele Worker für die Index-Vacuum-Arbeiten einsetzt. Einen reproduzierbaren Zeitgewinn konnten wir in diesem Laboraufbau jedoch nicht messen. Bei den sehr kurzen Läufen mit kleinen Tabellen war der Effekt kaum isolierbar. Bei den großen Tabellen lagen die Mediane nahe beieinander. Stellenweise führten parallele Worker aufgrund von I/O‑Konkurrenz (*Resource Contention*) sogar zu leichten Laufzeitverlängerungen.
Das ist kein Beleg dafür, dass paralleles Autovacuum grundsätzlich keinen Vorteil bringt. Die Ergebnisse gelten für eine einzelne virtuelle Maschine, einen isolierten Test ohne Anwendungslast und die hier verwendeten Tabellen und Indizes. Sie lassen sich daher nicht ohne Weiteres auf produktive PostgreSQL-Systeme übertragen. Auch Parameter wie maintenance_work_mem und der verfügbare Speicherdurchsatz können beeinflussen, ob zusätzliche Worker ihre Arbeit tatsächlich schneller erledigen.
Nach unserem Redaktionsschluss wurde PostgreSQL 19 RC1 veröffentlicht. Der Release Candidate enthält mehrere Fehlerkorrekturen für das neue Feature Parallel Autovacuum (autovacuum_max_parallel_workers).
Die wichtigsten Verbesserungen im Überblick:
pg_stat_progress_vacuum.delay_time) sowie der I/O‑Zeitmessung in den Autovacuum-Logs.
Fazit:
Die Korrekturen verbessern insbesondere die Stabilität, Ressourcensteuerung und Beobachtbarkeit des parallelen Autovacuums.
Hinweis:
Eine Änderung von autovacuum_max_parallel_workers beeinflusst weiterhin nur neu gestartete VACUUM-Vorgänge, nicht bereits laufende Worker.
Hier findest du weitere Infos aus der Welt von PostgreSQL aus unserem News & Insights Bereich.
Share this article
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen