Implementieren von manuellem WLM - Amazon Redshift

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.

Implementieren von manuellem WLM

Bei manuellem WLM können Sie Systemleistung und Benutzererfahrung verwalten, indem Sie die WLM-Konfiguration so ändern, dass separate Warteschlangen für lang andauernde und kürzere Abfragen erstellt werden.

Wenn Benutzer in Amazon Redshift Abfragen ausführen, werden diese zu Abfragewarteschlangen geleitet. Jede Abfragewarteschlange enthält eine Anzahl von Abfrageslots. Jeder Warteschlange ist ein Teil des verfügbaren Speicherplatzes des Clusters zugewiesen. Der Speicher einer Warteschlange wird unter den Abfrageslots der Warteschlange aufgeteilt. Sie können Amazon Redshift aktivieren, um die Nebenläufigkeit von Abfragen über das automatische WLM zu verwalten. Weitere Informationen finden Sie unter Implementieren von automatischem WLM.

Sie können WLM-Eigenschaften auch pro Abfragewarteschlange konfigurieren. Hierzu geben Sie an, wie der Arbeitsspeicher auf die einzelnen Slots verteilt wird und wie Abfragen während der Laufzeit an bestimmte Warteschlangen geleitet werden können. Darüber hinaus können Sie die WLM-Eigenschaften entsprechend konfigurieren, um lang andauernde Abfragen abzubrechen.

Standardmäßig konfiguriert Amazon Redshift die folgenden Abfragewarteschlangen:

  • Eine Superuser-Warteschlange

    Die Superuser-Warteschlange ist ausschließlich für Superusers reserviert und kann nicht konfiguriert werden. Verwenden Sie diese Warteschlange nur dann, wenn Sie Abfragen ausführen müssen, die sich auf das System auswirken, oder für Fehlerbehebungszwecke. Nutzen Sie diese Warteschlange beispielsweise, wenn Sie eine lang andauernde Abfrage eines Benutzers abbrechen oder wenn Sie der Datenbank Benutzer hinzufügen müssen. Verwenden Sie sie nicht für Routineabfragen. Die Warteschlange wird nicht in der Konsole angezeigt, sie erscheint aber in den Systemtabellen in der Datenbank als fünfte Spalte. Um eine Abfrage in der Superuser-Warteschlange ausführen zu können, muss ein Benutzer als Superuser angemeldet sein und die Abfrage in der vordefinierten superuser-Abfragegruppe ausführen.

  • Eine Standard-Benutzer-Warteschlange

    Die Standard-Warteschlange ist anfänglich so konfiguriert, dass sie fünf Abfragen gleichzeitig ausführen kann. Beim manuellen WLM können Sie die Eigenschaften für die Nebenläufigkeit, das Timeout und die Speicherzuweisung für die Standard-Warteschlange ändern, jedoch keine Benutzer- oder Abfragegruppen angeben. Die Standard-Warteschlange muss die letzte Warteschlange in der WLM-Konfiguration sein. Alle Abfragen, die nicht zu anderen Warteschlangen geleitet werden, werden in der Standard-Warteschlange ausgeführt.

Abfragewarteschlangen werden in der WLM-Konfiguration definiert. Die WLM-Konfiguration ist ein bearbeitbarer Parameter (wlm_json_configuration) in einer Parametergruppe, der mit einem oder mehreren Clustern verbunden werden kann. Weitere Informationen finden Sie unter Workload-Management-Konfiguration im Amazon-Redshift-Verwaltungshandbuch.

Sie können der WLM-Standardkonfiguration weitere Abfragewarteschlangen (bis zu acht Benutzerwarteschlangen) hinzufügen. Für jede Abfragewarteschlange kann Folgendes konfiguriert werden:

  • Nebenläufigkeitsskalierungsmodus

  • Nebenläufigkeitsstufe

  • Benutzergruppen

  • Abfragegruppen

  • Zu verwendender WLM-Speicherprozentsatz

  • WLM-Timeout

  • WLM-Abfragewarteschlangen-Hopping

  • Abfrageüberwachungsregeln

Nebenläufigkeitsskalierungsmodus

Bei aktivierter Nebenläufigkeitsskalierung fügt Amazon Redshift automatisch zusätzliche Cluster-Kapazität hinzu, wenn diese benötigt wird, um eine gestiegene Zahl von gleichzeitigen Lese- und Schreibabfragen zu verarbeiten. Benutzern werden stets die jeweils aktuellen Daten angezeigt, unabhängig davon, ob die Abfragen auf dem Haupt- oder einem Nebenläufigkeitsskalierungs-Cluster ausgeführt werden.

