it-swarm.com.de

Werden unter 9.1 noch regelmäßige VAKUUMANALYSEN empfohlen?

Ich verwende PostgreSQL 9.1 unter Ubuntu. Sind geplant VACUUM ANALYZE immer noch empfohlen, oder reicht Autovakuum aus, um alle Anforderungen zu erfüllen?

Wenn die Antwort "es kommt darauf an" lautet, dann:

  • Ich habe eine größere Datenbank (30 GiB komprimierte Speicherauszugsgröße, 200 GiB Datenverzeichnis)
  • Ich mache ETL in die Datenbank und importiere fast 3 Millionen Zeilen pro Woche
  • Die Tabellen mit den häufigsten Änderungen werden alle von einer Mastertabelle geerbt, ohne dass Daten in der Mastertabelle enthalten sind (Daten werden nach Wochen aufgeteilt).
  • Ich erstelle stündliche Rollups und von dort aus tägliche, wöchentliche und monatliche Berichte

Ich frage, weil die geplanten VACUUM ANALYZE wirkt sich auf meine Berichterstattung aus. Es läuft länger als 5 Stunden und ich musste es diese Woche zweimal beenden, da es sich auf die regulären Datenbankimporte auswirkte. check_postgres meldet kein signifikantes Aufblähen in der Datenbank, das ist also kein wirkliches Problem.

Aus den Dokumenten sollte sich Autovacuum auch um das Umwickeln der Transaktions-ID kümmern. Die Frage lautet: brauche ich noch ein VACUUM ANALYZE?

38

VACUUM wird nur für aktualisierte oder gelöschte Zeilen in nicht temporären Tabellen benötigt. Natürlich machst du viele INSERTs, aber aus der Beschreibung geht nicht hervor, dass du auch viele UPDATEs oder DELETEs machst.

Diese Operationen können mit der Ansicht pg_stat_all_tables Verfolgt werden, insbesondere mit den Spalten n_tup_upd Und n_tup_del. Noch wichtiger ist, dass es eine n_dead_tup - Spalte gibt, die pro Tabelle angibt, wie viele Zeilen gesaugt werden müssen. (Siehe Überwachen von Statistiken im Dokument für Funktionen und Ansichten zum Sammeln von Statistiken).

Eine mögliche Strategie in Ihrem Fall wäre, das geplante VAKUUM zu unterdrücken, diese Ansicht im Auge zu behalten und zu überprüfen, auf welchen Tabellen der n_dead_tup Deutlich ansteigt. Wenden Sie dann das aggressive VAKUUM nur auf diese Tabellen an. Dies ist ein Gewinn, wenn es große Tabellen gibt, deren Zeilen niemals gelöscht oder aktualisiert werden und das aggressive VACUUM nur bei kleineren Tabellen wirklich notwendig ist.

Führen Sie jedoch weiterhin die ANALYSE aus, damit der Optimierer immer über neue Statistiken verfügt.

32
Daniel Vérité

Ich sehe nichts in Ihrer Frage, um das sich autovacuum nicht kümmern würde. Dies hängt weitgehend vom Muster Ihrer Schreibaktivitäten ab . Sie erwähnen 3 Millionen neu Zeilen pro Woche, aber INSERT (oder COPY) erstellen normalerweise kein Aufblähen von Tabellen und Indizes. (autovacuum muss sich nur um Spaltenstatistik , Sichtbarkeitskarte und einige kleinere Jobs kümmern). UPDATE und DELETE sind die Hauptursache für das Aufblähen von Tabellen und Indizes, insbesondere bei der Ausrichtung auf zufällige Zeilen. Ich sehe nichts davon in Ihrer Frage.

autovacuum hat einen langen Weg zurückgelegt und leistet in Postgres 9.1 oder höher hervorragende Arbeit. Ich würde mir die autovacuum Einstellungen ansehen. Wenn das Staubsaugen dazu neigt, Ihre Arbeitsbelastung zu beeinträchtigen, lesen Sie auch "Kostenbasierte Vakuumverzögerung" . Manuelles Staubsaugen sollte die seltene Ausnahme sein.

Wenn Sie viele zufällige UPDATE haben, möchten Sie möglicherweise FILLFACTOR auf einen Wert unter 100 setzen, um sofort HOT-Updates zu ermöglichen und den Bedarf zu verringern VACUUM. Mehr zu HOT Updates:

Beachten Sie auch, dass temporäre Tabellen manuell VACUUM & ANALYZE benötigen. Ich zitiere das Handbuch zu CREATE TABLE :

Der autovacuum daemon kann nicht auf temporäre Tabellen zugreifen und diese daher nicht saugen oder analysieren. Aus diesem Grund sollten geeignete Vakuum- und Analysevorgänge über Sitzungs-SQL-Befehle ausgeführt werden. Wenn beispielsweise eine temporäre Tabelle in komplexen Abfragen verwendet werden soll, ist es ratsam, ANALYZE für die temporäre Tabelle auszuführen, nachdem sie gefüllt wurde.

25

Ich bin damit einverstanden, dass die Verwendung der automatischen Funktionen am besten ist, anstatt sie datenbankweit auszuführen. In den meisten Fällen ist jedoch eine Optimierung pro Tabelle erforderlich.

Ich bin nicht ganz mit der Wahl des Designs von Postgres einverstanden, um Vakuum und Analyse zusammenzubinden. Ich habe mehrere Fälle gesehen, in denen Datenbanken, die viel einfügen/aktualisieren, aber wenig löschen, niemals analysiert werden und anfangen, schlecht zu funktionieren.

Die Lösung besteht darin, in die Tabellen zu gehen, die häufig verwendet werden und großen Abfragen unterliegen, und die Einstellungen für die automatische Analyse für diese Tabellen so festzulegen, dass sie ein- oder jeden zweiten Tag analysiert werden.

Sie können die Einstellungen pro Tabelle in der Benutzeroberfläche auf der Registerkarte "Automatisches Vakuum" aufrufen und dort Analyseeinstellungen sehen, die Sie unabhängig vom Vakuum einstellen können.

Die Einstellungen landen in der reloptions-Tabelle und können mit der Abfrage angezeigt werden

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

und ein Stichprobenwert dort einer aggressiven Analyse könnte sein

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Um zu sehen, wann Ihre Tabellen das letzte Mal automatisch analysiert wurden

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;
6
MvcCmsJon