Workload-Management-Konfiguration

In Amazon Redshift verwenden Sie Workload Management (WLM), um festzulegen, wie viele Abfragewarteschlangen verfügbar sind und wie Abfragen zur Verarbeitung an diese Warteschlangen geleitet werden. WLM ist Teil der Parametergruppenkonfiguration. Ein Cluster verwendet die WLM-Konfiguration, die in seiner zugehörigen Parametergruppe angegeben ist.

Wenn Sie eine Parametergruppe erstellen, enthält die Standard-WLM-Konfiguration eine Warteschlange, die bis zu fünf Abfragen gleichzeitig enthalten kann. Sie können weitere Warteschlangen hinzufügen und in jeder davon WLM-Eigenschaften konfigurieren, wenn Sie die Abfrageverarbeitung besser steuern möchten. Jede von Ihnen hinzugefügte Warteschlange hat dieselbe Standard-WLM-Konfiguration, bis Sie ihre Eigenschaften konfigurieren.

Wenn Sie weitere Warteschlangen hinzufügen, ist die letzte Warteschlange in der Konfiguration die Standardwarteschlange. Sofern keine Abfrage auf der Grundlage der Kriterien in der WLM-Konfiguration zu einer anderen Warteschlange geleitet wird, wird sie von der Standard-Warteschlange verarbeitet. Sie können für die Standardwarteschlange Modus und Nebenläufigkeitsstufe (Abfrageslots) angeben, jedoch keine Benutzer- oder Abfragegruppen.

Wie bei anderen Parametern auch können Sie die WLM-Konfiguration in der Standard-Parametergruppe nicht ändern. Mit der Standard-Parametergruppe verbundene Cluster verwenden immer die Standard-WLM-Konfiguration. Zum Ändern der WLM-Konfiguration erstellen Sie eine neue Parametergruppe und verknüpfen diese mit allen Clustern, die die benutzerdefinierte WLM-Konfiguration erfordern.

Dynamische und statische WLM-Eigenschaften

Die WLM-Konfigurationseigenschaften sind dynamisch oder statisch. Sie können dynamische Eigenschaften ohne Neustart des Clusters auf die Datenbank anwenden. Statische Eigenschaften erfordern jedoch einen Neustart des Clusters, damit die Änderungen wirksam werden. Weitere Informationen zu statischen und dynamischen Eigenschaften finden Sie unter Dynamische und statische WLM-Konfigurationseigenschaften.

Eigenschaften des Parameters wlm_json_configuration

Sie können WLM mithilfe der Amazon Redshift Redshift-Konsole AWS CLI, der Amazon Redshift Redshift-API oder eines der SDKs konfigurieren. AWS Die WLM-Konfiguration nutzt verschiedene Eigenschaften zur Definition des Warteschlangenverhaltens, wie etwa die Speicherzuweisung unter den Warteschlangen, die Anzahl der gleichzeitig in einer Warteschlange ausführbaren Abfragen usw.

Anmerkung

Die folgenden Eigenschaften werden mit ihren Amazon-Redshift-Konsolennamen und den entsprechenden JSON-Eigenschaftennamen in den Beschreibungen aufgeführt.

Die folgende Tabelle zeigt, ob eine Eigenschaft auf automatisches WLM oder manuelles WLM angewendet werden kann.

WLM-Eigenschaft	Automatisches WLM	Manuelles WLM
Automatisches WLM	Ja	Ja
Aktivieren der Beschleunigung kurzer Abfragen	Ja	Ja
Maximale Laufzeit für kurze Abfragen	Ja	Ja
Priorität	Ja	Nein
Warteschlangentyp	Ja	Ja
Queue name (Name der Warteschlange)	Ja	Ja
Concurrency Scaling mode (Nebenläufigkeitsskalierungsmodus)	Ja	Ja
Nebenläufigkeit	Nein	Ja
Benutzergruppen	Ja	Ja
Benutzergruppenplatzhalter	Ja	Ja
Abfragegruppen	Ja	Ja
Abfragegruppenplatzhalter	Ja	Ja
Benutzerrollen	Ja	Ja
Platzhalter für die Benutzerrolle	Ja	Ja
Zeitüberschreitung	Nein	Als veraltet gekennzeichnet
Arbeitsspeicher	Nein	Ja
Query Monitoring Rules (Abfrageüberwachungsregeln)	Ja	Ja

Die folgende Liste enthält Beschreibungen der WLM-Eigenschaften, die Sie konfigurieren können.