Sie können verwalten, welche Abfragen an das Nebenläufigkeitsskalierungs-Cluster gesendet werden, indem Sie WLM-Warteschlangen konfigurieren. Wenn die Nebenläufigkeitsskalierung für eine Warteschlange aktiviert ist, werden entsprechend qualifizierte Abfragen an das Nebenläufigkeitsskalierungs-Cluster übermittelt, anstatt in einer Warteschlange zu warten. Weitere Informationen finden Sie unter Arbeiten mit Nebenläufigkeitsskalierung.

Nebenläufigkeitsstufe

Abfragen in einer Warteschlange werden gleichzeitig ausgeführt, bis die für die jeweilige Warteschlange festgelegte Anzahl der WLM-Abfrage-Slots oder die Nebenläufigkeitsstufe erreicht wird. Weitere Abfragen warten dann in der Warteschlange.

Anmerkung

Die WLM-Nebenläufigkeitsstufe entspricht nicht der Anzahl der gleichzeitigen Benutzerverbindungen zu einem Cluster. Weitere Informationen finden Sie unter Herstellen von Verbindungen mit einem Cluster im Amazon-Redshift-Verwaltungshandbuch.

Bei einer automatischen WLM-Konfiguration (empfohlen) ist die Nebenläufigkeitsstufe auf Auto festgelegt. Amazon Redshift weist Abfragen dynamisch Speicher zu, wobei anschließend bestimmt wird, wie viele Abfragen gleichzeitig ausgeführt werden sollen. Dies basiert auf den Ressourcen, die für laufende Abfragen und Abfragen in der Warteschlange benötigt werden. Automatisches WLM ist nicht konfigurierbar. Weitere Informationen finden Sie unter Implementieren von automatischem WLM.

Bei einer manuellen WLM-Konfiguration weist Amazon Redshift jeder Warteschlange statisch eine feste Speichermenge zu. Der Speicher der Warteschlange wird gleichmäßig auf die Abfrage-Slots verteilt. Zur Veranschaulichung: Wenn einer Warteschlange 20 % des Speichers eines Clusters zugewiesen sind und die Warteschlange 10 Slots umfasst, werden jeder Abfrage 2 % des Cluster-Speichers zugewiesen. Die Speicherzuweisung bleibt fest, unabhängig davon, wie viele Abfragen gleichzeitig ausgeführt werden. Aufgrund dieser festen Speicherzuweisung kann es vorkommen, dass Abfragen, die bei 5 Slots vollständig im Speicher ausgeführt werden, Zwischenergebnisse auf die Festplatte schreiben, wenn die Anzahl der Slots auf 20 erhöht wird. In diesem Fall verringert sich der Anteil jeder Abfrage am Speicher der Warteschlange von 1/5 auf 1/20. Die zusätzlichen Festplatten-I/O-Operationen können sich nachteilig auf die Leistung auswirken.

Die maximale Slot-Anzahl für alle benutzerdefinierten Warteschlangen ist 50. Dadurch wird die Gesamtzahl der Slots für alle Warteschlangen, einschließlich der Standardwarteschlange, begrenzt. Die einzige Warteschlange, die nicht dem Limit unterliegt, ist die reservierte Superuser-Warteschlange.

Standardmäßig lautet die Nebenläufigkeitsstufe von manuellen WLM-Warteschlangen 5. Ihr Workload kann in manchen Fällen von einer höheren Nebenläufigkeitsstufe profitieren, zu, Beispiel:

  • Wenn zahlreiche kleine Abfragen auf länger dauernde Abfragen warten müssen, erstellen Sie eine separate Warteschlange mit einer höheren Slot-Anzahl und weisen Sie die kleineren Abfragen dieser Warteschlange zu. Einer Warteschlange mit einer höheren Nebenläufigkeitsstufe hat weniger Speicherplatz für jeden Abfrageslot, die kleineren Abfragen beanspruchen jedoch auch weniger Speicher.

    Anmerkung

    Wenn Sie Short Query Acceleration (SQA) aktivieren, priorisiert WLM automatisch kurze Abfragen gegenüber längeren Abfragen. In diesem Fall benötigen Sie für die meisten Workflows keine eigene Wartschlange für kurze Abfragen. Weitere Informationen finden Sie unter Arbeiten mit Short Query Acceleration.

  • Wenn mehrere Abfragen vorhanden sind, die auf Daten auf einem einzigen Slice zugreifen, richten Sie eine separate WLM-Warteschlange ein, um diese Abfragen gleichzeitig auszuführen. Amazon Redshift weist gleichzeitige Abfragen verschiedenen Slices zu, wodurch mehrere Abfragen parallel auf mehreren Slices ausgeführt werden können. Zum Beispiel: Wenn eine Abfrage ein einfaches Aggregat mit einem Prädikat auf dem Verteilungsschlüssel ist, befinden sich die Daten für die Abfrage auf einem einzelnen Slice.

