Modifizieren der WLM-Konfiguration

Die einfachste Möglichkeit zur Modifizierung der WLM-Konfiguration besteht in der Verwendung der Amazon-Redshift-Konsole. Sie können auch die AWS CLI oder die Amazon Redshift Redshift-API verwenden.

Wenn Sie für Ihr Cluster zwischen automatischem und manuellem WLM wechseln, wird für Ihr Cluster der Zustand pending reboot festgelegt. Diese Änderung wird erst nach dem nächsten Neustart des Clusters wirksam.

Detaillierte Informationen zum Ändern von WLM-Konfigurationen finden Sie unter Konfigurieren von Workload Management im Amazon-Redshift-Verwaltungshandbuch.

Migration vom manuellen WLM zum automatischen WLM

Um den Systemdurchsatz zu maximieren und die Ressourcen so effektiv wie möglich zu nutzen, sollten Sie für Ihre Warteschlangen das automatische WLM festlegen. Sie sollten dabei den folgenden Ansatz befolgen, um einen problemlosen Übergang vom manuellen WLM zum automatischen WLM sicherzustellen.

Um vom manuellen WLM auf automatisches WLM umzustellen und Abfrageprioritäten zu verwenden, sollten Sie eine neue Parametergruppe erstellen und diese Parametergruppe anschließend an Ihren Cluster anfügen. Weitere Informationen finden Sie unter Amazon Redshift Parameter Groups (Amazon-Redshift-Parametergruppen) im Amazon-Redshift-Verwaltungshandbuch.

Wichtig

Um die Parametergruppe zu ändern oder vom manuellen zum automatischen WLM zu wechseln, ist ein Neustart des Clusters erforderlich. Weitere Informationen finden Sie unter Dynamische und statische WLM-Konfigurationseigenschaften.

Betrachten wir ein Beispiel mit drei manuellen WLM-Warteschlangen. Es gibt jeweils eine Warteschlange für einen ETL-Workload, einen Analytics-Workload und einen Data Science-Workload. Der ETL-Workload wird alle 6 Stunden und der Analytics-Workload während des gesamten Tages ausgeführt. Der Data Science-Workload kann jederzeit ausgeführt werden und dabei einen Spitzenwert erreichen. Bei Verwendung des manuellen WLM geben Sie den Arbeitsspeicher und den Nebenläufigkeitsfaktor an, den die einzelnen Workload-Warteschlangen erhalten, basierend auf Ihrem Verständnis der Bedeutung der einzelnen Workloads für das Geschäft. Die Festlegung von Arbeitsspeicher und Nebenläufigkeit ist nicht nur schwierig, sondern führt auch zu einer statischen Partitionierung der Cluster-Ressourcen und damit zu Verschwendung, wenn nur ein Teilsatz der Workloads ausgeführt wird.

Sie können automatisches WLM mit Abfrageprioritäten verwenden, um die relativen Prioritäten der Workloads anzugeben, und damit die zuvor beschriebenen Probleme vermeiden. Für dieses Beispiel führen Sie die folgenden Schritte aus:

• Erstellen Sie eine neue Parametergruppe und wechseln Sie zum Modus Auto WLM (Automatisches WLM).

• Fügen Sie für jeden der drei Workloads Warteschlangen hinzu: ETL-Workload, Analytics-Workload und Data Science-Workload. Verwenden Sie dieselben Benutzergruppen für jeden Workload, die im Manual WLM-Modus verwendet wurden.

• Legen Sie die Priorität für den ETL-Workload auf High, für den Analytics-Workload auf Normal und für den Data Science-Workload auf Low fest. Diese Prioritäten geben die geschäftlichen Prioritäten für die verschiedenen Workloads oder Benutzergruppen wieder.

• Optional können Sie die Nebenläufigkeitsskalierung für die Analytics- oder Data-Science-Warteschlange aktivieren, sodass Abfragen in diesen Warteschlangen eine konsistente Leistung erhalten, auch wenn der ETL-Workload alle 6 Stunden ausgeführt wird.

Wenn Sie Abfrageprioritäten verwenden und nur der Analytics-Workload für das Cluster ausgeführt wird, kann er das gesamte System nutzen. Dies führt zu einem hohen Durchsatz bei besserer Systemauslastung. Wenn jedoch der ETL-Workload gestartet wird, erhält dieser Priorität, da er eine höhere Priorität hat. Abfragen, die als Teil des ETL-Workloads ausgeführt werden, erhalten Priorität bei der Annahme. Nach der Annahme werden ihnen zudem bevorzugt Ressourcen zugeteilt. Daher wird der ETL-Workload planbar ausgeführt, unabhängig davon, welche weiteren Aufgaben im System ausgeführt werden. Die planbare Leistung eines Workloads mit hoher Priorität geht zu Lasten anderer Workloads mit niedrigerer Priorität. Diese benötigen eine längere Zeit für die Ausführung, da ihre Abfragen warten müssen, bis wichtigere Abfragen abgeschlossen sind. Ein anderer Grund für die längere Ausführungszeit besteht darin, dass sie einen kleineren Anteil an den Ressourcen erhalten, wenn sie gleichzeitig mit Abfragen höherer Priorität ausgeführt werden. Die von Amazon Redshift verwendeten Planungsalgorithmen sorgen dafür, dass Abfragen mit niedrigerer Priorität nicht angehalten werden, sondern weiter ausgeführt werden, wenn auch langsamer.

Anmerkung

• Im automatischen WLM ist das Zeitüberschreitungsfeld nicht verfügbar. Sie müssen stattdessen die QMR-Regel verwenden, query_execution_time. Weitere Informationen finden Sie unter WLM-Abfrageüberwachungsregeln.

• Die QMR-Aktion, HOP, kann nicht auf automatisches WLM angewendet werden. Sie müssen stattdessen die Aktion change priority verwenden. Weitere Informationen finden Sie unter WLM-Abfrageüberwachungsregeln.

• Cluster verwenden automatische WLM-Warteschlangen und manuelle WLM-Warteschlangen unterschiedlich, was zu Verwechslungen mit Ihren Konfigurationen führen kann. Beispielsweise können Sie die Prioritätseigenschaft in automatischen WLM-Warteschlangen konfigurieren, nicht jedoch in manuellen WLM-Warteschlangen. Vermeiden Sie daher die gleichzeitige Verwendung von automatischen und manuellen WLM-Warteschlangen innerhalb einer Parametergruppe. Erstellen Sie stattdessen eine neue Parametergruppe, wenn Sie zum automatischen WLM migrieren.