Wie behebe ich Probleme mit hoher oder vollständiger Festplattenauslastung bei Amazon Redshift?

Lösung

Um Probleme mit hoher Auslastung oder Festplattenauslastung bei Amazon Redshift zu beheben, befolge diese Schritte zur Fehlerbehebung.

Verteilungs- und Sortierschlüssel

Überprüfe die Auswahl des Verteilungsstils, des Verteilungsschlüssels und des Sortierschlüssels der Tabelle. Tabellen mit ungleicher Verteilung können zu einem vollen Festplattenknoten führen. Wenn du Tabellen mit ungleichen Verteilungsstilen hast, ändere den Verteilungsstil in eine gleichmäßigere Verteilung. Die Verteilung und das Ungleichgewicht der Zeilendaten können sich auf die Speicherverteilug und den Zwischenzeilensatz auswirken, wenn eine Abfrage ausgeführt wird.

Führe die folgende Abfrage aus, um die Kardinalität des Verteilungsschlüssels abzurufen:

SELECT <distkey column>, COUNT(*)
 FROM <schema name>.<table with distribution skew>
 GROUP BY <distkey column>
 HAVING COUNT(*) > 1
 ORDER BY 2 DESC;

Hinweis: Ersetze distkey column, schema name und table with distribution skew durch deine Tabellenvariablen.

Um einen Sortierschritt zu vermeiden, verwende SORT KEY-Spalten in deiner ORDER BY-Klausel. Ein Sortierschritt kann zu viel Arbeitsspeicher beanspruchen und zu einem Speicherüberlauf auf die Festplatte führen. Weitere Informationen findest du unter Sortierschlüssel.

Wähle im gefilterten Ergebnissatz eine Spalte mit hoher Kardinalität aus, um deren Datenverteilung anzuzeigen. Weitere Informationen findest du unter Den besten Verteilungsstil auswählen.

Bearbeitung von Abfragen

Überprüfe den zugewiesenen Abfragespeicher. Zwischenabfrageergebnisse können in temporären Blöcken gespeichert werden, wenn Abfragen verarbeitet werden. Wenn nicht genügend freier Speicher zur Verfügung steht, führen die Tabellen zu einem Speicherüberlauf auf die Festplatte. Zwischenergebnissätze werden nicht komprimiert, was sich auf den verfügbaren Speicherplatz auswirkt. Weitere Informationen findest du unter Für die Abfrage unzureichend zugewiesener Speicher.

Amazon Redshift verwendet standardmäßig eine Tabellenstruktur mit gleichmäßiger Verteilung und ohne Spaltencodierung für temporäre Tabellen. Wenn du die SELECT...INTO-Syntax verwendest, verwende eine CREATE-Anweisung. Weitere Informationen findest du unter Tipp Nr. 6 in Die 10 wichtigsten Techniken zur Leistungsoptimierung bei Amazon Redshift.

Wenn deiner Abfrage nicht genügend Speicher zugewiesen ist, siehst du möglicherweise einen Schritt in SVL_QUERY_SUMMARY, in dem is_diskbased den Wert true anzeigt. Die folgende Abfrage identifiziert die 20 häufigsten Abfragen mit Speicherüberlauf auf die Festplatte für einen bestimmten Zeitraum:

SELECT q.userid, q.query, q.starttime, q.endtime, m.query_temp_blocks_to_disk, btrim(querytxt)  
 FROM stl_query q JOIN SVL_QUERY_METRICS_SUMMARY m ON m.query = q.query
 WHERE m.query_temp_blocks_to_disk > 0
   AND starttime BETWEEN '2025-01-01 00:00:00' AND '2025-01-02 00:00:00'
 ORDER BY m.query_temp_blocks_to_disk DESC
 LIMIT 20;

Um dieses Problem zu beheben, erhöhe die Anzahl der Abfrageslots, um der Abfrage mehr Speicher zuzuweisen. 

Wenn du einen plötzlichen Anstieg der Auslastung feststellst, führe die folgende Abfrage aus, um die 20 häufigsten Abfragen mit Speicherüberlauf auf die Festplatte zu ermitteln:

SELECT a.userid, a.query, a.blocks_to_disk, trim(b.text) as text
 FROM stv_query_metrics a, stv_inflight b
 WHERE a.query = b.query
   AND a.segment = -1
   AND a.step_type = -1
   AND a.max_blocks_to_disk > 0
 ORDER BY 3 DESC
 LIMIT 20;

