Implementierungshandbuch 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.

Implementierungshandbuch WLM

Mit der manuellen Option können Sie die Systemleistung und die Benutzererfahrung verwaltenWLM, indem Sie die WLM Konfiguration so ändern, dass separate Warteschlangen für Abfragen mit langer Laufzeit und Abfragen mit kurzer Laufzeit 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 Parallelität von Abfragen automatisch zu verwalten. WLM Weitere Informationen finden Sie unter Automatisch implementieren WLM.

Oder Sie können WLM Eigenschaften für jede 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. Sie können auch WLM Eigenschaften konfigurieren, um Abfragen mit langer Laufzeit 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. Wenn Sie manuell arbeitenWLM, können Sie die Eigenschaften für Parallelität, Timeout und Speicherzuweisung für die Standardwarteschlange ändern, aber Sie können keine Benutzergruppen oder Abfragegruppen angeben. Die Standardwarteschlange 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 sind in der WLM Konfiguration definiert. Die WLM Konfiguration ist ein bearbeitbarer Parameter (wlm_json_configuration) in einer Parametergruppe, der einem oder mehreren Clustern zugeordnet werden kann. Weitere Informationen finden Sie unter Workload-Management-Konfiguration im Amazon-Redshift-Verwaltungshandbuch.

Sie können der WLM Standardkonfiguration zusätzliche Abfragewarteschlangen hinzufügen, bis zu insgesamt acht Benutzerwarteschlangen. Für jede Abfragewarteschlange kann Folgendes konfiguriert werden:

  • Nebenläufigkeitsskalierungsmodus

  • Nebenläufigkeitsstufe

  • Benutzergruppen

  • Abfragegruppen

  • WLMProzent des zu verwendenden Speichers

  • WLMTimeout

  • WLMQueue-Hopping bei Abfragen

  • 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 verwalten, welche Abfragen an den Concurrency Scaling-Cluster gesendet werden, indem Sie Warteschlangen konfigurierenWLM. 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 Nebenläufigkeitsskalierung.

Nebenläufigkeitsstufe

Abfragen in einer Warteschlange werden gleichzeitig ausgeführt, bis sie die für diese Warteschlange definierte Anzahl an WLM Abfrageslots oder Parallelitätsebene erreichen. Weitere Abfragen warten dann in der Warteschlange.

Anmerkung

WLMDer Parallelitätsgrad unterscheidet sich von der Anzahl der gleichzeitigen Benutzerverbindungen, die zu einem Cluster hergestellt werden können. Weitere Informationen finden Sie unter Herstellen von Verbindungen mit einem Cluster im Amazon-Redshift-Verwaltungshandbuch.

In einer automatischen WLM Konfiguration, die empfohlen wird, ist die Parallelitätsebene auf Auto gesetzt. 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. Auto WLM ist nicht konfigurierbar. Weitere Informationen finden Sie unter Automatisch implementieren WLM.

In 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 haben manuelle WLM Warteschlangen eine Parallelitätsstufe von 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 die Beschleunigung kurzer Abfragen (SQA) aktivieren, WLM werden kurze Abfragen automatisch vor länger laufenden Abfragen priorisiert, sodass Sie für die meisten Workflows keine separate Warteschlange für kurze Abfragen benötigen. Weitere Informationen finden Sie unter Short Query Acceleration.

  • Wenn Sie mehrere Abfragen haben, die jeweils auf Daten in einem einzelnen Bereich 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.

Ein manuelles Beispiel WLM

Dieses Beispiel ist ein einfaches, manuelles WLM Szenario, das zeigt, wie Steckplätze und Speicher zugewiesen werden können. Sie implementieren Manual 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 automatisch arbeiten WLM und für Ihre Arbeitslast mehr als 15 Abfragen parallel ausgeführt werden müssen, empfehlen wir, die Parallelitätsskalierung zu aktivieren. 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 Nebenläufigkeitsskalierung.

Weitere Informationen finden Sie unter Verbesserung 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 Platzhalter in der WLM Warteschlangenkonfiguration aktiviert sind, können Sie Benutzergruppen und Abfragegruppen einer Warteschlange entweder einzeln oder mithilfe von Platzhaltern im Unix-Shell-Stil 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.

WLMProzent des zu verwendenden Speichers

In einer automatischen WLM Konfiguration ist der Prozentsatz des Arbeitsspeichers auf festgelegtauto. Weitere Informationen finden Sie unter Automatisch implementieren WLM.

In einer manuellen WLM Konfiguration können Sie den WLM Memory Percent to Use Parameter festlegen, um die Menge des verfügbaren Speichers anzugeben, der einer Abfrage zugewiesen wird. 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.

WLMTimeout

WLMtimeout (max_execution_time) ist veraltet. Erstellen Sie stattdessen eine Regel zur Abfrageüberwachung (QMR), mit query_execution_time der Sie die abgelaufene Ausführungszeit für eine Abfrage einschränken können. Weitere Informationen finden Sie unter WLMRegeln für die Abfrageüberwachung.

Um die Zeitspanne zu begrenzen, die Abfragen in einer bestimmten WLM Warteschlange verwenden dürfen, können Sie den WLM Timeout-Wert für jede Warteschlange festlegen. 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.

WLMversucht, Hop CREATETABLEALS (CTAS) -Anweisungen und schreibgeschützte Abfragen, wie z. B. Anweisungen, auszuführen. SELECT Abfragen, für die kein Hopping ausgeführt werden kann, werden abgebrochen. Weitere Informationen finden Sie unter WLMÜberspringen von Abfragen.

WLMTimeout gilt nicht für eine Abfrage, die den Rückgabestatus erreicht hat. Um den Status einer Abfrage anzuzeigen, vgl. die Systemtabelle STV_WLM_QUERY_STATE. COPYAnweisungen und Wartungsvorgänge, wie z. B. ANALYZE undVACUUM, unterliegen keiner WLM Zeitüberschreitung.

Die Funktion von WLM Timeout ähnelt dem statement_timeout Konfigurationsparameter. Der Unterschied besteht darin, dass, wenn der statement_timeout Konfigurationsparameter für den gesamten Cluster gilt, der WLM Timeout für eine einzelne Warteschlange in der WLM Konfiguration spezifisch ist.

Falls ebenfalls angegeben, statement_timeout wird der jeweils niedrigere Wert von statement_timeout und WLM timeout (max_execution_time) verwendet.

Abfrageüberwachungsregeln

Regeln zur Abfrageüberwachung definieren auf Metriken basierende Leistungsgrenzen für WLM Warteschlangen und geben an, welche Aktion ergriffen werden soll, 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. Weitere Informationen finden Sie unter WLMRegeln für die Abfrageüberwachung.