Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon Aurora PostgreSQL - Amazon Aurora
Zuweisen von Arbeitsspeicher für die SelbstbereinigungVerringern der Wahrscheinlichkeit von Transaktions-ID-Wraparounds

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 der PostgreSQL-Selbstbereinigung in Amazon Aurora PostgreSQL

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 die Selbstbereinigungsfunktion auf den DB-Instances für Aurora PostgreSQL aktiviert, die Sie mit einer der folgenden PostgreSQL-DB-Parametergruppe 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 zur Selbstbereinigung und dazu, wie Sie einige ihrer Parameter auf Ihrer DB-Instance von Aurora PostgreSQL aktivieren.

Themen

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 und zeigt somit an, dass stattdessen die maintenance_work_mem-Einstellung verwendet wird. Bei allen anderen Versionen wird autovacuum_work_mem durch GREATEST({DBInstanceClassMemory/32768}, 65536) bestimmt.

Manuelle Bereinigungsvorgänge verwenden immer die maintenance_work_mem-Einstellung mit einer Standardeinstellung von GREATEST({DBInstanceClassMemory/63963136*1024}, 65536). Dies kann auch auf Sitzungsebene mit dem SET-Befehl für gezieltere manuelle VACUUM-Operationen angepasst werden.

autovacuum_work_mem bestimmt den Speicher der automatischen Bereinigung zum Speichern von IDs toter Tupeln (pg_stat_all_tables.n_dead_tup) für Bereinigungsindizes.

Beachten Sie Folgendes, wenn Sie Berechnungen durchführen, um den Wert des autovacuum_work_mem-Parameters bestimmen:

  • Wenn Sie den Wert des Parameters zu niedrig einstellen, muss die Tabelle während des Bereinigungsvorgangs möglicherweise mehrmals gescannt werden, damit der Vorgang abgeschlossen werden kann. Solche wiederholten Scans können negative Auswirkungen auf die Leistung haben. Bei größeren Instances kann das Festlegen von maintenance_work_mem oder autovacuum_work_mem auf mindestens 1 GB die Leistung bei der Bereinigung von Tabellen mit einer hohen Anzahl von toten Tupeln verbessern. In den PostgreSQL-Versionen 16 und früher ist die Speichernutzung für die Bereinigung 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, sind mehrere Bereinigungsdurchläufe durch die Indizes der Tabelle erforderlich, was den Zeitaufwand erheblich erhöht. Ab PostgreSQL-Version 17 gibt es kein Limit von 1 GB mehr und die Selbstbereinigung kann mithilfe von Radixbäumen mehr als 179 Millionen Tupel verarbeiten.

    Ein Tupel-Bezeichner hat eine Größe von 6‎ Bytes. Um den Speicherbedarf für das Bereinigen eines Tabellenindex zu schätzen, fragen Sie pg_stat_all_tables.n_dead_tup ab, um die Anzahl der toten Tupel zu ermitteln. Multiplizieren Sie diese Zahl dann mit 6, um den Speicherbedarf zu bestimmen, der für das Bereinigen 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 Worker aus autovacuum_max_workers kann den von Ihnen zugeteilten Arbeitsspeicher nutzen. Wenn Sie viele kleine Tabellen haben, müssen Sie mehr autovacuum_max_workers und weniger autovacuum_work_mem zuteilen. Wenn Sie große Tabellen haben (größer als 100 GB), sollten Sie mehr Arbeitsspeicher und weniger Worker-Prozesse zuteilen. Sie müssen genügend Arbeitsspeicher zuweisen, um den Vorgang für Ihre größte Tabelle erfolgreich ausführen zu können. Daher muss die Kombination aus Worker-Prozessen und Arbeitsspeicher dem gesamten Arbeitsspeicher entsprechen, den Sie zuteilen 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 anzugehen, stellt Aurora PostgreSQL eine Methode bereit, mit der die Selbstbereinigungsparameter automatisch angepasst werden. Die adaptive Selbstbereinigung ist ein Feature für Aurora PostgreSQL. In der PostgreSQL-Dokumentation finden Sie eine sehr detaillierte Beschreibung von Transaktions-ID-Wraparounds.

Die adaptive Selbstbereinigung ist standardmäßig für Instances von Aurora PostgreSQL aktiviert, wobei der dynamische Parameter rds.adaptive_autovacuum auf ON gesetzt ist. 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.

Transaktions-ID-Wraparounds können selbst dann noch auftreten, wenn Aurora Amazon RDS die Selbstbereinigungsparameter optimiert. Wir raten Ihnen dazu, einen Amazon CloudWatch-Alarm für Transaktions-ID-Wraparounds zu implementieren. Weitere Informationen finden Sie im Beitrag Implement an Early Warning System for Transaction ID Wraparound in RDS für PostgreSQL im AWS-Database-Blog.

Wenn die adaptive Optimierung der Selbstbereinigungsparameter aktiviert ist, beginnt Amazon RDS mit dem Anpassen der Selbstbereinigungsparameter, wenn die CloudWatch-Metrik MaximumUsedTransactionIDs den Wert des autovacuum_freeze_max_age-Parameters oder 500 000 000 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-Managementkonsole und über die Amazon-RDS-API sichtbar. Nachdem der Schwellenwert der zurückgegebenen CloudWatch-Metrik MaximumUsedTransactionIDs unterschritten wurde, setzt Amazon RDS die sich auf die Selbstbereinigung beziehenden Parameter auf die in der Parametergruppe angegebenen Werte zurück. Es generiert dann ein anderes Ereignis, das dieser Änderung entspricht.