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.

Lösung von Problemen mit der Vakuumleistung in RDS für PostgreSQL

In diesem Abschnitt werden Faktoren erörtert, die häufig zu einer langsameren Vakuumleistung beitragen, und es wird erläutert, wie diese Probleme behoben werden können.

Saugen Sie große Indizes ab

Der VACUUM Prozess besteht aus mehreren Schritten: Initialisierung, Scannen des Heaps, Löschen von Indizes und Heap, Bereinigen von Indizes, Kürzen des Heaps und Durchführung der abschließenden Bereinigung. Beim Scannen werden Seiten beschnitten, defragmentiert und eingefroren. Nachdem der Heap vollständig gescannt wurde, werden die Indizes bereinigt, leere Seiten werden an das Betriebssystem zurückgegeben und die letzten Bereinigungsaufgaben, wie das Löschen der freien Speicherzuweisung und das Aktualisieren der Statistiken, sind abgeschlossen.

Beim Löschen von Indizes können mehrere Durchgänge erforderlich sein, wenn die Angabe „Verfügbarmaintenance_work_mem“ (oder) nicht ausreicht, um den Index zu verarbeiten. autovacuum_work_mem In PostgreSQL-Versionen 16 und früher erforderte ein Limit von 1 GB für die Speicherzuweisung zum Speichern toter Tupel IDs oft mehrere Durchläufe, insbesondere bei großen Indizes. PostgreSQL Version 17 behebt diese Einschränkung durch die Einführung eines dynamischen SpeicherzuweisungssystemsTidStore, das das Single-Allocation Array ersetzt. Dadurch wird die 1-GB-Beschränkung aufgehoben, die Speichereffizienz verbessert und die Wahrscheinlichkeit mehrerer Scans pro Index verringert.

Aber selbst in PostgreSQL 17 können für große Indizes immer noch mehrere Durchgänge erforderlich sein, wenn der verfügbare Speicher nicht ausreicht, um den gesamten Index auf einmal zu verarbeiten. Typischerweise neigen große Indizes dazu, mehr tote Tupel zu enthalten, was mehrere Durchläufe erfordert.

Erkennung langsamer Vakuumvorgänge

Die postgres_get_av_diag() Funktion kann erkennen, wenn der Vakuumbetrieb aufgrund unzureichenden Speichers langsam abläuft. Weitere Informationen zu dieser Funktion finden Sie unterInstallation von Autovakuum-Überwachungs- und Diagnosetools in RDS für PostgreSQL.

Die postgres_get_av_diag() Funktion gibt die folgenden Hinweise aus, wenn der verfügbare Speicher nicht ausreicht, um die Indexbereinigung in einem einzigen Durchgang abzuschließen.

rds_tools1.8

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory. 
        Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).

rds_tools1,9

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more 
        memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual 
        vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide.

Wenn die postgres_get_av_diag() Funktion einen langsamen Vakuumvorgang identifiziert, für den mehrere Indexscans erforderlich sind, weil er nicht ausreichtautovacuum_work_mem, wird die folgende Meldung generiert:

NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming. 
        For more information, see Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide.

Anleitung

Sie können die folgenden Problemumgehungen manuell anwenden, VACUUM FREEZE um das Einfrieren der Tabelle zu beschleunigen.

Erhöhen Sie den Speicher für das Staubsaugen

Wie von der postgres_get_av_diag() Funktion vorgeschlagen, ist es ratsam, den autovacuum_work_mem Parameter zu erhöhen, um möglichen Speicherbeschränkungen auf Instanzebene zu begegnen. Obwohl es autovacuum_work_mem sich um einen dynamischen Parameter handelt, ist es wichtig zu beachten, dass der Autovacuum-Daemon seine Worker neu starten muss, damit die neue Speichereinstellung wirksam wird. Um dies zu erreichen:

Dieser Ansatz stellt sicher, dass die angepasste Speicherzuweisung auf neue Autovacuum-Operationen angewendet wird.

Um unmittelbarere Ergebnisse zu erzielen, sollten Sie erwägen, einen VACUUM FREEZE Vorgang mit einer erhöhten maintenance_work_mem Einstellung innerhalb Ihrer Sitzung manuell durchzuführen:

SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;

Wenn Sie Amazon RDS verwenden und feststellen, dass Sie zusätzlichen Speicher benötigen, um höhere Werte für maintenance_work_mem oder zu unterstützenautovacuum_work_mem, sollten Sie ein Upgrade auf eine Instance-Klasse mit mehr Speicher in Betracht ziehen. Dadurch können die erforderlichen Ressourcen bereitgestellt werden, um sowohl die manuellen als auch die automatischen Vakuumvorgänge zu verbessern, was zu einer insgesamt verbesserten Vakuum- und Datenbankleistung führt.

Deaktivieren Sie INDEX_CLEANUP

Manuell VACUUM in PostgreSQL Version 12 und höher ermöglicht das Überspringen der Indexbereinigungsphase, während das Notfall-Autovacuum in PostgreSQL Version 14 und höher dies automatisch auf der Grundlage des Parameters erledigt. vacuum_failsafe_age

Weitere Hinweise zum Umgang mit großen Indizes finden Sie in der Dokumentation zu. Verwalten der automatischen Bereinigung mit großen Indizes

Paralleles Absaugen von Indizes

Ab PostgreSQL 13 können Indizes standardmäßig manuell parallel gesaugt und bereinigt werdenVACUUM, wobei jedem Index ein Vacuum Worker-Prozess zugewiesen wird. Damit PostgreSQL jedoch feststellen kann, ob eine Vakuumoperation für die parallel Ausführung in Frage kommt, müssen bestimmte Kriterien erfüllt sein:

Sie können die max_parallel_maintenance_workers Einstellung basierend auf der Anzahl der auf Ihrer Amazon RDS-Instance CPUs verfügbaren v und der Anzahl der Indizes in der Tabelle anpassen, um die Bearbeitungszeit für das Vacuuming zu optimieren.

Weitere Informationen finden Sie unter Parallele Vakuumierung in Amazon RDS for PostgreSQL und Amazon Aurora PostgreSQL.

Zu viele Tabellen oder Datenbanken zum Löschen

Wie in der Dokumentation The Autovacuum-Daemon von PostgreSQL erwähnt, arbeitet der Autovacuum-Daemon mit mehreren Prozessen. Dazu gehört auch ein persistenter Autovacuum-Launcher, der für das Starten von Autovacuum-Worker-Prozessen für jede Datenbank innerhalb des Systems verantwortlich ist. Der Launcher plant, dass diese Worker ungefähr alle autovacuum_naptime Sekunden pro Datenbank initiiert werden.

Bei 'N' Datenbanken beginnt ungefähr alle [autovacuum_naptime/N Sekunden] ein neuer Worker. Die Gesamtzahl der gleichzeitigen Mitarbeiter ist jedoch durch die autovacuum_max_workers Einstellung begrenzt. Wenn die Anzahl der Datenbanken oder Tabellen, die gelöscht werden müssen, diesen Grenzwert überschreitet, wird die nächste Datenbank oder Tabelle verarbeitet, sobald ein Worker verfügbar ist.

Wenn viele große Tabellen oder Datenbanken gleichzeitig gelöscht werden müssen, kann es sein, dass alle verfügbaren Autovakuum-Mitarbeiter für einen längeren Zeitraum ausgelastet sind, was die Wartung anderer Tabellen und Datenbanken verzögert. In Umgebungen mit hohen Transaktionsraten kann dieser Engpass schnell eskalieren und möglicherweise zu umfassenden Vakuumproblemen innerhalb Ihrer Amazon RDS-Instance führen.

Wenn eine große Anzahl von Tabellen oder Datenbanken postgres_get_av_diag() erkannt wird, gibt es die folgende Empfehlung:

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.

Anleitung

Erhöhen Sie autovacuum_max_workers

Um das Absaugen zu beschleunigen, empfehlen wir, den Parameter so anzupassen, dass mehr Mitarbeiter gleichzeitig mit dem Autovakuieren arbeiten können. autovacuum_max_workers Wenn weiterhin Leistungsengpässe bestehen, sollten Sie erwägen, Ihre Amazon RDS-Instance auf eine Klasse mit mehr v zu skalierenCPUs, wodurch die Parallelverarbeitungsmöglichkeiten weiter verbessert werden können.

Es läuft ein aggressives Vakuum (um eine Rundum-Operation zu verhindern)

Das Alter der Datenbank (MaximumUsedTransactionIDs) in PostgreSQL nimmt nur ab, wenn ein aggressives Vakuum (um Wraparound zu verhindern) erfolgreich abgeschlossen wird. Bis dieses Vakuum beendet ist, wird das Alter je nach Transaktionsrate weiter zunehmen.

Die postgres_get_av_diag() Funktion generiert FolgendesNOTICE, wenn sie ein aggressives Vakuum erkennt. Sie löst diesen Ausgang jedoch erst aus, wenn das Vakuum mindestens zwei Minuten lang aktiv war.

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.

Weitere Informationen zu aggressivem Vakuum finden Sie unter Wenn bereits ein aggressives Vakuum läuft.

Mit der folgenden Abfrage können Sie überprüfen, ob ein aggressives Vakuumieren im Gange ist:

SELECT
    a.xact_start AS start_time,
    v.datname "database",
    a.query,
    a.wait_event,
    v.pid,
    v.phase,
    v.relid::regclass,
    pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
    (
        SELECT
            string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS index_sizes,
    trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
    v.index_vacuum_count || '/' || (
        SELECT
            count(*)
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS step2_vacuum_indexes,
    trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
    age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
    pg_stat_activity a
    INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;

Sie können anhand der Abfragespalte in der Ausgabe feststellen, ob es sich um ein aggressives Vakuum handelt (um einen Rundum-Vorgang zu verhindern). Der Ausdruck „zur Verhinderung von Rundumbildung“ weist darauf hin, dass es sich um ein aggressives Vakuum handelt.

query                  | autovacuum: VACUUM public.t3 (to prevent wraparound)

Nehmen wir zum Beispiel an, Sie haben einen Blocker im Transaktionsalter von 1 Milliarde und eine Tabelle, die ein aggressives Vakuum erfordert, um Wraparound im gleichen Transaktionsalter zu verhindern. Zusätzlich gibt es einen weiteren Blocker im Transaktionsalter von 750 Millionen. Nach der Aufhebung des Blockers im Transaktionsalter von 1 Milliarde wird das Transaktionsalter nicht sofort auf 750 Millionen sinken. Es wird so lange hoch bleiben, bis der Tisch, der das aggressive Vakuum benötigt, oder eine Transaktion mit einem Alter von über 750 Millionen abgeschlossen ist. Während dieses Zeitraums wird das Transaktionsalter Ihres PostgreSQL-Clusters weiter steigen. Sobald der Vakuumvorgang abgeschlossen ist, wird das Transaktionsalter auf 750 Millionen sinken, aber es wird wieder steigen, bis das weitere Vakuumieren abgeschlossen ist. Dieser Zyklus wird so lange fortgesetzt, wie diese Bedingungen bestehen, bis das Transaktionsalter irgendwann auf das für Ihre Amazon RDS-Instance konfigurierte Niveau fällt, das von autovacuum_freeze_max_age angegeben ist.