Frage in der Ausgabe den Spaltenwert blocks_to_disk ab, um Speicherüberläufe auf die Festplatte zu identifizieren. Beende Abfragen, die zu übermäßig viel Speicherüberlauf auf die Festplatte führen, und weise den Abfragen dann mehr Speicher zu, bevor du sie erneut ausführst.

Du kannst auch Regeln zur WLM-Abfrageüberwachung verwenden, um hohen Verarbeitungslasten entgegenzuwirken und E/A-intensive Abfragen zu identifizieren.

Tabellen mit VARCHAR(MAX)-Spalten

Überprüfe die Spalten VARCHAR oder CHARACTER VARIING auf nachstehende Leerzeichen, die möglicherweise weggelassen werden, wenn Daten auf der Festplatte gespeichert werden. Wenn Abfragen verarbeitet werden, können nachfolgende Leerzeichen die maximal mögliche Länge im Speicher belegen. Der Höchstwert für VARCHAR und CHARACTER VARYING beträgt 65535 Byte. Es hat sich bewährt, die kleinstmögliche Spaltengröße zu verwenden.

Führe die folgende Abfrage aus, um eine Liste von Tabellen mit maximalen Spaltenbreiten zu generieren:

SELECT database, schema || '.' || "table" AS "table", max_varchar
 FROM svv_table_info
 WHERE max_varchar > 150 ORDER BY 2;

Führe die folgende Abfrage aus, um die tatsächlichen Breiten der breiten VARCHAR-Tabellenspalten zu ermitteln und anzuzeigen:

SELECT max(octet_length (rtrim(column_name))) FROM table_name;

Vergewissere dich in der Ausgabe dieser Abfrage, dass die Länge deinem Anwendungsfall entspricht. Wenn die Spalten die maximale Länge haben und deine Anforderungen übertreffen, passe die Länge an die benötigte Mindestgröße an.

Weitere Informationen findest du unter Bewährte Methoden für das Entwerfen von Tabellen in Amazon Redshift.

Hohe Spaltenkomprimierung

Um alle Spalten bis auf den Sortierschlüssel zu codieren, verwende ANALYZE COMPRESSION oder die automatische Tabellenoptimierung. Es hat sich bewährt, die Spaltencodierung zu verwenden.

Wartungsvorgänge

Achte darauf, die Datenbanktabellen in der Amazon-Redshift-Datenbank regelmäßig zu analysieren und zu bereinigen. Identifiziere alle Abfragen, die für Tabellen ausgeführt werden, für die Statistiken fehlen. Verhindere dann, dass Abfragen für Tabellen ausgeführt werden, für die Statistiken fehlen, damit Amazon Redshift keine unnötigen Tabellenzeilen scannt.

Hinweis: Wartungsvorgänge wie VACUUM und DEEP COPY verwenden temporären Speicherplatz für ihre Sortiervorgänge und können zu einem Anstieg der Festplattenauslastung führen.

Die folgende Abfrage identifiziert beispielsweise veraltete Statistiken in Amazon Redshift:

SELECT table_id, database, schema, "table", stats_off, size
 FROM svv_table_info
 WHERE stats_off > 10
 ORDER BY size DESC;

Verwende zusätzlich den Befehl ANALYZE, um Tabellenstatistiken anzuzeigen und zu analysieren.

Kartesische Produkte mit Kreuzverknüpfungen

Verwende den EXPLAIN-Plan der Abfrage, um nach Abfragen mit kartesischen Produkten zu suchen. Kartesische Produkte sind Kreuzverknüpfungen, die nichts miteinander zu tun haben und zu einer erhöhten Anzahl von Blöcken führen können. Diese Kreuzverknüpfungen können zu einer höheren Speichernutzung und mehr Tabellen führen, die auf die Festplatte überlaufen. Wenn Kreuzverknüpfungen keine gemeinsame JOIN-Bedingung haben, erzeugen die Verknüpfungen ein kartesisches Produkt zweier Tabellen. Jede Zeile einer Tabelle wird mit jeder Zeile der anderen Tabelle verknüpft.

Kreuzverknüpfungen können auch als verschachtelte Schleifenverknüpfungen ausgeführt werden und lange Verarbeitungszeiten verursachen. Verschachtelte Schleifenverknüpfungen führen zu Spitzenwerten bei der gesamten Festplattennutzung. Weitere Informationen findest du unter Identifizieren von Abfragen mit verschachtelten Schleifen.

