Arbeiten mit PostgreSQL Autovacuum auf - Amazon Aurora

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Arbeiten mit PostgreSQL Autovacuum auf

Wir empfehlen ausdrücklich die Selbstbereinigungsfunktion zu verwenden, um die Integrität Ihrer PostgreSQL-DB-Instance zu wahren. Die Selbstbereinigung automatisiert den Start der Befehle VACUUM und ANALYZE. Sie prüft auf Tabellen mit einer großen Zahl von eingefügten, aktualisierten oder gelöschten Tupeln. Nach dieser Prüfung wird Speicher durch Entfernen von überflüssigen Daten oder Tupeln aus der PostgreSQL-Datenbank freigegeben.

Standardmäßig ist Autovacuum für die aktiviert, die Sie mit einer der standardmäßigen PostgreSQL-DB-Parametergruppen erstellen. Andere Konfigurationsparameter, die mit der Selbstbereinigungsfunktion verknüpft sind, sind ebenfalls standardmäßig festgelegt. Da diese Standardwerte generisch sind, können Sie davon profitieren, einige der mit der Selbstbereinigungsfunktion verbundenen Parameter für Ihre spezifische Workload zu optimieren.

Im Folgenden finden Sie weitere Informationen zum Autovacuum und zur Optimierung einiger seiner Parameter auf Ihrer Aurora PostgreSQL-DB-Instance von .

Zuweisen von Arbeitsspeicher für die Selbstbereinigung

Einer der wichtigsten Parameter, der sich auf die Leistung der Selbstbereinigung auswirkt, ist der Parameter autovacuum_work_mem. In Aurora PostgreSQL, Versionen 14 und früher, ist der autovacuum_work_mem Parameter auf -1 gesetzt, was bedeutet, dass stattdessen die Einstellung von maintenance_work_mem verwendet wird. Wird für alle anderen Versionen durch autovacuum_work_mem GREATEST ({DBInstanceClassMemory/32768}, 65536) bestimmt.

Bei manuellen Vakuumvorgängen wird immer die maintenance_work_mem Einstellung verwendet, wobei die Standardeinstellung GREATEST ({DBInstanceClassMemory/63963136 *1024}, 65536) ist. Sie kann auch auf Sitzungsebene mithilfe des Befehls für gezieltere manuelle Operationen angepasst werden. SET VACUUM

Das autovacuum_work_mem legt fest, dass der Speicher für das automatische Vakuumieren die Kennungen von toten Tupeln () zum Absaugen von Indizes enthalten soll. pg_stat_all_tables.n_dead_tup

Beachten Sie bei Berechnungen zur Bestimmung des autovacuum_work_mem Parameterwerts Folgendes:

  • Wenn Sie den Parameter zu niedrig einstellen, muss der Vakuumprozess die Tabelle möglicherweise mehrmals scannen, um die Arbeit abzuschließen. Solche wiederholten Scans können negative Auswirkungen auf die Leistung haben. Bei größeren Instanzen kann die Einstellung von maintenance_work_mem oder autovacuum_work_mem auf mindestens 1 GB die Leistung beim Bereinigen von Tabellen mit einer hohen Anzahl von toten Tupeln verbessern. In PostgreSQL-Versionen 16 und früheren Versionen ist die Speichernutzung von Vacuum jedoch auf 1 GB begrenzt, was ausreicht, um ungefähr 179 Millionen tote Tupel in einem einzigen Durchgang zu verarbeiten. Wenn eine Tabelle mehr tote Tupel enthält, muss Vacuum mehrere Durchläufe durch die Indizes der Tabelle durchführen, was den Zeitaufwand erheblich erhöht. Ab PostgreSQL Version 17 gibt es kein Limit von 1 GB, und Autovacuum kann mithilfe von Radixbäumen mehr als 179 Millionen Tupel verarbeiten.

    Ein Tupelbezeichner hat eine Größe von 6 Byte. Um den Speicherbedarf für das Löschen eines Tabellenindexes zu schätzen, fragen Sie pg_stat_all_tables.n_dead_tup nach der Anzahl der toten Tupel ab und multiplizieren Sie diese Zahl dann mit 6, um den Speicherplatz zu ermitteln, der für das Löschen des Index in einem einzigen Durchgang erforderlich ist. Sie können die folgende Abfrage verwenden:

    SELECT relname AS table_name, n_dead_tup, pg_size_pretty(n_dead_tup * 6) AS estimated_memory FROM pg_stat_all_tables WHERE relname = 'name_of_the_table';
  • Der Parameter autovacuum_work_mem funktioniert in Verbindung mit dem Parameter autovacuum_max_workers. Jeder Mitarbeiter unter Ihnen autovacuum_max_workers kann den von Ihnen zugewiesenen Speicher verwenden. Wenn Sie viele kleine Tabellen haben, müssen Sie mehr autovacuum_max_workers und weniger autovacuum_work_mem zuteilen. Wenn Sie über große Tabellen (größer als 100 GB) verfügen, sollten Sie mehr Speicher und weniger Arbeitsprozesse zuweisen. Sie müssen genügend Arbeitsspeicher zuweisen, um den Vorgang für Ihre größte Tabelle erfolgreich ausführen zu können. Stellen Sie daher sicher, dass die Kombination aus Arbeitsprozessen und Arbeitsspeicher dem Gesamtspeicher entspricht, den Sie zuweisen möchten.

