WLMRegeln für die Abfrageüberwachung - Amazon Redshift
Definition einer AbfrageüberwachungsregelAbfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestelltAbfrageüberwachungsmetriken für Amazon Redshift ServerlessVorlagen für AbfrageüberwachungsregelnSystemtabellen und Ansichten für Abfrageüberwachungsregeln

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

WLMRegeln für die Abfrageüberwachung

In Amazon Redshift Workload Management (WLM) definieren Regeln zur Abfrageüberwachung metrikbasierte Leistungsgrenzen für WLM Warteschlangen und geben an, welche Maßnahmen ergriffen werden sollen, wenn eine Abfrage diese Grenzen ü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 Regeln zur Abfrageüberwachung als Teil Ihrer Workload-Management-Konfiguration (). WLM 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.

WLMwertet Metriken alle 10 Sekunden aus. Wenn im gleichen Zeitraum mehr als eine Regel ausgelöst wird, WLM wählt die Regel mit der schwerwiegendsten Aktion aus. Wenn die Aktion für zwei Regeln denselben Schweregrad hat, werden die Regeln basierend auf dem Regelnamen in alphabetischer Reihenfolge WLM ausgeführt. 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. WLMinitiiert nur eine Protokollaktion 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, WLM schreibt eine Zeile in die STL_WLM_RULE_ACTION Systemtabelle. 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 Regeln zur Abfrageüberwachung als Teil Ihrer WLM Konfiguration, die Sie als Teil der Parametergruppendefinition Ihres Clusters definieren.

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

Anmerkung

Wenn Sie Regeln programmgesteuert erstellen möchten, empfehlen wir dringend, die Konsole zum Generieren der Regeln zu verwenden, die Sie in JSON die Parametergruppendefinition aufnehmen. 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:

  • Ein Regelname — 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, wird WLM die Regel mit der schwerwiegendsten Aktion ausgewählt. Mögliche Aktionen, aufsteigend nach Schweregrad, sind:

    • Protokoll — Zeichnet Informationen über die Abfrage in der ACTION Systemtabelle STL WLM _ RULE _ _ auf. Verwenden Sie diese Aktion, wenn Sie lediglich einen Protokolleintrag schreiben möchten. WLMerstellt höchstens ein Protokoll pro Abfrage und Regel. Nach einer Protokollaktion bleiben andere Regeln in Kraft und überwachen die Abfrage WLM weiterhin.

    • Hop (nur im manuellen Modus verfügbarWLM) — Protokolliert die Aktion und leitet die Abfrage zur nächsten passenden Warteschlange weiter. Wenn keine andere passende Warteschlange vorhanden ist, wird die Abfrage abgebrochen. QMRüberspringt nur CREATETABLEAS (CTAS) -Anweisungen und schreibgeschützte Abfragen, wie SELECT z. B. Anweisungen. Weitere Informationen finden Sie unter WLMÜberspringen von Abfragen.

    • Abort – Protokollieren der Aktion und Abbrechen der Abfrage. QMRstoppt keine COPY Anweisungen und Wartungsvorgänge wie ANALYZE und. VACUUM

    • Priorität ändern (nur mit Automatik verfügbarWLM) — Ändert die Priorität einer Abfrage.

Um die Laufzeit von Abfragen zu begrenzen, empfehlen wir, eine Regel zur Abfrageüberwachung zu erstellen, anstatt das WLM Timeout zu verwenden. Sie können beispielsweise den Wert max_execution_time auf 50.000 Millisekunden festlegen, wie im folgenden Codeausschnitt gezeigt. JSON

"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

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 WLMTimeout unterscheidet sich von Abfrageüberwachungsregeln.

Metrik Name Beschreibung
CPUZeit der Abfrage query_cpu_time CPUvon der Abfrage verwendete Zeit in Sekunden. CPU timeunterscheidet sich vonQuery 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.

CPUVerwendung query_cpu_usage_percent Prozent der von der Abfrage genutzten 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.

CPUschräg cpu_skew Das Verhältnis der maximalen CPU Nutzung für ein beliebiges Segment zur durchschnittlichen CPU Nutzung für alle Scheiben. 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
CPUZeit der Abfrage max_query_cpu_time CPUvon der Abfrage verwendete Zeit in Sekunden. CPU timeunterscheidet sich vonQuery execution time.

Gültige Werte liegen zwischen 0 und 999 999.

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.

CPUVerwendung max_query_cpu_usage_percent Prozent der von der Abfrage genutzten CPU Kapazität.

Gültige Werte liegen zwischen 0 und 6 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 die Ausführung von Abfragen derzeit mehr als das verfügbare System beanspruchtRAM, schreibt das Abfrageausführungsmodul Zwischenergebnisse auf die Festplatte (verschütteter Speicher). 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.
Lang dauernde Abfrage mit hoher I/O-Verzerrung segment_execution_time > 120 und io_skew > 1.30 I/O-Verzerrung tritt auf, wenn ein Knotenslice eine viel höhere I/O-Rate aufweist als die anderen Slices. Als Ausgangspunkt gilt eine Verzerrung von 1,30 (das 1,3-fache des Durchschnitts) als hoch. Eine hohe I/O-Verzerrung ist nicht immer ein Problem. in Verbindung mit langen Abfrageausführungszeiten kann sie jedoch auf ein Problem mit dem Verteilungsstil oder dem Sortierschlüssel hindeuten.

Systemtabellen und Ansichten für Abfrageüberwachungsregeln

Wenn alle Prädikate einer Regel erfüllt sind, WLM schreibt eine Zeile in die STL_WLM_RULE_ACTION Systemtabelle. 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.