Automatisches WLM

Automatisches WLM auf true gesetzt, aktiviert das automatische WLM. Automatisches WLM legt die Werte für Concurrency on main (Nebenläufigkeit auf dem Haupt-Cluster) und Memory (%) (Arbeitsspeicher (%)) auf Auto fest. Amazon Redshift verwaltet die Abfragenebenläufigkeit und die Arbeitsspeicherzuweisung. Der Standardwert ist true.

JSON-Eigenschaft: auto_wlm

Aktivieren von Short Query Acceleration

Wenn Sie Short Query Acceleration (SQA) verwenden, werden ausgewählte, kurze Abfragen gegenüber Abfragen mit einer höheren Dauer priorisiert. SQA führt kurze Abfragen an einer dedizierten Stelle aus, sodass SQA-Abfragen nicht hinter längeren Abfragen in Warteschlangen eingereiht werden. Mit SQA werden kürzere Abfragen schneller ausgeführt und der Benutzer sieht schneller Ergebnisse. Wenn Sie SQA aktivieren, können Sie auch die maximale Laufzeit für kurze Abfragen festlegen. Legen Sie den Wert true fest, um SQA zu aktivieren. Der Standardwert ist false. Diese Einstellung wird für die einzelnen Parametergruppen, nicht für die Warteschlangen angewendet.

JSON-Eigenschaft: short_query_queue

Maximum run time for short queries (Maximale Laufzeit für kurze Abfragen)

Wenn Sie SQA aktivieren, können Sie 0 angeben, damit WLM dynamisch die maximale Laufzeit für kurze Abfragen festlegt. Alternativ können Sie einen Wert zwischen 1 und 20 Sekunden in Millisekunden angeben. Der Standardwert ist 0.

JSON-Eigenschaft: max_execution_time

Priority (Priorität)

Im Feld „Priority“ (Priorität) wird die Priorität der Abfragen festgelegt, die in einer Warteschlange ausgeführt werden. Um die Priorität festzulegen, muss WLM mode (WLM-Modus) auf Auto WLM (Automatisches WLM) festgelegt werden, d. h., auto_wlm muss true sein. Die Prioritätswerte können highest, high, normal, low und lowest sein. Der Standardwert ist normal.

JSON-Eigenschaft: priority

Queue type (Warteschlangentyp)

Der Warteschlangentyp bezeichnet eine Warteschlange als entweder von Auto WLM (Automatisches WLM) oder Manual WLM (Manuelles WLM) verwendet. Legen Sie queue_type auf auto oder manual fest. Wenn nichts angegeben ist, ist der Standardwert manual.

JSON-Eigenschaft: queue_type

Queue name (Name der Warteschlange)

Der Name der Warteschlange. Sie können den Namen der Warteschlange entsprechend Ihren geschäftlichen Anforderungen festlegen. Warteschlangennamen müssen innerhalb einer WLM-Konfiguration eindeutig sein und können bis zu 64 alphanumerische Zeichen, Unterstriche oder Leerzeichen enthalten. Sie dürfen keine Anführungszeichen enthalten. Wenn es beispielsweise eine Warteschlange für Ihre ETL-Abfragen gibt, können Sie sie mit ETL queue benennen. Dieser Name wird in Metriken, Systemtabellenwerten und in der Amazon-Redshift-Konsole zur Identifizierung der Warteschlange verwendet. Abfragen und Berichte, die den Namen aus diesen Quellen verwenden, müssen Änderungen des Namens verarbeiten können. Zuvor wurden die Warteschlangennamen von Amazon Redshift generiert. Die Standardnamen von Warteschlangen sind Queue 1, Queue 2 bis zur letzten Warteschlange mit dem Namen Default queue.

Wichtig

Wenn Sie einen Warteschlangennamen ändern, ändert sich auch der QueueName Dimensionswert der WLM-Warteschlangenmetriken (wie WLM, QueueWait WLM-ZeitQueueLength, WLM, WLM QueriesCompletedPerSecond, WLM usw.)QueryDuration. RunningQueries Wenn Sie also den Namen einer Warteschlange ändern, müssen Sie möglicherweise die von Ihnen eingerichteten Alarme ändern CloudWatch .

JSON-Eigenschaft: name

Concurrency Scaling mode (Nebenläufigkeitsskalierungsmodus)

