Definition einer Abfrageüberwachungsregel Abfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestellt Abfrageüberwachungsmetriken für Amazon Redshift Serverless Vorlagen für Abfrageüberwachungsregeln Systemtabellen und Ansichten für Abfrageüberwachungsregeln

WLM-Abfrageüberwachungsregeln

In Amazon Redshift Workload Management (WLM) definieren Abfrageüberwachungsregeln auf Metriken basierende Leistungsgrenzen für WLM-Warteschlangen und geben an, welche Aktion durchgeführt werden soll, wenn eine Abfrage diese Grenzwerte überschreitet. So können Sie etwa für eine für kurze Abfragen dedizierte Warteschlange eine Regel erstellen, die Abfragen abbricht, die länger als 60 Sekunden ausgeführt werden. Zur Nachverfolgung schlecht gestalteter Abfragen können Sie eine weitere Regel verwenden, die Abfragen mit eingebetteten Schleifen protokolliert.

Sie definieren die Abfrageüberwachungsregeln im Rahmen Ihrer Workload Management (WLM)-Konfiguration. Sie können für jede Warteschlange bis zu 25 Regeln definieren. Dabei liegt die Grenze für alle Warteschlangen insgesamt bei 25 Regeln. Jede Regel enthält bis zu drei Bedingungen (oder Prädikate) sowie eine Aktion. Ein Prädikat besteht aus einer Metrik, einer Vergleichsbedingung (=, <, oder >) und einem Wert. Wenn alle Prädikate für eine Regel erfüllt sind, wird die Aktion der Regel ausgelöst. Mögliche Regelaktionen sind log, hop und abort, wie nachfolgend erläutert.

Die Regeln in einer Warteschlange gelten nur für Abfragen, die in dieser Warteschlange ausgeführt werden. Eine Regel ist unabhängig von anderen Regeln.

WLM evaluiert die Metriken alle 10 Sekunden. Amazon Redshift wendet Regeln zur Abfrageüberwachung auf untergeordneter Abfrageebene an, wenn Abfragen automatisch neu geschrieben werden. Wenn im selben Zeitraum mehr als eine Regel ausgelöst wird, wählt WLM die Regel mit der schwerwiegendsten Aktion aus. Wenn die Aktion für zwei Regeln denselben Schweregrad hat, führt WLM die Regeln in alphabetischer Reihenfolge aus, basierend auf dem Regelnamen. Wenn die Aktion hop oder abort ist, wird die Aktion protokolliert, und die Abfrage wird aus der Warteschlange entfernt. Wenn die Aktion log ist, wird die Abfrage weiterhin in der Warteschlange ausgeführt. WLM initiiert nur eine log-Aktion pro Abfrage und Regel. Wenn die Warteschlange weitere Regeln enthält, bleiben diese wirksam. Wenn die Aktion hop ist und die Abfrage zu einer anderen Warteschlange geleitet wird, gelten die Regeln für die neue Warteschlange. Weitere Informationen zur Abfrageüberwachung und zur Nachverfolgung von Aktionen, die bei bestimmten Abfragen ergriffen wurden, finden Sie in der Beispielsammlung unter Short Query Acceleration.

Wenn alle Prädikate einer Regel erfüllt sind, schreibt WLM eine Zeile in die Systemtabelle STL_WLM_RULE_ACTION. Zusätzlich zeichnet Amazon Redshift Abfragemetriken für aktuell ausgeführte Abfragen in auf STV_QUERY_METRICS. Metriken für abgeschlossene Abfragen werden in gespeichert STL_QUERY_METRICS.

Definition einer Abfrageüberwachungsregel

Sie erstellen Abfrageüberwachungsregeln als Teil Ihrer WLM-Konfiguration, die Sie im Rahmen der Parametergruppendefinition für Ihren Cluster definieren.

Sie können Regeln mithilfe von AWS Management Console oder programmgesteuert mithilfe von JSON erstellen.

Anmerkung

Wenn Sie Regeln auf programmatischen Wege erstellen, empfehlen wir nachdrücklich, die Konsole zu verwenden, um die JSON-Elemente zu erstellen, die Sie in der Parametergruppendefinition verwenden. Weitere Informationen finden Sie unter Erstellen oder Modifizieren einer Abfrageüberwachungsregel mit der Konsole und Konfiguration von Parameterwerten mit der AWS CLI im Amazon-Redshift-Verwaltungshandbuch.