Minimale Tabellengröße

Einzelne Tabellen können in verschiedenen Clustern unterschiedliche Größen haben. Die minimale Tabellengröße wird von der Anzahl der Spalten bestimmt und davon, ob die Tabelle einen SORTKEY und die Anzahl der aufgefüllten Slices enthält. Wenn du kürzlich die Größe eines Amazon-Redshift-Clusters geändert hast, siehst du möglicherweise eine Änderung in deinem gesamten Festplattenspeicher, die durch die Änderung der Slices verursacht wird. Amazon Redshift zählt auch die Tabellensegmente, die von jeder Tabelle verwendet werden. Weitere Informationen findest du unter Warum verbraucht eine Tabelle in einem Amazon-Redshift-Cluster mehr oder weniger Festplattenspeicher als erwartet?

Tombstone-Blöcke

Tombstone-Blöcke werden generiert, wenn eine WRITE-Transaktion in eine Amazon-Redshift-Tabelle stattfindet und gleichzeitig ein Lesevorgang erfolgt. Amazon Redshift speichert die Blöcke vor dem Schreibvorgang, um einen gleichzeitigen Lesevorgang konsistent zu halten. Du kannst Amazon-Redshift-Blöcke nicht ändern. Jede Aktion Einfügen, Aktualisieren oder Löschen erstellt eine neue Gruppe von Blöcken und markiert die alten Blöcke als veraltet.

Manchmal werden Tombstones in der Commit-Phase aufgrund von Tabellentransaktionen mit langer Laufzeit nicht gelöscht. Das Löschen von Tombstones kann auch fehlschlagen, wenn zu viele ETL-Ladevorgänge gleichzeitig ausgeführt werden. Da Amazon Redshift die Datenbank ab dem Zeitpunkt überwacht, an dem die Transaktion beginnt, behält jede Tabelle, die in die Datenbank geschrieben wird, auch die Tombstone-Blöcke bei. Wenn Tabellentransaktionen mit langer Laufzeit regelmäßig und über mehrere Ladevorgänge hinweg stattfinden, können sich so viele Tombstones ansammeln, dass der Fehler „Disk Full“ angezeigt wird.

Wenn Abfragen mit langer Laufzeit aktiv sind, führe den Befehl commit aus, um die Abfragen zu beenden, und gib alle nachfolgenden Blöcke frei:

begin;
create table a (id int);
insert into a values(1);
commit;
drop table a;

Führe dann die folgende Abfrage aus, um Tombstone-Blöcke zu bestätigen:

SELECT trim(name) as tablename, count(case when tombstone > 0 then 1 else null end) as tombstones
 FROM svv_diskusage
 GROUP BY 1
 HAVING count(case when tombstone > 0 then 1 else null end) > 0
 ORDER BY 2 DESC;

Eine große Datei kopieren

Während eines COPY-Vorgangs wird möglicherweise der Fehler Disk Full angezeigt, auch wenn genügend Speicherplatz verfügbar ist. Dieser Fehler tritt auf, wenn der Sortiervorgang auf die Festplatte übertragen wird und temporäre Blöcke erstellt werden.

Wenn die Fehlermeldung „Disk Full“ angezeigt wird, überprüfe die Tabelle STL_DISK_FULL_DIAG. Prüfe die temporären Blöcke und welche Abfrage-ID den Fehler verursacht hat:

SELECT
  '2000-01-01'::timestamp + (currenttime/1000000.0)* interval '1 second' as currenttime,
  node_num,
  query_id,
  temp_blocks
 FROM stl_disk_full_diag;

Weitere Informationen findest du unter Bewährte Methoden für das Laden von Daten in Amazon Redshift.

Datashare-Abfrageblöcke auf Verbraucher-Clustern

Wenn eine Datashare-Abfrage auf dem Verbraucher-Cluster ausgeführt wird, werden die der Abfrage zugeordneten Datenblöcke in den PercentageDiskSpaceUsed-Metriken gezählt. Diese Datenblöcke werden aufgrund eines Cluster-Neustarts und anderer Faktoren aus den PercentageDiskSpaceUsed-Metriken entfernt. Für dieses erwartete Verhalten sind keine weiteren Aktionen erforderlich.

Speicherplatz überprüfen

Überprüfe den Prozentsatz des Festplattenspeichers auf der Registerkarte Leistung auf der Amazon-Redshift-Konsole.

Ähnliche Informationen

Leistung von Amazon Redshift