Zur Aktivierung der Nebenläufigkeitsskalierung für eine Warteschlange setzen Sie Concurrency Scaling mode (Nebenläufigkeitsskalierungsmodus) auf auto. Wenn die Anzahl der an eine Warteschlange geleiteten Abfragen die konfigurierte Nebenläufigkeit der Warteschlange überschreitet, werden berechtigte Abfragen an den Skalierungs-Cluster gesendet. Wenn Slots verfügbar werden, werden Abfragen auf dem Haupt-Cluster ausgeführt. Der Standardwert ist off.

JSON-Eigenschaft: concurrency_scaling

Concurrency (Nebenläufigkeit)

Die Anzahl der Abfragen, die gleichzeitig in einer manuellen WLM-Warteschlange ausgeführt werden können. Diese Eigenschaft gilt nur für manuelles WLM. Wenn für eine Warteschlange die Nebenläufigkeitsskalierung aktiviert ist, werden berechtigte Abfragen an einen Skalierungs-Cluster gesendet, wenn eine Warteschlange die Nebenläufigkeitsstufe (Abfrageslots) erreicht hat. Wenn die Nebenläufigkeitsskalierung nicht aktiviert ist, warten Abfragen in der Warteschlange, bis ein Slot verfügbar wird. Der Bereich liegt zwischen 1 und 50.

JSON-Eigenschaft: query_concurrency

User Groups (Benutzergruppen)

Eine durch Kommata getrennte Liste von Benutzergruppennamen. Wenn Mitglieder der Benutzergruppe Abfragen in der Datenbank ausführen, werden deren Abfragen zu der Warteschlange geleitet, die zu der Benutzergruppe gehört.

JSON-Eigenschaft: user_group

User Group Wildcard (Benutzergruppenplatzhalter)

Ein boolescher Wert, der angibt, ob Platzhalter für Benutzergruppen aktiviert werden sollen. Beim Wert 0 werden Platzhalter deaktiviert, beim Wert 1 werden sie aktiviert. Wenn Platzhalter aktiviert sind, können Sie „*“ oder „?“ verwenden, um beim Ausführen von Abfragen mehrere Benutzergruppen anzugeben. Weitere Informationen finden Sie unter Platzhalter.

JSON-Eigenschaft: user_group_wild_card

Query Groups (Abfragegruppen)

Eine durch Kommata abgeteilte Liste von Abfragegruppen. Wenn Mitglieder der Abfragegruppe Abfragen in der Datenbank ausführen, werden deren Abfragen zu der Warteschlange geleitet, die zu der Abfragegruppe gehört.

JSON-Eigenschaft: query_group

Query Group Wildcard (Abfragegruppenplatzhalter)

Ein boolescher Wert, der angibt, ob Platzhalter für Abfragegruppen aktiviert werden sollen. Beim Wert 0 werden Platzhalter deaktiviert, beim Wert 1 werden sie aktiviert. Wenn Platzhalter aktiviert sind, können Sie „*“ oder „?“ verwenden, um beim Ausführen von Abfragen mehrere Abfragegruppen anzugeben. Weitere Informationen finden Sie unter Platzhalter.

JSON-Eigenschaft: query_group_wild_card

Benutzerrollen

Eine durch Kommata getrennte Liste von Benutzerrollen. Wenn Mitglieder mit dieser Benutzerrolle Abfragen in der Datenbank ausführen, werden deren Abfragen zu der Warteschlange geleitet, die zu ihrer Benutzerrolle gehört. Weitere Informationen zu Benutzerrollen finden Sie unter Rollenbasierte Zugriffskontrolle (RBAC).

JSON-Eigenschaft: user_role

Platzhalter für die Benutzerrolle

Ein boolescher Wert, der angibt, ob Platzhalter für Abfragegruppen aktiviert werden sollen. Beim Wert 0 werden Platzhalter deaktiviert, beim Wert 1 werden sie aktiviert. Wenn Platzhalter aktiviert sind, können Sie „*“ oder „?“ verwenden, um beim Ausführen von Abfragen mehrere Abfragegruppen anzugeben. Weitere Informationen finden Sie unter Platzhalter.

JSON-Eigenschaft: user_role_wild_card

Timeout (ms)

WLM-Timeout (max_execution_time) ist veraltet. Die Funktion ist bei Verwendung von automatischem WLM nicht verfügbar. 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.

