Soll ich meine PostgreSQL-Datenbank manuell VAKUUMIEREN, wenn Autovacuum aktiviert ist?


15

Ich verwende eine Software, die eine große PostgreSQL-Datenbank erstellt (es gibt eine Tabelle mit einer Million Zeilen darin), und die Entwickler sagen, ich sollte VACUUMund in ANALYZEregelmäßigen Abständen. Die Standardeinstellung für die PostgreSQL-Datenbank ist jedoch aktiviert autovacuum.

Soll ich überhaupt staubsaugen / analysieren? Was sind die Vorteile? Was ist der Unterschied zwischen automatischem und manuellem Vakuum?

In Pgadmin3 habe ich zum Beispiel Folgendes:
Bildbeschreibung hier eingeben

Antworten:


12

Ich bin mit ETL einverstanden, dass es keine kurze Antwort gibt. Die Größe ist nicht das Einzige, worauf es ankommt - wir betreiben ziemlich große PostgreSQL OLTP-Datenbanken (mit einigen Tabellen> 100.000.000 Zeilen) unter hoher Last und verlassen uns derzeit nur auf Autovakuum.

Dennoch scheinen mir zwei Dinge wichtig zu sein:

  • Es scheint ein Konsens zu bestehen, dass das automatische Absaugen niemals ausgeschaltet werden sollte, es sei denn, Sie haben eine sehr genau definierte Arbeitslast in Ihrer Datenbank und wissen genau, was Sie tun. Aber natürlich können Sie zusätzliche VACUUMund / oder ANALYZELäufe durchführen.

  • Bevor VACUUMich zusätzliche Läufe in Betracht ziehe, würde ich prüfen, wie das automatische Vakuum mithält. Sie können überprüfen, ob Tabellen die Autovakuum-Schwelle überschreiten, indem Sie pg_stat_user_tablesund abfragen pg_class. Ich habe eine solche Abfrage in einem anderen Thread gepostet, der von Interesse sein könnte: Aggressives Autovacuum in PostgreSQL .

    Leider ist es nicht so einfach (dh momentan nicht möglich), eine ähnliche Überprüfung auf Autoanalyse-Schwellenwerte durchzuführen. Die automatische Analyse setzt jedoch standardmäßig lange vor dem automatischen Vakuum ein und ist viel billiger. Wenn Ihre Datenbank also mit dem automatischen Vakuum Schritt halten kann, ist die automatische Analyse wahrscheinlich ebenfalls in Ordnung. Die letzten Autoanalyse-Daten können auch von abgefragt werden pg_stat_user_tables.

Einige Teile der (hervorragendsten) PostgreSQL-Dokumentation, die ich hilfreich fand:


7

Autovacuum sollte es ziemlich gut abdecken, es sei denn, Sie haben etwas falsch konfiguriert. Andere Antworten decken das bereits ab.

Es gibt jedoch einen klar definierten Fall für manuelle VACUUM (und vor allem: manuelle ANALYZE) Tabellen : temporäre Tabellen , die vom Autovakuum-Dämon nicht berücksichtigt werden. Ich zitiere das Handbuch CREATE TABLEhier :

Der Autovacuum-Daemon kann nicht auf temporäre Tabellen zugreifen und diese daher nicht vakuumieren oder analysieren. Aus diesem Grund sollten geeignete Vakuum- und Analysevorgänge über SQL-Sitzungsbefehle ausgeführt werden. Wenn beispielsweise eine temporäre Tabelle in komplexen Abfragen verwendet werden soll, ist es ratsam, sie ANALYZEnach dem Auffüllen für die temporäre Tabelle auszuführen .


4

Darauf gibt es keine kurze Antwort, da dies von vielen Faktoren abhängt. Ist das System langsam? Berührt das automatische Vakuum tatsächlich diesen Tisch? etc.

Hier sind einige gute Links zu diesem Thema:

Um eine klare Entscheidung treffen zu können, müssen Sie die Datenbank selbst verstehen und mehr darüber erfahren, was gerade passiert.


1

Ich glaube nicht, dass Sie manuell staubsaugen müssen, es sei denn, Sie bemerken einen Leistungsabfall. Es wird jedoch dringend empfohlen, die Vakuum- und Autovakuumeinstellungen zu überprüfen und an Ihre Bedürfnisse anzupassen

Führen Sie diese Abfrage aus, um Ihre aktuellen Einstellungen anzuzeigen:

SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

Die meisten Felder sind selbsterklärend. Hier finden Sie jedoch eine Dokumentation: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

Ich würde sagen, dass Ihr Ziel darin bestehen sollte, Autovakuum so zu konfigurieren, dass der Müll konsistent gereinigt wird. Führen Sie Autovakuum jedoch nicht ständig aus

Die wichtigsten Einstellungen sind:

  • autovacuum_vacuum_scale_factor - Bestimmt den Prozentsatz der Tupel, die tot sein können, bevor eine Bereinigung ausgelöst wird. Standardwert = 0,2
  • autovacuum_vacuum_threshold - Mindestanzahl von toten Tupeln, bevor die Bereinigung ausgelöst wird. Standardwert = 50

Threshold verhindert, dass der Bereinigungsprozess bei kleinen Tabellen zu oft ausgelöst wird.

Die Standardeinstellungen funktionieren einwandfrei, es sei denn, Sie haben sehr große Tabellen. Einfach ausgedrückt, wenn Sie einen Tisch mit 100 GB haben, werden Sie 20 GB Müll ansammeln, bevor der automatische Unterdruck ausgelöst wird. Daher empfehle ich normalerweise, den Skalierungsfaktor niedrig einzustellen. Wie niedrig sollten Sie selbst bestimmen? Ich benutze 0.05 für mein aktuelles Projekt

Schwellenwerte können ebenfalls erhöht werden. Viele Anwendungen haben ein paar Tabellen, die häufig aktualisiert werden, und 50 Tupel sind nicht so viel. Eine Erhöhung auf 1000 sollte zu keinem Problem führen, aber Sie sollten natürlich Ihren eigenen Fall in Betracht ziehen

Sie können auch das automatische Vakuum fein einstellen und für einige Ihrer Tabellen unterschiedliche Einstellungen vornehmen

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

Wenn Sie scale_factor und thresholds konfigurieren, sollten Sie in Ordnung sein. Sie können auch eine Erhöhung vornehmen autovacuum_vacuum_cost_limit, die standardmäßig vacuum_cost_limit200 entspricht. Dies ist eine sehr wichtige Funktion von Vacuum, mit der nicht alle Ressourcen aufgebraucht werden und die es Ihrer Anwendung ermöglicht, auch während des Staubsaugens mit Daten zu arbeiten , aber der Standardwert ist zu niedrig. Eine Erhöhung auf 1000 sollte keine nennenswerten Verzögerungen zur Folge haben, ermöglicht jedoch eine viel schnellere Beendigung des Vakuumprozesses

Natürlich können Sie das Vakuum auch manuell ausführen. Im einfachsten Fall können Sie einen einfachen Cron-Job ausführen, der jede Nacht eine vollständige Bereinigung durchführt, wenn nicht häufig auf Ihre Datenbank zugegriffen wird

Ich hoffe, das hilft!

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.