Verringern der Wahrscheinlichkeit von Transaktions-ID-Wraparounds

In einigen Fällen sind Parametergruppen-Einstellungen, die sich auf die Selbstbereinigung beziehen, möglicherweise nicht aggressiv genug, um Transaktions-ID-Wraparounds zu verhindern. Um dieses Problem zu lösen, bietet Aurora PostgreSQL einen Mechanismus, der die Autovacuum-Parameterwerte automatisch anpasst. Adaptive Autovacuum ist eine Funktion für . In der PostgreSQL-Dokumentation finden Sie eine sehr detaillierte Beschreibung von Transaktions-ID-Wraparounds.

Adaptives Autovacuum ist standardmäßig für aktiviert, wobei der dynamische Parameter auf ON gesetzt ist. rds.adaptive_autovacuum Wir raten dringend dazu, diese Option aktiviert zu lassen. Um die adaptive Optimierung der Selbstbereinigungsparameter zu deaktivieren, stellen Sie den Parameter rds.adaptive_autovacuum jedoch auf 0 oder OFF ein.

Der Transaktions-ID-Wraparound ist auch dann noch möglich, wenn Aurora Amazon RDS die Autovacuum-Parameter optimiert. Wir empfehlen Ihnen, einen CloudWatch Amazon-Alarm für den Transaktions-ID-Wraparound zu implementieren. Weitere Informationen finden Sie im Datenbank-Blog im Beitrag Implementieren eines Frühwarnsystems für Transaktions-ID-Wraparound in RDS for PostgreSQL. AWS

Wenn die adaptive Abstimmung der Autovakuum-Parameter aktiviert ist, beginnt Amazon RDS mit der Anpassung der Autovakuum-Parameter, wenn die CloudWatch Metrik den Wert des autovacuum_freeze_max_age Parameters oder 500.000.000 MaximumUsedTransactionIDs erreicht, je nachdem, welcher Wert größer ist.

Amazon RDS fährt mit dem Anpassen der Parameter für die Selbstbereinigung fort, wenn eine Tabelle weiterhin zu Transaktions-ID-Wraparounds tendiert. Jede dieser Anpassungen stellt weitere Ressourcen für die Selbstbereinigung bereit, um Wraparounds zu vermeiden. Amazon RDS aktualisiert die folgenden Parameter, die sich auf die Selbstbereinigung beziehen:

RDS ändert diese Parameter nur, wenn der neue Wert die Selbstbereinigung aggressiver macht. Die Parameter werden im Arbeitsspeicher auf der DB-Instance geändert. Die Werte in der Parametergruppe werden nicht geändert. Um die aktuellen Arbeitsspeichereinstellungen anzuzeigen, verwenden Sie den PostgreSQL-SQL-Befehl SHOW.

Wenn Amazon RDS einen dieser Selbstbereinigungsparameter ändert, wird ein Ereignis für die betroffene DB-Instance erzeugt. Dieses Ereignis ist auf der AWS Management Console und über die Amazon RDS-API sichtbar. Wenn die MaximumUsedTransactionIDs CloudWatch Metrik wieder unter den Schwellenwert fällt, setzt Amazon RDS die Autovakuum-bezogenen Parameter im Speicher auf die in der Parametergruppe angegebenen Werte zurück. Es generiert dann ein anderes Ereignis, das dieser Änderung entspricht.