Die maximale Zeit, in Millisekunden, für die Abfragen ausgeführt werden können, bevor sie abgebrochen werden. In einigen Fällen wird eine schreibgeschützte Abfrage, z. B. eine SELECT-Anweisung, aufgrund einer WLM-Zeitüberschreitung abgebrochen. In diesen Fällen versucht WLM, die Abfrage auf Grundlage der WLM-Warteschlangenzuweisungsregeln an die nächste übereinstimmende Warteschlange weiterzuleiten. Wenn die Abfrage keiner anderen Warteschlangendefinition entspricht, wird sie abgebrochen und nicht der Standardwarteschlange zugewiesen. Weitere Informationen finden Sie unter WLM-Abfragewarteschlangen-Hopping. Das WLM-Timeout gilt nicht für eine Abfrage, die den Status returning erreicht hat. Den Status einer Abfrage finden Sie in der Systemtabelle STV_WLM_QUERY_STATE.

JSON-Eigenschaft: max_execution_time

Memory (%) (Arbeitsspeicher)

Der Prozentsatz des Speicherplatzes, der der Warteschlange zuzuweisen ist. Wenn Sie für mindestens eine der Warteschlangen einen Speicherprozentsatz festlegen, müssen Sie einen Prozentsatz für alle weiteren Warteschlangen bis zu einem Gesamtwert von 100 Prozent angeben. Wenn die Speicherzuweisung für alle Warteschlangen unter 100 Prozent liegt, wird der nicht zugewiesene Speicher vom Service verwaltet. Der Service kann den nicht zugewiesenen Speicher vorübergehend der Warteschlange zur Verfügung stellen, die zusätzlichen Speicher zur Verarbeitung benötigt.

JSON-Eigenschaft: memory_percent_to_use

Query Monitoring Rules (Abfrageüberwachungsregeln)

Mit WLM-Abfrageüberwachungsregeln können Sie Ihre WLM-Warteschlangen kontinuierlich auf der Grundlage von Kriterien bzw. Prädikaten, die Sie angeben, auf Abfragen überwachen. Sie können beispielsweise Abfragen überwachen, die dazu neigen, ein Übermaß an Systemressourcen zu beanspruchen, und dann eine angegebene Aktion initiieren, wenn eine Anfrage die von Ihnen angegebenen Leistungsgrenzen verletzt.

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.

Sie weisen eine Abfrageüberwachungsregel einer bestimmten Abfragewarteschlange zu. Sie können bis zu 25 Regeln pro Warteschlange und insgesamt 25 Regeln für alle Warteschlangen festlegen.

JSON-Eigenschaft: rules

Hierarchie der JSON-Eigenschaften:

rules
    rule_name
    predicate
        metric_name
        operator
        value
    action
        value

Für jede Regel geben Sie die folgenden Eigenschaften an:

• rule_name – Regelnamen müssen innerhalb einer 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.

  • predicate – Sie können bis zu drei Prädikate pro Regel verwenden. Für jedes Prädikat geben Sie die folgenden Eigenschaften an.

    • metric_name – Eine Liste der Metriken finden Sie unter Abfrageüberwachungsmetriken im Datenbankentwicklerhandbuch zu Amazon Redshift.

    • operator – Vorgänge sind =, < und >.

    • value – Der Schwellenwert für die angegebene Metrik, der eine Aktion auslöst.

• action – Jede Regel ist einer einzigen Aktion zugeordnet. Gültige Aktionen sind:

  • log

  • hop (nur bei Verwendung von manuellem WLM verfügbar)

  • abort

  • change_query_priority (nur bei Verwendung von automatischem WLM verfügbar)

Das folgende Beispiel zeigt den JSON-Code für eine WLM-Abfrageüberwachungsregel mit der Bezeichnung rule_1, mit zwei Prädikaten und der Aktion hop.

"rules": [
          {
            "rule_name": "rule_1",
            "predicate": [
              {
                "metric_name": "query_execution_time",
                "operator": ">",
                "value": 100000
              },
              {
                "metric_name": "query_blocks_read",
                "operator": ">",
                "value": 1000
              }
            ],
            "action": "hop"
          }
        ]

Weitere Informationen zu den einzelnen Eigenschaften und Strategien für die Konfiguration von Abfragewarteschlangen finden Sie unter Implementierung von Workload Management im Datenbankentwicklerhandbuch zu Amazon Redshift.

Konfiguration des Parameters wlm_json_configuration mit dem AWS CLI