Zur Definition einer Abfrageüberwachungsregel geben Sie die folgenden Elemente an:

Einen Regelnamen – Regelnamen müssen innerhalb der WLM-Konfiguration eindeutig sein. Regelnamen können aus bis zu 32 alphanumerischen Zeichen oder Unterstrichen bestehen und dürfen keine Leerzeichen oder Anführungszeichen enthalten. Sie können bis zu 25 Regeln pro Warteschlange und insgesamt 25 Regeln für alle Warteschlangen festlegen.
Ein oder mehrere Prädikat(e) – Sie können bis zu drei Prädikate pro Regel angeben. Wenn alle Prädikate für eine Regel erfüllt sind, wird die Aktion der Regel ausgelöst. Ein Prädikat wird durch einen Metriknamen, einen Operator ( =, <, or > ) und einen Wert definiert. Ein Beispiel ist query_cpu_time > 100000. Für eine Liste der Metriken und Beispiele für Werte bei unterschiedlichen Metriken vgl. Abfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestellt unten in diesem Abschnitt.
Eine Aktion – Wenn mehr als eine Regel ausgelöst wird, wählt WLM die Regel mit der schwerwiegendsten Aktion. Mögliche Aktionen, aufsteigend nach Schweregrad, sind:
- Log – Aufzeichnung von Informationen zu der Abfrage in der Systemtabelle STL_WLM_RULE_ACTION. Verwenden Sie diese Aktion, wenn Sie lediglich einen Protokolleintrag schreiben möchten. WLM erstellt höchstens einen Protokolleintrag pro Abfrage und Regel. Nach einer Log-Aktion bleiben andere Regeln wirksam, und WLM überwacht die Abfrage weiter.
- Hop (Nur bei manuellem WLM verfügbar) – Protokollieren der Aktion und Hopping der Abfrage zur nächsten übereinstimmenden Warteschlange. Wenn keine andere passende Warteschlange vorhanden ist, wird die Abfrage abgebrochen. QMR führt Hopping nur für CREATE TABLE AS (CTAS)-Anweisungen und schreibgeschützte Abfragen aus, beispielsweise SELECT-Anweisungen. Weitere Informationen finden Sie unter WLM-Abfragewarteschlangen-Hopping.
- Abort – Protokollieren der Aktion und Abbrechen der Abfrage. QMR stoppt COPY-Anweisungen und Wartungsvorgänge wie ALTER, ANALYZE und VACUUM nicht.
- Ändern der Priorität (nur bei automatischem WLM verfügbar) – Ändern der Priorität einer Warteschlange.

Zur Begrenzung der Laufzeit von Abfragen empfehlen wir das Erstellen einer Abfrageüberwachungsregel anstelle eines WLM-Timeouts. Sie können beispielsweise max_execution_time auf 50.000 Millisekunden festlegen, wie im folgenden JSON-Snippet gezeigt.


"max_execution_time": 50000

Wir empfehlen jedoch, stattdessen eine entsprechende Regel zur Abfrageüberwachung zu definieren. Das folgende Beispiel zeigt eine Regel zur Abfrageüberwachung, die query_execution_time auf 50 Sekunden festgelegt ist:


"rules": 
[
    {
        "rule_name": "rule_query_execution",
        "predicate": [
            {
                "metric_name": "query_execution_time",
                "operator": ">",
                "value": 50
            }
        ],
        "action": "abort"
    }            
]

Informationen zu den Schritten zum Erstellen oder Ändern einer Abfrageüberwachungsregel finden Sie unter Erstellen oder Modifizieren einer Abfrageüberwachungsregel mit der Konsole und Eigenschaften im Parameter wlm_json_configuration im Amazon-Redshift-Verwaltungshandbuch.

Weitere Informationen zu Abfrageüberwachungsregeln finden Sie in den folgenden Themen:

Abfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestellt
Vorlagen für Abfrageüberwachungsregeln
Erstellen einer Regel mit der Konsole
Workload-Management-Konfiguration
Systemtabellen und Ansichten für Abfrageüberwachungsregeln

Abfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestellt

Die folgende Tabelle beschreibt die Metriken für Abfrageüberwachungsregeln. (Diese Metriken unterscheiden sich von den in den Systemtabellen STV_QUERY_METRICS und STL_QUERY_METRICS gespeicherten Metriken.)

Für eine Metrik wird der Leistungsschwellenwert auf Abfrage- oder auf Segmentebene verfolgt. Für weitere Informationen zu Segmenten und Schritten vgl. Workflow der Abfrageplanung und -ausführung.

Anmerkung

Der Parameter WLM-Timeout unterscheidet sich von Abfrageüberwachungsregeln.

Metrik	Name	Beschreibung
Abfrage-CPU-Zeit	`query_cpu_time`	Von der Abfrage verwendete CPU-Zeit, in Sekunden. `CPU time` unterscheidet sich von `Query execution time`. Gültige Werte liegen zwischen 0 und 999 999.
Gelesene Blöcke	`query_blocks_read`	Anzahl der von der Abfrage gelesenen 1 MB-Blöcke. Gültige Werte liegen zwischen 0 und 1 048 575.
Anzahl der Scan-Zeilen	`scan_row_count`	Die Anzahl der Zeilen in einem Scan-Schritt. Die Anzahl der Zeilen ist die Gesamtzahl der Zeilen, die nach der Filterung der zur Löschung markierten Zeilen (Geisterzeilen), jedoch vor der Anwendung benutzerdefinierter Abfragefilter ausgegeben wurden. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Abfrageausführungszeit	`query_execution_time`	Verstrichene Ausführungszeit für eine Abfrage, in Sekunden. Die Ausführungszeit enthält nicht die in einer Warteschlange verbrachte Zeit. Gültige Werte liegen zwischen 0 und 86 399.
Zeit in Abfragewarteschlange	`query_queue_time`	Wartezeit in einer Warteschlange in Sekunden. Gültige Werte liegen zwischen 0 und 86 399.
CPU-Verwendung	`query_cpu_usage_percent`	Prozentsatz der von der Abfrage verwendeten CPU-Kapazität. Gültige Werte liegen zwischen 0 und 6 399.
Speicher zu Festplatte	`query_temp_blocks_to_disk`	Der temporäre Festplattenspeicherplatz, der zum Schreiben von Zwischenergebnissen verwendet wird, in 1 MB-Blöcken. Gültige Werte liegen zwischen 0 und 319 815 679.
CPU-Verzerrung	`cpu_skew`	Das Verhältnis der maximalen CPU-Nutzung für einen Slice zur durchschnittlichen CPU-Nutzung für alle Slices. Diese Metrik wird auf Segmentebene definiert. Gültige Werte liegen zwischen 0 und 99.
I/O-Verzerrung	`io_skew`	Das Verhältnis der maximalen Zahl der gelesenen Blöcke (I/O) für einen Slice zur durchschnittlichen Zahl der gelesenen Blöcke für alle Slices. Diese Metrik wird auf Segmentebene definiert. Gültige Werte liegen zwischen 0 und 99.
Verbundene Zeilen	`join_row_count`	Die Anzahl der in einem Join-Schritt verarbeiteten Zeilen. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Zahl der Zeilen mit eingebetteten Loop-Joins.	`nested_loop_join_row_count`	Die Anzahl der Zeilen in einem eingebetteten Loop-Join. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Anzahl der Rückgabezeilen.	`return_row_count`	Die Anzahl der von der Abfrage ausgegebenen Zeilen. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Segment-Ausführungszeit.	`segment_execution_time`	Verstrichene Ausführungszeit für ein einzelnes Segment, in Sekunden. Nehmen Sie zur Vermeidung oder Reduzierung von Samplingfehlern `segment_execution_time > 10` in Ihre Regeln auf. Gültige Werte liegen zwischen 0 und 86 388.
Anzahl der Spectrum-Scan-Zeilen	`spectrum_scan_row_count`	Die Anzahl der Datenzeilen in Amazon S3, die von einer Amazon-Redshift-Spectrum-Abfrage gescannt wurden. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Spektrum-Scan-Größe.	`spectrum_scan_size_mb`	Die Datengröße in Amazon S3, in MB, die von einer Amazon-Redshift-Spectrum-Abfrage gescannt wurde. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Abfragepriorität	`query_priority`	Die Priorität der Abfrage. Gültige Werte sind `HIGHEST`, `HIGH`, `NORMAL`, `LOW` und `LOWEST`. Beim Vergleich von `query_priority` mittels der Operatoren „größer als (>)“ und „kleiner als (<)“ ist `HIGHEST` größer als `HIGH`, `HIGH` größer als `NORMAL` usw.