Beispiel für manuelles WLM

Dieses Beispiel zeigt anhand eines Szenarios mit einfachem manuellem WLM, wie Slots und Speicher zugewiesen werden können. Sie implementieren manuelles WLM mit den folgenden drei Warteschlangen:

  • Warteschlange für die Datenerfassung – Diese wird für die Erfassung von Daten eingerichtet. Der Warteschlange sind 20 % des Cluster-Speichers zugewiesen und sie verfügt über 5 Slots. Anschließend können 5 Abfragen gleichzeitig in der Warteschlange ausgeführt werden, denen jeweils 4 % des Speichers zugewiesen werden.

  • Warteschlange für Datenwissenschaftler – Diese Warteschlange ist für speicherintensive Abfragen konzipiert. Der Warteschlange sind 40 % des Cluster-Speichers zugewiesen und sie verfügt über 5 Slots. Anschließend können 5 Abfragen gleichzeitig ausgeführt werden, denen jeweils 8 % des Speichers zugewiesen werden.

  • Standardwarteschlange – Diese Warteschlange ist für die Mehrheit der Benutzer in der Organisation konzipiert. Hierzu gehören Vertriebs- und Buchhaltungsteams, die in der Regel kürzere oder mittellange Abfragen haben, die nicht kompliziert sind. Dieser Warteschlange werden 40 % des Cluster-Speichers zugewiesen und sie verfügt über 40 Slots. 40 Abfragen können gleichzeitig in dieser Warteschlange ausgeführt werden, wobei jeder Abfrage 1 % des Speichers zugewiesen wird. Dies ist die maximale Anzahl von Slots, die dieser Warteschlange zugewiesen werden können, da das Limit für alle Warteschlangen bei 50 liegt.

Wenn Sie automatisches WLM ausführen und Ihr Workload die parallele Ausführung von mehr als 15 Abfragen erfordert, empfehlen wir, die Nebenläufigkeitsskalierung einzuschalten. Dies liegt daran, dass eine Erhöhung der Anzahl von Abfrage-Slots auf mehr als 15 zu einem Wettbewerb um Systemressourcen führen und den Gesamtdurchsatz eines einzelnen Clusters einschränken könnte. Mit der Nebenläufigkeitsskalierung können Sie Hunderte von Abfragen bis zu einer konfigurierten Anzahl von Nebenläufigkeitsskalierungs-Clustern parallel ausführen. Die Anzahl der Nebenläufigkeitsskalierungs-Cluster wird von max_concurrency_scaling_clusters gesteuert. Weitere Hinweise zur Parallelitätsskalierung finden Sie unter Arbeiten mit Nebenläufigkeitsskalierung.

Weitere Informationen finden Sie unter Verbessern der Abfrageleistung.

Benutzergruppen

Sie können einer Warteschlange einen Satz von Benutzergruppen zuweisen, indem Sie die einzelnen Namen der Benutzergruppen angeben oder Platzhalter verwenden. Wenn ein Mitglied einer aufgeführten Benutzergruppe eine Abfrage ausführt, wird diese in der entsprechenden Warteschlange ausgeführt. Es gibt keine Grenze für die Anzahl der Benutzergruppen, die einer Warteschlange zugewiesen werden können. Weitere Informationen finden Sie unter Zuweisen von Abfragen zu Warteschlangen auf der Grundlage von Benutzergruppen.

Abfragegruppen

Sie können einer Warteschlange einen Satz von Abfragegruppen zuweisen, indem Sie die einzelnen Namen der Abfragegruppen angeben oder Platzhalter verwenden. Eine Abfragegruppe ist einfach eine Beschriftung. Während der Laufzeit können Sie die Beschriftung der Abfragegruppe einer Serie von Abfragen zuweisen. Alle einer aufgeführten Abfragegruppe zugewiesenen Abfragen werden in der entsprechenden Warteschlange ausgeführt. Es gibt keine Grenze für die Anzahl der Abfragegruppen, die einer Warteschlange zugewiesen werden können. Weitere Informationen finden Sie unter Zuweisen einer Abfrage zu einer Abfragegruppe.

Platzhalter

Wenn in der WLM-Warteschlangenkonfiguration Platzhalter aktiviert sind, können Sie Benutzergruppen und Abfragegruppen einzeln oder mithilfe von Platzhaltern im Unix-Shell-Typ einer Warteschlange zuweisen. Der Musterabgleich beachtet die Groß- und Kleinschreibung.