Zur Konfiguration von WLM modifizieren Sie den Parameter wlm_json_configuration. Die maximale Größe des wlm_json_configuration-Eigenschaftswerts beträgt 8 000 Zeichen. Der Wert ist in Object Notation (JSON) formatiert JavaScript . Wenn Sie WLM mithilfe der AWS CLI Amazon Redshift Redshift-API oder eines der AWS SDKs konfigurieren, erfahren Sie im Rest dieses Abschnitts, wie Sie die JSON-Struktur für den Parameter erstellen. wlm_json_configuration

Anmerkung

Wenn Sie WLM mit der Amazon-Redshift-Konsole konfigurieren, müssen Sie nicht mit der JSON-Formatierung vertraut sein, da die Konsole eine einfache Möglichkeit zum Hinzufügen von Warteschlangen und zur Konfiguration ihrer Eigenschaften bietet. Weitere Informationen zur Konfiguration von WLM mit der Konsole finden Sie unter Modifizieren einer Parametergruppe.

Beispiel

Das folgende Beispiel ist die WLM-Standardkonfiguration, die eine Warteschlange mit automatischem WLM definiert.

{
   "auto_wlm": true
}

Beispiel

Das folgende Beispiel ist eine benutzerdefinierte WLM-Konfiguration, die eine manuelle WLM-Warteschlange mit der Nebenläufigkeitsstufe fünf (Abfrageslots) definiert.

{
   "query_concurrency":5
}

Syntax

Die Standard-WLM-Konfiguration ist sehr einfach, mit nur einer Warteschlange und einer Eigenschaft. Sie können weitere Warteschlangen hinzufügen und für jede Warteschlange in der JSON-Struktur mehrere Eigenschaften konfigurieren. Die folgende Syntax zeigt die JSON-Struktur, die Sie für die Konfiguration mehrerer Warteschlangen mit mehreren Eigenschaften verwenden:

[
   {
      "ParameterName":"wlm_json_configuration", "ParameterValue":
         "[
             {
                "q1_first_property_name":"q1_first_property_value",
                "q1_second_property_name":"q1_second_property_value", 
                ...
             },
             {
                "q2_first_property_name":"q2_first_property_value",
                "q2_second_property_name":"q2_second_property_value", 
                ...
             }
             ...

         ]"
   }
]

Im vorherigen Beispiel sind die repräsentativen Eigenschaften, die mit q1 beginnen, Objekte in einem Array für die erste Warteschlange. Jedes dieser Objekte ist ein Name-/Wert-Paar; name und value richten gemeinsam die WLM-Eigenschaften für die erste Warteschlange ein. Die repräsentativen Eigenschaften, die mit q2 beginnen, sind Objekte in einem Array für die zweite Warteschlange. Wenn Sie mehr Warteschlangen benötigen, fügen Sie ein weiteres Array für jede weitere Warteschlange hinzu und richten die Eigenschaften für jedes Objekt ein.

Wenn Sie die WLM-Konfiguration modifizieren, müssen Sie die gesamte Struktur für Ihre Warteschlangen einschließen, selbst wenn Sie nur eine Eigenschaft in einer Warteschlange ändern möchten. Der Grund dafür ist, dass die gesamte JSON-Struktur als Zeichenfolge als Wert für den Parameter wlm_json_configuration übergeben wird.

Formatieren des AWS CLI -Befehls

Der Parameter wlm_json_configuration muss ein spezifisches Format haben, wenn Sie die AWS CLI verwenden. Das verwendete Format hängt von Ihrem Client-Betriebssystem ab. Betriebssysteme schließen die JSON-Struktur auf unterschiedliche Weise ein, damit sie korrekt von der Befehlszeile übergeben wird. Für Einzelheiten zur Konstruktion des korrekten Befehls unter Linux, Mac OS X und Windows vgl. die folgenden Abschnitte. Weitere Informationen zu den Unterschieden beim Einschließen von JSON-Datenstrukturen im Allgemeinen finden Sie unter Zeichenketten AWS CLI in Anführungszeichen setzen im Benutzerhandbuch.AWS Command Line Interface

Beispiele

Mit dem folgenden Beispielbefehl wird für eine Parametergruppe mit dem Namen example-parameter-group manuelles WLM konfiguriert. Die Konfiguration lässt die Beschleunigung für kurze Abfragen mit einer maximalen Laufzeit von 0 Sekunden zu. Dadurch wird WLM angewiesen, den Wert dynamisch festzulegen. Die ApplyType-Einstellung lautet dynamic. Diese Einstellung bedeutet, dass alle an dynamischen Eigenschaften in dem Parameter vorgenommenen Änderungen sofort angewendet werden, sofern keine anderen statischen Änderungen an der Konfiguration vorgenommen wurden. Die Konfiguration definiert drei Warteschlangen mit:

• Die erste Warteschlange ermöglicht Benutzern, report als Beschriftung (wie in der Eigenschaft query_group angegeben) in ihren Abfragen anzugeben, um die Abfragen leichter zu dieser Warteschlange weiterleiten zu können. Platzhaltersuchen sind für die Beschriftung report* aktiviert, so dass die Beschriftung nicht exakt sein muss, damit Abfragen zur Warteschlange geleitet werden. Beispielsweise entsprechen sowohl reports als auch reporting dieser Abfragegruppe. Der Warteschlange sind 25 Prozent des gesamten Speicherplatzes für alle Warteschlangen zugewiesen, und es können bis zu vier Abfragen gleichzeitig ausgeführt werden. Abfragen sind auf eine maximale Ausführungszeit von 20 000 Millisekunden (ms) begrenzt. Der Modus ist auf automatisch festgelegt. Berechtigte Abfragen werden daher an ein Skalierungs-Cluster gesendet, wenn die Abfrage-Slots der Warteschlange gefüllt sind.

• Die zweite Warteschlange ermöglicht Benutzern, die Mitglieder der Gruppe admin oder dba in der Datenbank sind, ihre Abfragen zur Verarbeitung zu der Warteschlange weiterzuleiten. Platzhaltersuchen sind für Benutzergruppen deaktiviert, die Benutzer müssen daher exakt Gruppen in der Datenbank entsprechen, damit ihre Abfragen zu der Warteschlange geleitet werden. Der Warteschlange werden 40 Prozent des gesamten Speicherplatzes für alle Warteschlangen zugeteilt. Sie kann bis zu fünf Abfragen gleichzeitig ausführen. Der Modus ist auf „Off“ (Aus) festgelegt. Daher werden alle Abfragen, die von Mitgliedern der Administrator- oder DBA-Gruppe gesendet werden, auf dem Haupt-Cluster ausgeführt.

• Die letzte Warteschlange in der Konfiguration ist die Standard-Warteschlange. Dieser Warteschlange sind 35 Prozent des gesamten Speicherplatzes für alle Warteschlangen zugewiesen. Sie kann bis zu fünf Abfragen gleichzeitig verarbeiten. Der Modus ist auf „Auto“ (Automatisch) festgelegt.

Anmerkung

Das Beispiel wird zu Demonstrationszwecken auf mehreren Zeilen angezeigt. Die tatsächlichen Befehle haben jedoch keine Zeilenumbrüche.

aws redshift modify-cluster-parameter-group 
--parameter-group-name example-parameter-group 
--parameters
'[
  {
    "query_concurrency": 4,
    "max_execution_time": 20000,
    "memory_percent_to_use": 25,
    "query_group": ["report"],
    "query_group_wild_card": 1,
    "user_group": [],
    "user_group_wild_card": 0,
    "user_role": [],
    "user_role_wild_card": 0,
    "concurrency_scaling": "auto", 
    "queue_type": "manual"
  },
  {
    "query_concurrency": 5,
    "memory_percent_to_use": 40,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [
      "admin",
      "dba"
    ],
    "user_group_wild_card": 0,
    "user_role": [],
    "user_role_wild_card": 0,
    "concurrency_scaling": "off",
    "queue_type": "manual"    
  },
  {
    "query_concurrency": 5,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [],
    "user_group_wild_card": 0,
    "user_role": [],
    "user_role_wild_card": 0,
    "concurrency_scaling": "auto",
    "queue_type": "manual"    
  },
  {"short_query_queue": true}
]'

Im Folgenden sehen Sie ein Beispiel für die Konfiguration von WLM-Abfrageüberwachungsregeln für eine automatische WLM-Konfiguration. In diesem Beispiel wird eine Parametergruppe mit dem Namen example-monitoring-rules erstellt. Die Konfiguration definiert die gleichen drei Warteschlangen wie im vorherigen Beispiel. query_concurrency und memory_percent_to_use werden jedoch nicht mehr angegeben. Die Konfiguration fügt darüber hinaus die folgenden Regeln und Abfrageprioritäten hinzu:

• Die erste Warteschlange definiert eine Regel mit der Bezeichnung rule_1. Die Regel hat zwei Prädikate: query_cpu_time > 10000000 und query_blocks_read > 1000. Die Regelaktion ist log . Diese Warteschlange hat die Priorität Normal.