Anmerkung

Die Hop-Aktion wird mit dem Prädikat query_queue_time nicht unterstützt. Das heißt, Regeln, die zum Durchführen von Hopping definiert werden, wenn ein query_queue_time-Prädikat erfüllt wird, werden ignoriert.
Kurze Segmentausführungszeiten können bei einigen Metriken zu Samplingfehlern führen, etwa bei io_skew und query_cpu_usage_percent. Nehmen Sie zur Vermeidung oder Reduzierung von Samplingfehlern die Segmentausführungszeit in Ihre Regeln auf. Ein guter Ausgangspunkt ist segment_execution_time > 10.

Die Ansicht SVL_QUERY_METRICS zeigt die Metriken für abgeschlossene Abfragen. Die Ansicht SVL_QUERY_METRICS_SUMMARY zeigt die maximalen Werte der Metriken für abgeschlossene Abfragen. Verwenden Sie die Werte in diesen Ansichten als Hilfe zur Bestimmung der Schwellenwerte für die Definition von Abfrageüberwachungsregeln.

Abfrageüberwachungsmetriken für Amazon Redshift Serverless

Die folgende Tabelle beschreibt die Metriken, die in Abfrageüberwachungsregeln für Amazon Redshift Serverless verwendet werden.

Metrik	Name	Beschreibung
Gelesene Blöcke	`max_query_blocks_read`	Anzahl der von der Abfrage gelesenen 1 MB-Blöcke. Gültige Werte liegen zwischen 0 und 1 048 575.
Anzahl der Scan-Zeilen	`max_scan_row_count`	Die Anzahl der Zeilen in einem Scan-Schritt. Die Anzahl der Zeilen ist die Gesamtzahl der Zeilen, die nach der Filterung der zur Löschung markierten Zeilen (Geisterzeilen), jedoch vor der Anwendung benutzerdefinierter Abfragefilter ausgegeben wurden. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Abfrageausführungszeit	max_query_execution_time	Verstrichene Ausführungszeit für eine Abfrage, in Sekunden. Die Ausführungszeit enthält nicht die in einer Warteschlange verbrachte Zeit. Wenn eine Abfrage die festgelegte Ausführungszeit überschreitet, stoppt Amazon Redshift Serverless die Abfrage. Gültige Werte liegen zwischen 0 und 86 399.
Zeit in Abfragewarteschlange	`max_query_queue_time`	Wartezeit in einer Warteschlange in Sekunden. Gültige Werte liegen zwischen 0 und 86 399.
Speicher zu Festplatte	`max_query_temp_blocks_to_disk`	Der temporäre Festplattenspeicherplatz, der zum Schreiben von Zwischenergebnissen verwendet wird, in 1 MB-Blöcken. Gültige Werte liegen zwischen 0 und 319 815 679.
Verbundene Zeilen	`max_join_row_count`	Die Anzahl der in einem Join-Schritt verarbeiteten Zeilen. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.
Zahl der Zeilen mit eingebetteten Loop-Joins.	`max_nested_loop_join_row_count`	Die Anzahl der Zeilen in einem eingebetteten Loop-Join. Gültige Werte liegen zwischen 0 und 999 999 999 999 999.

Anmerkung

Die Hop-Aktion wird mit dem Prädikat max_query_queue_time nicht unterstützt. Das heißt, Regeln, die zum Durchführen von Hopping definiert werden, wenn ein max_query_queue_time-Prädikat erfüllt wird, werden ignoriert.
Kurze Segmentausführungszeiten können bei einigen Metriken zu Samplingfehlern führen, etwa bei max_io_skew und max_query_cpu_usage_percent.

Vorlagen für Abfrageüberwachungsregeln