So entspricht beispielsweise das Platzhalterzeichen „*“ einer beliebigen Anzahl von Zeichen. Wenn Sie dementsprechend dba_* zur Liste der Benutzergruppen für eine Warteschlange hinzufügen, wird dieser Warteschlange jede Benutzerabfrage zugeordnet, die zu einer Gruppe gehört, deren Name mit dba_ beginnt. Beispiele sind dba_admin oder DBA_primary, . Das Platzhalterzeichen „?“ entspricht einem einzelnen Zeichen. Wenn die Warteschlange also die Benutzergruppe dba?1enthält, dann passen die Benutzergruppen mit Namen dba11 und dba21, dba12 jedoch nicht.

Platzhalter sind standardmäßig deaktiviert.

Zu verwendender WLM-Speicherprozentsatz

In einer automatischen WLM-Konfiguration ist der Speicherprozentsatz auf eingestellt auto. Weitere Informationen finden Sie unter Implementieren von automatischem WLM.

In einer manuellen WLM-Konfiguration können Sie zur Angabe der Menge des verfügbaren Speicherplatzes, der einer Abfrage zugewiesen wird, den Parameter WLM Memory Percent to Use einstellen. Standardmäßig wird jeder benutzerdefinierten Warteschlange ein gleicher Anteil des für benutzerdefinierte Abfragen verfügbaren Speicherplatzes zugewiesen. Wenn Sie beispielsweise vier benutzerdefinierte Warteschlangen haben, erhält jede Warteschlange 25 Prozent des verfügbaren Speicherplatzes. Die Superuser-Warteschlange hat ihren eigenen zugewiesenen Speicherplatz und kann nicht modifiziert werden. Zur Änderung der Zuweisung weisen Sie jeder Warteschlange einen ganzzahligen Speicherplatzprozentsatz zu, bis insgesamt 100 Prozent erreicht sind. Nicht zugewiesener Speicherplatz wird von Amazon Redshift verwaltet und kann vorübergehend einer Warteschlange zugewiesen werden, wenn diese zusätzlichen Speicherplatz zur Verarbeitung anfragt.

Wenn Sie beispielsweise vier Warteschlangen konfigurieren, können Sie den Speicherplatz wie folgt zuweisen: 20 Prozent, 30 Prozent, 15 Prozent, 15 Prozent. Die verbleibenden 20 Prozent sind nicht zugewiesen und werden von dem Service verwaltet.

WLM-Timeout

WLM-Timeout (max_execution_time) ist veraltet. Erstellen Sie stattdessen eine Abfrageüberwachungsregel (Query Monitoring Rule, QMR) query_execution_time zur Begrenzung der Ausführungszeit für eine Abfrage. Weitere Informationen finden Sie unter WLM-Abfrageüberwachungsregeln.

Um die Zeit zu begrenzen, die Abfragen in einer WLM-Warteschlange nutzen können, können Sie den WLM-Timeout-Wert für jede Warteschlange einstellen. Der Timeout-Parameter gibt die Zeit in Millisekunden an, für die Amazon Redshift auf die Ausführung einer Abfrage wartet, bevor es diese beendet oder zur nächsten Warteschlange springt. Der Timeout-Wert basiert auf der Abfrageausführungszeit und beinhaltet nicht die in einer Warteschlange verbrachte Zeit.

WLM führt Hopping möglichst für CREATE TABLE AS (CTAS)-Anweisungen und schreibgeschützte Abfragen wie SELECT-Anweisungen aus. Abfragen, für die kein Hopping ausgeführt werden kann, werden abgebrochen. Weitere Informationen finden Sie unter WLM-Abfragewarteschlangen-Hopping.

Das WLM-Timeout gilt nicht für eine Abfrage, die den Status „returning“ erreicht hat. Um den Status einer Abfrage anzuzeigen, vgl. die Systemtabelle STV_WLM_QUERY_STATE. COPY-Anweisungen und Wartungsoperationen wie ANALYZE und VACUUM unterliegen keinen WLM-Timeouts.

Die Funktion des WLM-Timeout ist ähnlich wie beim statement_timeout Konfigurationsparameter. Der Unterschied besteht darin, dass, während der Konfigurationsparameter statement_timeout für den gesamten Cluster gilt, das WLM-Timeout nur für eine einzelne Warteschlange in der WLM-Konfiguration spezifisch ist.

Wenn statement_timeout auch angegeben wird, wird die untere der Anweisungen „statement_timeout“ und „WLM-Timeout (max_execution_time)“ verwendet.

Abfrageüberwachungsregeln

Sie können auf Metriken basierende Leistungsgrenzen für WLM-Warteschlangen definieren und angeben, 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. Weitere Informationen finden Sie unter WLM-Abfrageüberwachungsregeln.