• Die zweite Warteschlange definiert eine Regel mit dem Namen rule_2. Die Regel hat zwei Prädikate: query_execution_time > 600000000 und scan_row_count > 1000000000. Die Regelaktion ist abort . Diese Warteschlange hat die Priorität Highest.

• Die letzte Warteschlange in der Konfiguration ist die Standard-Warteschlange. Diese Warteschlange hat die Priorität Low.

Anmerkung

Das Beispiel wird zu Demonstrationszwecken auf mehreren Zeilen angezeigt. Die tatsächlichen Befehle haben jedoch keine Zeilenumbrüche.

aws redshift modify-cluster-parameter-group 
--parameter-group-name example-monitoring-rules 
--parameters
'[ {
  "query_group" : [ "report" ],
  "query_group_wild_card" : 1,
  "user_group" : [ ],
  "user_group_wild_card" : 0,
  "user_role": [ ],
  "user_role_wild_card": 0,
  "concurrency_scaling" : "auto",
  "rules" : [{
    "rule_name": "rule_1",
    "predicate": [{
      "metric_name": "query_cpu_time",
      "operator": ">",
      "value": 1000000 },
      { "metric_name": "query_blocks_read",
      "operator": ">",
      "value": 1000
    } ],
    "action" : "log"
  } ],
   "priority": "normal",
   "queue_type": "auto"
}, {  
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ "admin", "dba" ],
  "user_group_wild_card" : 0,
  "user_role": [ ],
  "user_role_wild_card": 0,
  "concurrency_scaling" : "off",
  "rules" : [ {
    "rule_name": "rule_2",
    "predicate": [
      {"metric_name": "query_execution_time",
      "operator": ">",
      "value": 600000000},
      {"metric_name": "scan_row_count",
      "operator": ">",
      "value": 1000000000}],
      "action": "abort"}],
   "priority": "high",
   "queue_type": "auto"

}, {
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ ],
  "user_group_wild_card" : 0,
  "user_role": [ ],
  "user_role_wild_card": 0,
  "concurrency_scaling" : "auto",
  "priority": "low",
  "queue_type": "auto",
  "auto_wlm": true
}, {
  "short_query_queue" : true
} ]'

Konfiguration von WLM mithilfe von AWS CLI in der Befehlszeile mit einer JSON-Datei

Sie können den wlm_json_configuration Parameter mit dem ändern AWS CLI und den Wert des parameters Arguments als JSON-Datei übergeben.

aws redshift modify-cluster-parameter-group --parameter-group-name myclusterparaametergroup --parameters file://modify_pg.json 

Die Argumente für --parameters werden in der Datei modify_pg.json gespeichert: Der Speicherort der Datei wird in dem Format für Ihr Betriebssystem angegeben. Weitere Informationen finden Sie unter Laden von Parametern aus einer Datei. Es folgen Beispiele für den Inhalt der JSON–Datei modify_pg.json.

[
    {
        "ParameterName": "wlm_json_configuration",
        "ParameterValue": "[{\"user_group\":\"example_user_group1\",\"query_group\": \"example_query_group1\", \"query_concurrency\":7},{\"query_concurrency\":5}]"
    }
]                        

[
    {
        "ParameterName": "wlm_json_configuration",
        "ParameterValue": "[{\"query_group\":[\"reports\"],\"query_group_wild_card\":0,\"query_concurrency\":4,\"max_execution_time\":20000,\"memory_percent_to_use\":25},{\"user_group\":[\"admin\",\"dba\"],\"user_group_wild_card\":1,\"query_concurrency\":5,\"memory_percent_to_use\":40},{\"query_concurrency\":5,\"memory_percent_to_use\":35},{\"short_query_queue\": true, \"max_execution_time\": 5000 }]",
        "ApplyType": "dynamic"
    }
]            

Regeln für die Konfiguration von WLM mithilfe der AWS CLI in der Befehlszeile auf den Betriebssystemen Linux und MacOS X

Folgen Sie diesen Regeln, um einen AWS CLI Befehl mit Parametern in einer Zeile auszuführen:

• Die gesamte JSON-Struktur muss in einfache Anführungszeichen (') und einem Satz Klammern ([ ]) eingeschlossen werden.

• Alle Parameternamen und Parameterwerte müssen in doppelte Anführungszeichen (") eingeschlossen werden.

• Innerhalb des ParameterValue-Werts müssen Sie die gesamte eingebettete Struktur in doppelte Anführungszeichen (") und Klammern ([ ]) einschließen.

• Innerhalb der eingebetteten Struktur müssen alle Eigenschaften und Werte für jede Warteschlange in geschweifte Klammern ({ }) eingeschlossen werden.

• Innerhalb der eingebetteten Struktur müssen Sie den umgekehrten Schrägstrich (\) als Escape-Zeichen vor jedem doppelten Anführungszeichen (") verwenden.

• Für Name-/Wert-Paare trennt ein Doppelpunkt (:) jede Eigenschaft von ihrem Wert.

• Alle Name-/Wert-Paare werden voneinander durch Kommata (,) getrennt.

• Mehrere Warteschlangen werden durch ein Komma (,) zwischen der schließenden geschweiften Klammer einer Warteschlange (}) und der öffnenden geschweiften Klammer der nächsten Warteschlange getrennt.

Regeln für die Konfiguration von WLM mithilfe von AWS CLI in Windows PowerShell auf Microsoft Windows-Betriebssystemen

Folgen Sie diesen Regeln, um einen AWS CLI Befehl mit Parametern in einer Zeile auszuführen:

• Die gesamte JSON-Struktur muss in einfache Anführungszeichen (') und einem Satz Klammern ([ ]) eingeschlossen werden.

• Alle Parameternamen und Parameterwerte müssen in doppelte Anführungszeichen (") eingeschlossen werden.

• Innerhalb des ParameterValue-Werts müssen Sie die gesamte eingebettete Struktur in doppelte Anführungszeichen (") und Klammern ([ ]) einschließen.

• Innerhalb der eingebetteten Struktur müssen alle Eigenschaften und Werte für jede Warteschlange in geschweifte Klammern ({ }) eingeschlossen werden.

• Innerhalb der eingebetteten Struktur müssen Sie den umgekehrten Schrägstrich (\) als Escape-Zeichen vor jedem doppelten Anführungszeichen (") und dessen Escape-Zeichen (umgekehrter Schrägstrich (\)) verwenden. Dies bedeutet, dass Sie drei umgekehrte Schrägstriche und ein doppeltes Anführungszeichen verwenden müssen, um sicherzustellen, dass die Eigenschaften korrekt übergeben werden („\\\“).

• Für Name-/Wert-Paare trennt ein Doppelpunkt (:) jede Eigenschaft von ihrem Wert.

• Alle Name-/Wert-Paare werden voneinander durch Kommata (,) getrennt.

• Mehrere Warteschlangen werden durch ein Komma (,) zwischen der schließenden geschweiften Klammer einer Warteschlange (}) und der öffnenden geschweiften Klammer der nächsten Warteschlange getrennt.

Regeln für die Konfiguration von WLM mit der Befehlszeile in Windows-Betriebssystemen

Folgen Sie diesen Regeln, um einen AWS CLI Befehl mit Parametern in einer Zeile auszuführen:

• Die gesamte JSON-Struktur muss in doppelte Anführungszeichen (") und einem Satz Klammern ([ ]) eingeschlossen werden.

• Alle Parameternamen und Parameterwerte müssen in doppelte Anführungszeichen (") eingeschlossen werden.

• Innerhalb des ParameterValue-Werts müssen Sie die gesamte eingebettete Struktur in doppelte Anführungszeichen (") und Klammern ([ ]) einschließen.

• Innerhalb der eingebetteten Struktur müssen alle Eigenschaften und Werte für jede Warteschlange in geschweifte Klammern ({ }) eingeschlossen werden.

• Innerhalb der eingebetteten Struktur müssen Sie den umgekehrten Schrägstrich (\) als Escape-Zeichen vor jedem doppelten Anführungszeichen (") und dessen Escape-Zeichen (umgekehrter Schrägstrich (\)) verwenden. Dies bedeutet, dass Sie drei umgekehrte Schrägstriche und ein doppeltes Anführungszeichen verwenden müssen, um sicherzustellen, dass die Eigenschaften korrekt übergeben werden („\\\“).

• Für Name-/Wert-Paare trennt ein Doppelpunkt (:) jede Eigenschaft von ihrem Wert.

• Alle Name-/Wert-Paare werden voneinander durch Kommata (,) getrennt.

• Mehrere Warteschlangen werden durch ein Komma (,) zwischen der schließenden geschweiften Klammer einer Warteschlange (}) und der öffnenden geschweiften Klammer der nächsten Warteschlange getrennt.