Wie kann ich lokale Speicherprobleme in Aurora PostgreSQL-kompatiblen Instances beheben?

Kurzbeschreibung

DB-Instances, die sich in Amazon Aurora-Clustern befinden, verfügen über zwei Speichertypen:

• Für persistente Daten verwendeter Speicher (gemeinsam genutztes Cluster-Volume). Weitere Informationen finden Sie unter Was das Cluster-Volume enthält.
• Lokaler Speicher für jede Aurora-Instance im Cluster, basierend auf der Instance-Klasse. Diese Speichergröße ist an die Instance-Klasse gebunden und kann nur geändert werden, indem auf eine größere DB-Instance-Klasse gewechselt wird. Aurora PostgreSQL-Coompatible verwendet lokalen Speicher zum Speichern von Fehlerprotokollen und temporären Dateien. Weitere Informationen finden Sie unter Temporäre Speicherlimits für Aurora PostgreSQL.

Behebung

Sie können den lokalen Speicherplatz überwachen, der der Aurora-DB-Instance oder dem Knoten zugeordnet ist, indem Sie die Amazon CloudWatch-Metrik für FreeLocalStorage verwenden. Diese Metrik gibt an, wie viel Speicherplatz jeder DB-Instance für temporäre Tabellen und Protokolle zur Verfügung steht. Weitere Informationen finden Sie unter Amazon Aurora-Metriken mit Amazon CloudWatch überwachen.

Wenn Ihr lokaler Aurora-Speicher voll ist, gehen Sie je nach angezeigtem Fehler wie folgt vor.

Lokaler Speicherplatz wird von temporären Tabellen oder Dateien verwendet

„ERROR: could not write block XXXXXXXX of temporary file: No space left on device."

Dieser Fehler tritt auf, wenn der temporäre Speicher auf der DB-Instance erschöpft ist. Dies kann eine Reihe von Ursachen haben, unter anderem Operationen, die:

• große Tabellen ändern;
• Indizes zu großen Tabellen hinzufügen;
• umfangreiche SELECT-Abfragen mit komplexen VERBINDET-, GRUPPIEREN NACH- oder ANORDNEN NACH-Klauseln durchführen.

Verwenden Sie diese Methoden, um die Größe temporärer Tabellen und Dateien zu überprüfen:

1.    Aktivieren Sie für temporäre Dateien den Parameter log\ _temp\ _files auf der DB-Instance von Aurora PostgreSQL-Compatible. Dieser Parameter protokolliert die Verwendung temporärer Dateien, die größer als die angegebene Anzahl von Kilobyte sind. Nachdem dieser Parameter aktiviert wurde, wird für jede temporäre Datei ein Protokolleintrag erstellt, wenn die Datei gelöscht wird. Ein Wert von 0 protokolliert alle temporären Dateiinformationen. Ein positiver Wert protokolliert nur die Dateien, die größer oder gleich der angegebenen Anzahl von Kilobyte sind. Der Standardwert ist -1, wodurch die temporäre Dateiprotokollierung deaktiviert wird. Verwenden Sie diesen Parameter, um die Details der temporären Datei zu identifizieren, und verknüpfen Sie diese temporären Dateien mit der FreeLocalStorage-Metrik.

Hinweis: Das Aktivieren des Parameters og_temp_files kann zu übermäßiger Protokollierung auf der DB-Instance von Aurora PostgreSQL-Compatible führen. Aus diesem Grund empfiehlt es sich, die Größe der Protokolldateien von Aurora PostgreSQL-Compatible zu überprüfen, bevor Sie log_temp_files aktivieren. Wenn Protokolldateien den maximalen Speicherplatz für den lokalen Speicher beanspruchen, reduzieren Sie den Wert von rds.log_retention, um Speicherplatz zurückzugewinnen. Der Standardwert für rds.log_retention ist drei Tage.

Sie können temporäre Dateien ebenfalls überprüfen, indem Sie das Delta nachfolgender Ausführungen dieses Befehls verwenden:

maxiops=> select datname, temp_files , pg_size_pretty(temp_bytes) as temp_file_size  FROM   pg_stat_database order by temp_bytes desc;

Hinweis: In der Spalte temp_files werden alle temporären Dateien gezählt, unabhängig davon, wann Sie die temporäre Datei erstellt haben (z. B. durch Sortieren oder Hashing). Die Spalten **temp_files ** und temp_bytes in der Ansicht pg_stat_database sammeln Statistiken für den akkumulierten Wert. Dieser Wert kann mit der Funktion pg_stat_reset() oder durch einen Neustart der DB-Instance zurückgesetzt werden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation für Zusätzliche Statistikfunktionen.

