Wie behebe ich lokale Speicherprobleme in meinen DB-Instances von Aurora PostgreSQL-Compatible?

Kurzbeschreibung

Es gibt zwei Speichertypen für Amazon Aurora: Speicher für persistente Daten wie das geteilte Cluster-Volume und lokaler Speicher für jede DB-Instance.

Die Instance-Klasse bestimmt die lokale Speichergröße. Du kannst die Speichergröße nur ändern, wenn du zu einer größeren DB-Instance-Klasse wechselst. Aurora PostgreSQL-Compatible verwendet lokalen Speicher zum Speichern von Fehlerprotokollen und temporären Dateien. Bei Instance-Typen, die nicht der T-Klasse angehören, schreibt das System Protokolle auf ein dediziertes Volume, welches das System automatisch bereinigt.

Verwende die Amazon-CloudWatch-Metrik FreeLocalStorage, um den lokalen Speicherplatz zu überwachen, welcher der Aurora-DB-Instance oder dem Aurora-DB-Knoten zugeordnet ist. Diese Metrik gibt die Menge an lokalem Speicher an, die in jeder DB-Instance verfügbar ist.

Lösung

Beheben des Fehlers „No space left on device“

Du erhältst die Fehlermeldung „could not write block ###### of temporary file: No space left on device“, wenn kein temporärer Speicher mehr vorhanden ist. Dieser Fehler kann bei den folgenden Vorgängen auftreten:

• Änderung großer Tabellen
• Hinzufügen von Indizes in großen Tabellen oder Durchführen eines REINDEX
• Ausführen von großen SELECT-Abfragen mit komplexen JOINs, GROUP BY- oder ORDER BY-Klauseln
• Ausführen von VACUUM FULL oder pg_repack

Die Größe der temporären Datei überprüfen

Um die Details der temporären Datei zu identifizieren, aktiviere den Parameter log_temp_files in der Aurora PostgreSQL-Compatible DB-Instance. Vergleiche dann die temporären Dateien mit der FreeLocalStorage-Metrik.

Der Parameter log_temp_files protokolliert jede temporäre Datei, die größer als die Anzahl der angegebenen Kilobyte ist. Ein Wert von 0 protokolliert alle temporären Datei-Informationen. 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. Wenn du den Parameter log_temp_files aktivierst, kann dies zu übermäßiger Protokollierung auf der DB-Instance von Aurora PostgreSQL-Compatible führen.

Es empfiehlt sich, die Größe der Aurora-PostgreSQL-Compatible-Protokolldateien zu überprüfen, bevor du log_temp_files aktivierst. Wenn Protokolldateien den maximalen Speicherplatz für den lokalen Speicher beanspruchen, reduziere den Wert von rds.log_retention, um Speicherplatz zurückzugewinnen. Der Standardwert für rds.log_retention ist 3 Tage.

Führe den folgenden Befehl mehrmals aus, um die Größe der temporären Datei zu überprüfen:

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

Hinweis: Verwende die Ausgabe, die sich nach nachfolgenden Ausführungen geändert hat.

Die Spalten temp_files und temp_bytes in der Ansicht pg_stat_database erfassen Statistiken für den akkumulierten Wert aller temporären Dateien, unabhängig davon, wann du sie erstellt hast. Um den Wert zurückzusetzen, verwende die Funktion pg_stat_reset() oder starte die DB-Instance neu. Weitere Informationen findest du unter Additional statistics functions (Zusätzliche Statistikfunktionen) auf der PostgreSQL-Website.

Wenn du Aurora PostgreSQL-Compatible 10 oder neuer verwendest, kannst du temp_bytes und temp_files mit Performance Insights überwachen. Performance Insights bietet native Zähler für die internen Metriken und Warteereignisse deiner DB-Engine. Du kannst auch Performance Insights aktivieren und Database Insights verwenden, um die Datenbankprotokolle zu überwachen.

Um den Prozessen, die den Vorgang ausführen, mehr Arbeitsspeicher zuzuweisen, erhöhe die Parameter maintenance_work_mem und work_mem. Diese Methode verwendet mehr Arbeitsspeicher für den Vorgang und weniger temporären Festplattenspeicher. Weitere Informationen zu diesen Parametern findest du unter maintenance_work_mem und work_mem auf der PostgreSQL-Website.

Es empfiehlt sich, die Werte für maintenance_work_mem und work_mem auf Abfrage- oder Sitzungsebene festzulegen. Dann geht den DB-Instances nicht der Arbeitsspeicher aus. Weitere Informationen findest du in der Amazon-Aurora-PostgreSQL-Referenz.

Die temporäre Tabellengröße überprüfen

Führe die folgende Abfrage 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, die Anwendung genau zu überwachen und die Transaktionen zu verfolgen, die temporäre Tabellen erstellen. Anschließend kannst du die Nutzung der verfügbaren lokalen Speicherkapazität verwalten. Du kannst auch die Instance-Klasse für die Aurora-DB-Instance ändern, sodass der DB-Instance mehr lokalen Speicher zur Verfügung steht.

Protokolldateien auf Instance-Klassentypen mit burstfähiger Leistung überprüfen

Eine übermäßige Protokollierung kann dazu führen, dass der DB-Instance nur bei Instance-Klassentypen mit burstfähiger Leistung wie db.t2, db.t3 und db.t4g der lokale Speicher ausgeht. Im Folgenden findest du Beispiele für Protokollierungsparameter, die lokalen Speicherplatz beanspruchen können. Der Verbrauch kann aufgrund übermäßiger Protokollierung auftreten oder weil das System das Fehlerprotokoll über einen langen Zeitraum aufbewahrt.

Um den Parameter zu identifizieren, der eine übermäßige Protokollierung verursacht, führe die folgenden Schritte aus:

1. Analysiere die PostgreSQL-Protokolle, um die größten Protokolle zu finden.
2. Identifiziere den Parameter, der für die meisten Einträge in diesen Protokollen verantwortlich ist.
3. Ändere den Parameter, der eine übermäßige Protokollierung verursacht.

Beispielparameter:

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

Wenn du wiederholt eine Abfrage ausführst, die mit einem Fehler fehlschlägt, protokolliert PostgreSQL die Fehler standardmäßig im PostgreSQL-Fehlerprotokoll. Um eine übermäßige Speichernutzung zu vermeiden, überprüfe die Fehler im Protokoll und korrigiere dann die fehlschlagende Abfrage. Alternativ kannst du den 3-tägigen Standardwert für rds.log_retention reduzieren, um den Speicherplatz zurückzugewinnen, den die Fehlerprotokolle beanspruchen.

Es hat sich bewährt, die Instance-Klasse in eine größere Instance-Klasse zu ändern, um eine übermäßige Protokollierung zu vermeiden. Dadurch steht deiner Aurora-DB-Instance mehr lokaler Speicher zur Verfügung.

Ähnliche Informationen

Bewährte Methoden mit Amazon Aurora PostgreSQL