Beim Hinzufügen einer Regel mit der Amazon-Redshift-Konsole können Sie eine Regel aus einer vordefinierten Vorlage erstellen. Amazon Redshift erstellt eine neue Regel mit einem Satz von Prädikaten und füllt die Prädikate mit Standardwerten aus. Die Standardaktion ist log. Sie können die Prädikate und die Aktion an Ihren Anwendungsfall anpassen.

In der folgenden Tabelle werden die verfügbaren Vorlagen aufgeführt.

Name der Vorlage	Prädikate	Beschreibung
Nested loop join	`nested_loop_join_row_count > 100`	Ein eingebetteter Loop-Join kann auf ein unvollständiges Join-Prädikat hindeuten; diese führen oft zu sehr großen Ausgabesätzen (einem cartesischen Produkt). Verwenden Sie eine geringe Zahl von Zeilen, um eine mögliche Ausreißerabfrage frühzeitig zu finden.
Die Abfrage gibt eine sehr große Zahl von Zeilen aus.	`return_row_count > 1000000`	Wenn Sie eine Warteschlange für einfache und kurze Abfragen einrichten, können Sie eine Regel anwenden, die Abfragen mit einer großen Zahl ausgegebener Zeilen findet. Die Vorlage verwendet einen Standardwert von 1 Million Zeilen. Bei manchen Systemen kann 1 Million ein zu hoher Wert sein, während in anderen erst ein Wert von 1 Milliarde oder mehr als hoch gilt.
Join mit großer Zahl von Zeilen	`join_row_count > 1000000000`	Ein Join-Schritt mit einer großen Zahl von Zeilen kann darauf hindeuten, dass restriktivere Filter erforderlich sind. Die Vorlage verwendet einen Standardwert von 1 Milliarde Zeilen. Für eine (einmalige) Ad-Hoc-Warteschlange für schnelle und einfache Abfragen sollten Sie eine geringere Zahl verwenden.
Hohe Festplattennutzung beim Schreiben von Zwischenergebnissen	`query_temp_blocks_to_disk > 100000`	Wenn gleichzeitig ausgeführte Abfragen mehr als den verfügbaren System-RAM verwenden, schreibt die Abfrageausführungsengine Zwischenergebnisse auf die Festplatte. Typischerweise ist dies das Ergebnis einer fehlerhaften Abfrage; solche Abfragen verwenden normalerweise auch den meisten Festplattenspeicherplatz. Der akzeptable Schwellenwert für die Festplattennutzung variiert je nach Typ des Clusterknotens und der Anzahl der Knoten. Die Vorlage verwendet einen Standardwert von 100.000 Blöcken bzw. 100 GB. Für einen kleineren Cluster werden Sie wahrscheinlich einen geringeren Wert verwenden.
Abfrage mit langer Laufzeit und hoher I/O Schräglage	`segment_execution_time > 120` und `io_skew > 1.30`	I/O skew occurs when one node slice has a much higher I/O rate than the other slices. As a starting point, a skew of 1.30 (1.3 times average) is considered high. High I/OEine Schräglage ist nicht immer ein Problem, kann aber in Kombination mit einer langen Abfragedauer auf ein Problem mit dem Verteilungsstil oder dem Sortierschlüssel hinweisen.

Systemtabellen und Ansichten für Abfrageüberwachungsregeln

Wenn alle Prädikate einer Regel erfüllt sind, schreibt WLM eine Zeile in die Systemtabelle STL_WLM_RULE_ACTION. Diese Zeile enthält Details zu der Abfrage, die die Regel ausgelöst hat, und die daraus resultierende Aktion.

Darüber hinaus zeichnet Amazon Redshift Abfragemetriken der folgenden Systemtabellen und Ansichten auf.

Die Tabelle STV_QUERY_METRICS zeigt die Metriken für aktuell ausgeführte Abfragen an.
Die Tabelle STL_QUERY_METRICS zeichnet die Metriken für abgeschlossene Abfragen auf.
Die Ansicht SVL_QUERY_METRICS zeigt die Metriken für abgeschlossene Abfragen.
Die Ansicht SVL_QUERY_METRICS_SUMMARY zeigt die maximalen Werte der Metriken für abgeschlossene Abfragen.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Beispiel für dynamische WLM-Eigenschaften

WLM-Systemtabellen und Ansichten