Warum überschreitet meine Amazon Redshift-Abfrage immer wieder das von mir festgelegte WLM-Timeout?

Kurzbeschreibung

Ein WLM-Timeout gilt nur für Abfragen während der Abfrageausführungsphase. Wenn WLM eine Abfrage nicht wie erwartet beendet, liegt das normalerweise daran, dass die Abfrage in anderen Phasen als der Ausführungsphase Zeit verbracht hat. Beispielsweise kann die Abfrage darauf warten, analysiert oder neu geschrieben zu werden, auf eine Sperre warten, auf einen Platz in der WLM-Warteschlange warten, die Rücklaufphase erreichen oder zu einer anderen Warteschlange springen.

Lösung

Bei der Abfrage von STV_RECENTS ist Startzeit die Uhrzeit, zu der die Abfrage in den Cluster eingetreten ist, nicht die Uhrzeit, zu der die Ausführung der Abfrage beginnt. Wenn sich die Abfrage in STV_RECENTS im Status Läuft befindet, ist sie im System live. Die Abfrage verwendet jedoch keine Rechenknotenressourcen, bis sie den Status STV_INFLIGHT erreicht hat. Weitere Informationen zur Abfrageplanung finden Sie unter Arbeitsablauf für die Abfrageplanung und -ausführung.

Um den Status einer laufenden Abfrage anzuzeigen, fragen Sie STV_INFLIGHT statt STV_RECENTS ab:

select * from STV_INFLIGHT where query = your_query_id;

Verwenden Sie diese Abfrage, um weitere Informationen zu Abfragephasen zu erhalten:

select * from SVL_QUERY_REPORT where query = your_query_id ORDER BY segment, step, slice;

Verwenden Sie die STV_EXEC_STATE-Tabelle für den aktuellen Status aller Abfragen, die aktiv auf Rechenknoten ausgeführt werden:

select * from STV_EXEC_STATE where query = your_query_id ORDER BY segment, step, slice;

Im Folgenden sind einige häufige Gründe aufgeführt, warum eine Abfrage möglicherweise länger als das WLM-Timeout ausgeführt wird:

Die Anfrage befindet sich in der „Rückgabe“ -Phase

Es gibt zwei „Zurück“ -Schritte. Überprüfen Sie STV_EXEC_STATE, um zu sehen, ob die Abfrage in eine dieser Rückgabephasen eingetreten ist:

• Die Rückkehr von den Rechenknoten zum Leader-Knoten
• Die Rückkehr vom Leader-Knoten zum Kunden

Ein Rollback ist im Gange

Wenn bei einem DML-Vorgang (Data Manipulation Language) ein Fehler auftritt und ein Rollback durchgeführt wird, scheint der Vorgang nicht beendet zu sein, da er bereits im Rollback ist. Sie können Rollbacks anzeigen, indem Sie STV_EXEC_STATE abfragen. Weitere Informationen finden Sie in STL_UNDONE.

Die Abfrage verbringt Zeit in der Warteschlange, bevor sie ausgeführt wird

Fragen Sie STV_WLM_QUERY_STATE ab, um die Wartezeit zu sehen:

select * from STV_WLM_QUERY_STATE where query = your_query_id;

Die Anfrage wartet auf einem Schloss

Wenn die Abfrage in STV_RECENTS sichtbar ist, aber nicht in STV_WLM_QUERY_STATE, wartet die Abfrage möglicherweise auf eine Sperre und ist nicht in die Warteschlange eingetreten. Weitere Informationen zur Überprüfung auf Sperren finden Sie unter Wie kann ich Sperren in Amazon Redshift erkennen und aufheben?

Eine Abfrage wurde in eine andere Warteschlange verschoben

Wenn eine Leseabfrage das Timeout-Limit für ihre aktuelle WLM-Warteschlange erreicht oder wenn es eine Regel zur Abfrageüberwachung gibt, die eine Hop-Aktion festlegt, wird die Abfrage an die nächste WLM-Warteschlange weitergeleitet. Um zu überprüfen, ob die Abfrage in die nächste Warteschlange gesprungen ist, gehen Sie wie folgt vor:

• Während die Abfrage läuft: Abfrage STV_WLM_QUERY_STATE
• Nachdem die Abfrage ausgeführt wurde: Abfrage STL_WLM_QUERY

Um zu verhindern, dass Abfragen in eine andere Warteschlange springen, konfigurieren Sie die Regeln zur Überwachung der WLM-Warteschlange oder der WLM-Abfrage. Weitere Informationen zu Query Hopping finden Sie unter WLM-Queue-Hopping.

Ein Netzwerk- oder Firewallproblem

Wenn ein Amazon Redshift-Server Probleme bei der Kommunikation mit Ihrem Client hat, bleibt der Server möglicherweise im Status „Zurück zum Client“ hängen. Suchen Sie nach Konflikten mit Netzwerkkomponenten, wie z. B. lokalen Firewalleinstellungen für eingehenden Datenverkehr, Sicherheitsgruppenregeln für ausgehenden Datenverkehr oder Netzwerk-ACL-Regeln (Network Access Control List) für ausgehenden Datenverkehr. Weitere Informationen finden Sie unter Herstellen einer Verbindung von außerhalb von Amazon EC2—Firewall-Timeout-Problem.

Ein Problem mit dem Cluster

Probleme im Cluster selbst, wie z. B. Hardwareprobleme, können dazu führen, dass die Abfrage einfriert. In diesem Fall befindet sich der Cluster im Status „Hardwarefehler“. Um einen Cluster mit einem Knoten wiederherzustellen, stellen Sie einen Snapshot wieder her. In Clustern mit mehreren Knoten werden ausgefallene Knoten automatisch ersetzt.

---

Verwandte Informationen

Optimieren der Abfrageleistung

Analysieren und Verbessern von Abfragen