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.
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 RDS for PostgreSQL Aurora PostgreSQL-DB-Instances 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 PostgreSQL-DB-Instance von RDS for PostgreSQL. Allgemeine Informationen finden Sie unter. Bewährte Methoden für die Arbeit mit PostgreSQL
Themen
Verringern der Wahrscheinlichkeit von Transaktions-ID-Wraparounds
Ermittlung, ob die Tabellen in Ihrer Datenbank bereinigt werden müssen
Ermittlung, für welche Tabellen derzeit eine Selbstbereinigung nötig ist
Ermittlung, ob die Selbstbereinigung derzeit ausgeführt wird und wie lange sie dauert
Neuindizierung einer Tabelle während der Ausführung einer Selbstbereinigung
Weitere Parameter, die sich auf die Selbstbereinigung auswirken
Festlegen von Selbstbereinigungsparametern auf Tabellenebene
Protokollieren von Selbstbereinigung- und Bereinigungsaktivitäten
Das Verhalten von Autovacuum bei ungültigen Datenbanken verstehen
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
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
oderautovacuum_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 Parameterautovacuum_max_workers
. Jeder Mitarbeiter unter Ihnenautovacuum_max_workers
kann den von Ihnen zugewiesenen Speicher verwenden. Wenn Sie viele kleine Tabellen haben, müssen Sie mehrautovacuum_max_workers
und wenigerautovacuum_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 RDS for PostgreSQL einen Mechanismus, der die Autovacuum-Parameterwerte automatisch anpasst. Adaptive Autovacuum In der PostgreSQL-Dokumentation finden Sie eine sehr detaillierte Beschreibung von Transaktions-ID-Wraparounds
Adaptives Autovacuum ist standardmäßig für RDS für PostgreSQL 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 Amazon RDS 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
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.