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 z. B. gemeinsam genutztes Cluster-Volume, und lokaler Speicher für jede DB-Instance.

Die lokale Speichergröße ist an die Instance-Klasse gebunden. 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 an, wie viel Speicherplatz für die temporären Tabellen in jeder DB-Instance verfügbar ist.

Lösung

Es ist kein lokaler Speicherplatz mehr vorhanden

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 zu großen Tabellen
• Ausführung umfangreicher SELECT-Abfragen mit komplexen JOINs-, GROUP BY- oder ORDER BY-Klauseln

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 DB-Instance von Aurora PostgreSQL-Compatible. 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 den nachfolgenden Ausführungen geändert hat.

In der Spalte temp_files werden alle temporären Dateien gezählt, unabhängig davon, wann du die temporäre Datei erstellt hast. Die Spalten temp_files und temp_bytes in der Ansicht pg_stat_database erfassen Statistiken für den akkumulierten Wert. 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 höher verwendest, kannst du temp_bytes and 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 Speicher zuzuweisen, kannst du die Parameter maintenance_work_mem und work_mem erhöhen. 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 hat sich bewährt, 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 (gilt nur für Instance-Klassentypen mit hoher Leistung), die lokalen Speicher verwenden

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 entweder auf eine übermäßige Protokollierung oder auf eine lange Beibehaltung des Fehlerprotokolls zurückzuführen sein.

Um den Parameter zu identifizieren, der die übermäßige Protokollierung verursacht, analysiere die PostgreSQL-Protokolle, um die größten Protokolle zu finden. Identifiziere dann den Parameter, der für den Großteil der Einträge in diesen Protokollen verantwortlich ist. Du kannst dann den Parameter ändern, der die übermäßige Protokollierung verursacht.

Beispielausgabe:

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 zu verhindern, dass die Fehlerprotokolle zu viel Speicherplatz belegen, überprüfe die Fehler im Protokoll und korrigiere dann die fehlgeschlagene Abfrage. Du kannst auch den 3-Tage-Standardwert für rds.log_retention reduzieren, um den Speicherplatz zurückzugewinnen, den die Fehlerprotokolle belegen.

Es hast sich bewährt, die Instance-Klasse in eine größere Instance-Klasse zu ändern, um eine übermäßige Protokollierung zu vermeiden. Auf diese Weise verfügt die Aurora-DB-Instance über mehr verfügbaren lokalen Speicher.

Ähnliche Informationen

Bewährte Methoden mit Amazon Aurora PostgreSQL