Wenn Sie Aurora PostgreSQL-Compatible 10 oder höher verwenden, können Sie mithilfe von Performance Insights temp_bytes und temp_files überwachen. Dies gilt auch für Amazon Relational Database Service (Amazon RDS) für PostgreSQL. Performance Insights bietet zusätzlich zu Wait-Ereignissen native Zähler für die internen Metriken Ihrer DB-Engine. Weitere Informationen finden Sie unter Native Zähler für Amazon RDS for PostgreSQL.

Sie können auch maintenance_work_mem und work_memerhöhen, um den Prozessen, die den Vorgang ausführen, mehr Speicher zuzuweisen. Dadurch wird mehr Arbeitsspeicher für den Vorgang verwendet, wodurch weniger temporärer Festplattenspeicher benötigt werden kann. Weitere Informationen zu diesen Parametern finden Sie in der PostgreSQL-Dokumentation für maintenance_work_mem und work\ _mem. Es hat sich bewährt, die Werte für maintenance_work_mem und work_mem auf Abfrage- oder Sitzungsebene festzulegen, um zu vermeiden, dass der Arbeitsspeicher knapp wird. Weitere Informationen finden Sie in der Amazon Aurora PostgreSQL-Referenz.

2.    Führen Sie für temporäre Tabellen eine Abfrage wie folgt aus:

maxiops=> SELECT
n.nspname as SchemaName
,c.relname as RelationName
,CASE c.relkind
WHEN 'r' THEN 'table'
WHEN 'v' THEN 'view'
WHEN 'i' THEN 'index'
WHEN 'S' THEN 'sequence'
WHEN 's' THEN 'special'
END as RelationType
,pg_catalog.pg_get_userbyid(c.relowner) as RelationOwner
,pg_size_pretty(pg_relation_size(n.nspname ||'.'|| c.relname)) as RelationSize
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n
    ON n.oid = c.relnamespace
WHERE  c.relkind IN ('r','s')
AND  (n.nspname !~ '^pg_toast' and nspname like 'pg_temp%')
ORDER BY pg_relation_size(n.nspname ||'.'|| c.relname) DESC;

Es hat sich bewährt, Ihre Anwendung genau zu beobachten und zu sehen, welche Transaktionen temporäre Tabellen erstellen. Auf diese Weise können Sie die Nutzung der verfügbaren lokalen Speicherkapazität verwalten. Sie können auch auf eine höhere Instance-Klasse für Ihre Aurora-Instance wechseln, sodass die Instance über mehr verfügbaren lokalen Speicher verfügt.

Lokaler, von Protokolldateien verwendeter Speicher

Übermäßige Protokollierung kann auch dazu führen, dass Ihrer DB-Instance der lokale Speicher ausgeht. Dies sind einige Beispiele für Protokollierungsparameter, die den lokalen Speicherplatz beanspruchen können. Der Verbrauch kann entweder darauf zurückzuführen sein, dass das Fehlerprotokoll übermäßig protokolliert wird oder es über einen längeren Zeitraum aufbewahrt wird.

rds.log_retention_period
auto_explain.log_min_duration
log_connections
log_disconnections
log_lock_waits
log_min_duration_statement
log_statement
log_statement_stats

Um herauszufinden, welcher Parameter zur übermäßigen Protokollierung führt, analysieren Sie die PostgreSQL-Protokolle, um die größten Protokolle zu finden. Identifizieren Sie anschließend, welcher Parameter für die meisten Einträge in diesen Protokollen verantwortlich ist. Anschließend können Sie den Parameter ändern, der zur übermäßigen Protokollierung führt.

Wenn Sie wiederholt eine Abfrage ausführen, die fehlschlägt, protokolliert PostgreSQL die Fehler standardmäßig im PostgreSQL-Fehlerprotokoll. Überprüfen Sie die protokollierten Fehler und korrigieren Sie anschließend die fehlgeschlagene Abfrage, um zu verhindern, dass die Protokolle zu viel Speicherplatz beanspruchen. Sie können auch den Standardwert für rds.log_retention (drei Tage) reduzieren, um Speicherplatz zurückzugewinnen, der von den Fehlerprotokollen belegt wird.

Wenn eine übermäßige Protokollierung erforderlich ist und Sie aufgrund von Protokolldateien den verfügbaren lokalen Speicher drosseln, sollten Sie erwägen, auf eine höhere Instance-Klasse zu wechseln. Das bedeutet, dass Ihre Aurora-DB-Instance über mehr verfügbaren lokalen Speicher verfügt.

---

Verwandte Informationen

Bewährte Methoden mit Amazon Aurora PostgreSQL