Tutorial: Warteschlangen für manuelles Workload-Management (WLM) konfigurieren - Amazon Redshift
ÜbersichtAbschnitt 1: Erläuterung des standardmäßigen Verhaltens der WarteschlangenverarbeitungAbschnitt 2: Ändern der Konfiguration der WLM AbfragewarteschlangeAbschnitt 3: Weiterleiten von Abfragen zu Warteschlangen auf der Grundlage von Benutzergruppen und AbfragegruppenAbschnitt 4: Verwenden von wlm_query_slot_count zur temporären Übergehung der Gleichzeitigkeitsstufe in einer WarteschlangeAbschnitt 5: Bereinigen Ihrer Ressourcen

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.

Tutorial: Warteschlangen für manuelles Workload-Management (WLM) konfigurieren

Mit Amazon Redshift können Sie Warteschlangen für manuelles Workload-Management (WLM) konfigurieren, um Ressourcen für verschiedene Arten von Abfragen und Benutzern zu priorisieren und zuzuweisen. Manuelle WLM Warteschlangen ermöglichen es Ihnen, die Speicher- und Parallelitätseinstellungen für bestimmte Warteschlangen zu kontrollieren und so sicherzustellen, dass kritische Workloads die erforderlichen Ressourcen erhalten, während gleichzeitig verhindert wird, dass Abfragen mit niedriger Priorität das System monopolisieren. Die folgenden Abschnitte führen Sie durch den Prozess der Erstellung und Konfiguration manueller WLM Warteschlangen in Amazon Redshift, um Ihre Workload-Management-Anforderungen zu erfüllen.

Übersicht

Wir empfehlen, automatisches Workload-Management (WLM) in Amazon Redshift zu konfigurieren. Weitere Informationen zur automatischen Funktion finden Sie WLM unterWorkload-Management. Wenn Sie jedoch mehrere WLM Warteschlangen benötigen, führt Sie dieses Tutorial durch den Prozess der Konfiguration der manuellen Arbeitslastverwaltung (WLM) in Amazon Redshift. Durch die manuelle WLM Konfiguration können Sie die Abfrageleistung und die Ressourcenzuweisung in Ihrem Cluster verbessern.

Amazon Redshift leitet Benutzerabfragen zur Verarbeitung an Warteschlangen weiter. WLMdefiniert, wie diese Abfragen an die Warteschlangen weitergeleitet werden. Standardmäßig hat Amazon Redshift zwei Warteschlangen für Abfragen: eine für Superuser und eine für (normale) Benutzer. Die Superuser-Warteschlange kann nicht konfiguriert werden und verarbeitet jeweils nur eine Abfrage zur gleichen Zeit. Sie sollten diese Warteschlange nur für Fehlerbehebungszwecke reservieren. Die Benutzerwarteschlange kann bis zu fünf Abfragen gleichzeitig verarbeiten, Sie können dies jedoch konfigurieren, indem Sie bei Bedarf die Gleichzeitigkeitsstufe der Warteschlange ändern.

Wenn mehrere Benutzer Abfragen gegen die Datenbank ausführen, kann es sein, dass eine andere Konfiguration effizienter ist. Wenn einige Benutzer beispielsweise ressourcenintensive Operationen ausführen, können sich diese negativ auf weniger intensive Abfragen wie VACUUM Berichte auswirken. Si sollten dann vielleicht weitere Warteschlangen hinzufügen und diese für unterschiedliche Workloads konfigurieren.

Geschätzte Zeit: 75 Minuten

Geschätzte Kosten: 50 Cent

Voraussetzungen

Sie benötigen einen Amazon Redshift Redshift-Cluster, die TICKIT Beispieldatenbank und das Amazon Redshift RSQL Redshift-Client-Tool. Falls Sie diese noch nicht eingerichtet haben, gehen Sie zu Amazon Redshift Getting Started Guide und Amazon RSQL Redshift.

Sections

Abschnitt 1: Erläuterung des standardmäßigen Verhaltens der Warteschlangenverarbeitung

Bevor Sie mit der manuellen Konfiguration beginnenWLM, ist es hilfreich, das Standardverhalten der Warteschlangenverarbeitung in Amazon Redshift zu verstehen. In diesem Abschnitt erstellen Sie zwei Datenbankansichten, die Informationen aus verschiedenen Systemtabellen zurückgeben. Dann führen Sie einige Testabfragen aus, um zu sehen, wie Abfragen standardmäßig weitergeleitet werden. Weitere Informationen zu Systemtabellen finden Sie unter Referenz zu Systemtabellen und Ansichten.

Schritt 1: Erstellen Sie die WLM _ QUEUE _ STATE _VW-Ansicht

In diesem Schritt erstellen Sie eine Ansicht namens WLM _ QUEUE _ STATE _VW. Diese Ansicht gibt Informationen aus den folgenden Systemtabellen aus.

Sie verwenden diese Ansicht im gesamten Tutorial, um zu überwachen, was mit Warteschlangen passiert, nachdem Sie die WLM Konfiguration geändert haben. In der folgenden Tabelle werden die Daten beschrieben, die die WLM _ QUEUE _ STATE _VW-Ansicht zurückgibt.

Spalte Beschreibung
Warteschlange Die Nummer der Zeile, die für eine Warteschlange steht. Die Warteschlangennummer bestimmt die Reihenfolge der Warteschlangen in der Datenbank.
description Ein Wert, der angibt, ob die Warteschlange nur für bestimmte Benutzergruppen, bestimmte Abfragegruppen oder für alle Arten von Abfragen verfügbar ist.
slots Die Anzahl der der Warteschlange zugewiesenen Slots.
mem Der der Warteschlange zugewiesene Speicherplatz, in MB pro Slot.
max_execution_time Die Zeitspanne, für die eine Abfrage laufen kann, bevor sie beendet wird.
Benutzer_* Ein Wert, der angibt, ob Platzhalterzeichen in der WLM Konfiguration zulässig sind, um Benutzergruppen zu entsprechen.
query_* Ein Wert, der angibt, ob Platzhalterzeichen in der WLM Konfiguration zulässig sind, um Abfragegruppen zu entsprechen.
queued Die Anzahl der Abfragen, die in der Warteschlange auf ihre Verarbeitung warten.
executing Die Anzahl der Abfragen, die derzeit ausgeführt werden.
executed Die Anzahl der Abfragen, die ausgeführt wurden.

Um die WLM _ QUEUE _ STATE _VW-Ansicht zu erstellen

  1. Öffnen Sie Amazon Redshift RSQL und stellen Sie eine Verbindung zu Ihrer TICKIT Beispieldatenbank her. Wenn Sie diese Datenbank nicht haben, finden Sie weitere Informationen unter Voraussetzungen.

  2. Führen Sie die folgende Abfrage aus, um die WLM _ QUEUE _ STATE _VW-Ansicht zu erstellen.

    create view WLM_QUEUE_STATE_VW as
select (config.service_class-5) as queue
, trim (class.condition) as description
, config.num_query_tasks as slots
, config.query_working_mem as mem
, config.max_execution_time as max_time
, config.user_group_wild_card as "user_*"
, config.query_group_wild_card as "query_*"
, state.num_queued_queries queued
, state.num_executing_queries executing
, state.num_executed_queries executed
from
STV_WLM_CLASSIFICATION_CONFIG class,
STV_WLM_SERVICE_CLASS_CONFIG config,
STV_WLM_SERVICE_CLASS_STATE state
where
class.action_service_class = config.service_class 
and class.action_service_class = state.service_class 
and config.service_class > 4
order by config.service_class;

  3. Führen Sie die folgende Abfrage aus, um die Informationen in der Ansicht anzuzeigen.

    select * from wlm_queue_state_vw;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         1 |      160

Schritt 2: Erstellen Sie die WLM _ QUERY _ STATE _VW-Ansicht

In diesem Schritt erstellen Sie eine Ansicht namens WLM _ QUERY _ STATE _VW. Diese Ansicht gibt Informationen aus der Systemtabelle STV_WLM_QUERY_STATE aus.

Sie verwenden diese Ansicht während des gesamten Tutorials zur Überwachung der laufenden Abfragen. In der folgenden Tabelle werden die Daten beschrieben, die von der Ansicht WLM _ QUERY _ STATE _VW zurückgegeben werden.

Spalte Beschreibung
query Die Abfrage-ID.
Warteschlange Die Nummer der Warteschlange.
slot_count Die Anzahl der der Abfrage zugewiesenen Slots.
start_time Der Zeitpunkt des Beginns der Abfrage.
state Der Status der Abfrage, etwa „executing“.
queue_time Die Anzahl der Mikrosekunden, die die Abfrage in der Warteschlange verbracht hat.
exec_time Die Anzahl der Mikrosekunden, seitdem die Abfrage in die Warteschlange ausgeführt wird.

Um die WLM _ QUERY _ STATE _VW-Ansicht zu erstellen

  1. Führen Sie in die folgende Abfrage ausRSQL, um die WLM _ QUERY _ STATE _VW-Ansicht zu erstellen.

    create view WLM_QUERY_STATE_VW as
select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time
from stv_wlm_query_state;

  2. Führen Sie die folgende Abfrage aus, um die Informationen in der Ansicht anzuzeigen.

    select * from wlm_query_state_vw;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 1249 |     1 |          1 | 2014-09-24 22:19:16 | Executing | 0          | 516

Schritt 3: Ausführen von Testabfragen

In diesem Schritt führen Sie Abfragen von mehreren Verbindungen aus RSQL und überprüfen die Systemtabellen, um festzustellen, wie die Abfragen zur Verarbeitung weitergeleitet wurden.

Für diesen Schritt müssen zwei RSQL Fenster geöffnet sein:

  • In RSQL Fenster 1 führen Sie Abfragen aus, die den Status der Warteschlangen überwachen, und Abfragen mithilfe der Ansichten, die Sie bereits in diesem Tutorial erstellt haben.

  • In RSQL Fenster 2 führen Sie Abfragen mit langer Laufzeit aus, um die Ergebnisse zu ändern, die Sie in RSQL Fenster 1 finden.

So führen Sie die Testabfragen aus

  1. Öffnen Sie zwei RSQL Fenster. Wenn Sie bereits ein Fenster geöffnet haben, müssen Sie lediglich ein zweites Fenster öffnen. Sie können für beide Verbindungen dasselbe Benutzerkonto verwenden.

  2. Führen Sie in RSQL Fenster 1 die folgende Abfrage aus.

    select * from wlm_query_state_vw;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 1258 |     1 |          1 | 2014-09-24 22:21:03 | Executing | 0          | 549

    Diese Abfrage gibt ein selbstreferenzielles Ergebnis aus. Die Abfrage, die gerade ausgeführt wird, ist die SELECT Anweisung aus dieser Ansicht. Eine Abfrage in dieser Ansicht gibt immer mindestens ein Ergebnis aus. Vergleichen Sie dieses Ergebnis dann mit dem Ergebnis, das nach dem Start der lang andauernden Abfrage im nächsten Schritt angezeigt wird.

  3. Führen Sie in RSQL Fenster 2 eine Abfrage aus der TICKIT Beispieldatenbank aus. Diese Abfrage sollte ungefähr eine Minute lang ausgeführt werden, sodass Sie Zeit haben, die Ergebnisse der _ _ STATE _VW-Ansicht und der WLM QUEUE _ _ _VW-Ansicht, die WLM Sie STATE zuvor erstellt haben, zu untersuchen. QUERY In manchen Fällen stellen Sie möglicherweise fest, dass die Abfrage nicht lange genug ausgeführt wird, um beide Ansichten abzufragen. In diesen Fällen können Sie den Wert des Filters für l.listid erhöhen, um die Ausführungszeit zu verlängern.

    Anmerkung

    Um die Ausführungszeiten von Abfragen zu reduzieren und die Systemleistung zu verbessern, stellt Amazon Redshift die Ergebnisse bestimmter Abfragen in den Speicher auf dem führenden Knoten. Wenn die Ergebniszwischenspeicherung aktiviert ist, werden nachfolgende Abfragen viel schneller ausgeführt. Um zu verhindern, dass die Abfrage zu schnell ausgeführt wird, deaktivieren Sie die Ergebniszwischenspeicherung für die aktuelle Sitzung.

    Um die Ergebniszwischenspeicherung für die aktuelle Sitzung zu deaktivieren, setzen Sie den Parameter enable_result_cache_for_session wie im Folgenden dargestellt auf off.

    set enable_result_cache_for_session to off;

    Führen Sie in RSQL Fenster 2 die folgende Abfrage aus.

    select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000;

  4. Fragen Sie in RSQL Fenster 1 WLM QUEUE _ STATE _VW und _ WLM QUERY _ STATE _VW ab und vergleichen Sie die Ergebnisse mit Ihren früheren Ergebnissen.

    select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;

    Nachfolgend sehen Sie einige Beispielergebnisse.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         2 |      163
                        
query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 1267 |     1 |          1 | 2014-09-24 22:22:30 | Executing | 0          | 684
 1265 |     1 |          1 | 2014-09-24 22:22:36 | Executing | 0          | 4080859

Beachten Sie die folgenden Unterschiede zwischen Ihren vorherigen Abfragen und den Ergebnissen in diesem Schritt:

  • Es gibt jetzt zwei Zeilen in WLM _ QUERY _ STATE _VW. Ein Ergebnis ist die selbstreferentielle Abfrage zum Ausführen eines SELECT Vorgangs in dieser Ansicht. Das zweite Ergebnis ist das der länger währenden Abfrage aus dem vorherigen Schritt.

  • Die Ausführungsspalte in WLM _ QUEUE _ STATE _VW wurde von 1 auf 2 erhöht. Dieser Spalteneintrag bedeutet, dass derzeit zwei Abfragen in der Warteschlange ausgeführt werden.

  • Der Wert in der Spalte „executed“ wird bei jeder Ausführung einer Abfrage in der Warteschlange erhöht.

Die WLM _ QUEUE _ STATE _VW-Ansicht ist nützlich, um einen Gesamtüberblick über die Warteschlangen und darüber zu erhalten, wie viele Abfragen in jeder Warteschlange verarbeitet werden. Die WLM _ QUERY _ STATE _VW-Ansicht ist nützlich, um einen detaillierteren Überblick über die einzelnen Abfragen zu erhalten, die gerade ausgeführt werden.

Abschnitt 2: Ändern der Konfiguration der WLM Abfragewarteschlange

Nachdem Sie nun verstanden haben, wie Warteschlangen standardmäßig funktionieren, können Sie lernen, wie Sie Abfragewarteschlangen manuell konfigurieren. WLM In diesem Abschnitt erstellen und konfigurieren Sie eine neue Parametergruppe für Ihren Cluster. Sie erstellen zwei zusätzliche Benutzerwarteschlangen und konfigurieren sie so, dass sie Abfragen basierend auf den Bezeichnungen der Benutzergruppe oder der Anfragegruppe der Abfragen entgegennehmen. Alle Anfragen, die nicht an eine dieser beiden Warteschlangen weitergeleitet werden, werden zur Laufzeit an die Standard-Warteschlange weitergeleitet.

So erstellen Sie eine manuelle WLM Konfiguration in einer Parametergruppe

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon Redshift Redshift-Konsole unter https://console.aws.amazon.com/redshiftv2/.

  2. Wählen Sie im Navigationsmenü Configurations (Konfigurationen) und dann Workload management (Workload-Management) aus, um die Seite Workload management (Workload-Management) anzuzeigen.

  3. Wählen Sie Create (Erstellen) aus, um das Fenster Create parameter group (Parametergruppe erstellen) anzuzeigen.

  4. Geben Sie WLMTutorial für Parameter group name (Parametergruppenname) und Beschreibung) ein. Wählen Sie dann Erstellen aus, um die Parametergruppe zu erstellen.

    Anmerkung

    Der Parameter group name (Parametergruppenname) wird beim Erstellen in alle Kleinbuchstaben umgewandelt.

  5. Wählen Sie auf der Seite Workload management (Workload-Management) die Parametergruppe wlmtutorial aus, um die Detailseite mit Registerkarten für Parameters (Parameter) und Workload management (Workload-Management) anzuzeigen.

  6. Vergewissern Sie sich, dass Sie sich auf der Registerkarte Workload-Management befinden, und wählen Sie dann WLMSwitch-Modus, um das Fenster mit den Parallelitätseinstellungen anzuzeigen.

  7. Wählen Sie „Manuell“ WLM und anschließend „Speichern“, um zum manuellen WLM Modus zu wechseln.

  8. Wählen Sie Edit workload queues (Workload-Warteschlangen bearbeiten) aus.

  9. Wählen Sie zweimal Add queue (Warteschlange hinzufügen) aus, um zwei Warteschlangen hinzuzufügen. Jetzt gibt es drei Warteschlangen: Queue 1 (Warteschlange 1), Queue 2 (Warteschlange 2) und Default Queue (Standardwarteschlange).

  10. Geben Sie die Informationen für jede Warteschlange wie folgt ein:

    • Für Queue 1 (Warteschlange 1) geben Sie 30 für Memory (%) (Arbeitsspeicher (%)), 2 für Concurrency on main (Gleichzeitigkeit auf dem Haupt-Cluster) und test für Query groups (Abfragegruppen) ein. Übernehmen Sie für die anderen Einstellungen die eingestellten Standardwerte.

    • Für Queue 2 (Warteschlange 2) geben Sie 40 für Memory (%) (Arbeitsspeicher (%)), 3 für Concurrency on main (Gleichzeitigkeit auf dem Haupt-Cluster) und admin für User groups (Benutzergruppen) ein. Übernehmen Sie für die anderen Einstellungen die eingestellten Standardwerte.

    • Nehmen Sie unter Default queue (Standardwarteschlange) keine Änderungen vor. WLMweist der Standardwarteschlange nicht zugewiesenen Speicher zu.

  11. Wählen Sie Save, um Ihre Einstellungen zu speichern.

Ordnen Sie als Nächstes die Parametergruppe mit der manuellen WLM Konfiguration einem Cluster zu.

Um eine Parametergruppe mit einer manuellen WLM Konfiguration einem Cluster zuzuordnen

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon Redshift Redshift-Konsole unter https://console.aws.amazon.com/redshiftv2/.

  2. Wählen Sie im Navigationsmenü die Option Clusters (Cluster) und dann erneut Clusters (Cluster) aus, um eine Liste Ihrer Cluster anzuzeigen.

  3. Wählen Sie Ihren Cluster aus, z. B. examplecluster, um die Details zum Cluster anzuzeigen. Wählen Sie dann die Registerkarte Properties (Eigenschaften) aus, um die Cluster-Eigenschaften anzuzeigen.

  4. Wählen Sie im Abschnitt Database configurations (Datenbankkonfigurationen) Edit (Bearbeiten), Edit parameter group (Parametergruppe bearbeiten) aus, um das Parametergruppenfenster zu öffnen.

  5. Wählen Sie unter Parameter groups (Parametergruppen) die Parametergruppe wlmtutorial aus, die Sie zuvor erstellt haben.

  6. Klicken Sie auf Save changes (Änderungen speichern), um die Parametergruppe zuzuordnen.

    Der Cluster wird mit der geänderten Parametergruppe modifiziert. Sie müssen jedoch den Cluster neu starten, damit die Änderungen auch auf die Datenbank angewendet werden können.

  7. Wählen Sie Ihren Cluster aus und wählen Sie dann Reboot (Neu starten) für Actions (Aktionen) aus.

Nachdem der Cluster neu gestartet wurde, kehrt sein Status zu Available (Verfügbar) zurück.

Abschnitt 3: Weiterleiten von Abfragen zu Warteschlangen auf der Grundlage von Benutzergruppen und Abfragegruppen

Jetzt haben Sie Ihren Cluster mit einer neuen Parametergruppe verknüpft und konfiguriertWLM. Führen Sie als Nächstes ein paar Abfragen aus, um zu sehen, wie Amazon Redshift Abfragen zur Bearbeitung in Warteschlangen weiterleitet.

Schritt 1: Anzeigen der Konfiguration der Abfragewarteschlange in der Datenbank

Stellen Sie zunächst sicher, dass die Datenbank die von Ihnen erwartete WLM Konfiguration hat.

So zeigen Sie die Konfiguration der Abfragewarteschlange an

  1. Öffnen Sie die folgende Abfrage RSQL und führen Sie sie aus. Die Abfrage verwendet die WLM _ QUEUE _ STATE _VW-Ansicht, in Schritt 1: Erstellen Sie die WLM _ QUEUE _ STATE _VW-Ansicht der Sie sie erstellt haben. Wenn vor dem Neustart des Clusters bereits eine Sitzung mit der Datenbank verbunden war, müssen Sie die Verbindung erneut herstellen.

    select * from wlm_queue_state_vw;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        0
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0

    Vergleichen Sie die Ergebnisse mit denen in Schritt 1: Erstellen Sie die WLM _ QUEUE _ STATE _VW-Ansicht. Beachten Sie, dass jetzt zwei weitere Warteschlangen vorhanden sind. Warteschlange 1 ist jetzt die Warteschlange für die Testabfragegruppe, und Warteschlange 2 ist die Warteschlange für die Admin User-Gruppe.

    Warteschlange 3 ist jetzt die Standardwarteschlange. Die letzte Warteschlange in der Liste ist immer die Standardwarteschlange. Dies ist die Warteschlange, zu der Abfragen standardmäßig weitergeleitet werden, wenn in einer Abfrage keine Benutzergruppe oder Abfragegruppe angegeben ist.

  2. Führen Sie die folgende Abfrage aus, um zu bestätigen, dass Ihre Abfrage jetzt in Warteschlange 3 ausgeführt wird.

    select * from wlm_query_state_vw;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 2144 |     3 |          1 | 2014-09-24 23:49:59 | Executing | 0          | 550430

Schritt 2: Ausführen einer Abfrage mit der Abfragegruppenwarteschlange

So führen Sie eine Abfrage mit der Abfragegruppenwarteschlange aus

  1. Führen Sie die folgende Abfrage aus, um sie zur Abfragegruppe test weiterzuleiten.

    set query_group to test;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

  2. Führen Sie im anderen RSQL Fenster die folgende Abfrage aus.

    select * from wlm_query_state_vw;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 2168 |     1 |          1 | 2014-09-24 23:54:18 | Executing | 0          | 6343309
 2170 |     3 |          1 | 2014-09-24 23:54:24 | Executing | 0          | 847

    Die Abfrage wurde zur Testabfragegruppe geleitet; dies ist jetzt Warteschlange 1.

  3. Wählen Sie in der Ansicht des Warteschlangenzustands alle aus.

    select * from wlm_queue_state_vw;

    Das Ergebnis sieht in etwa wie folgt aus.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        0
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0

  4. Setzen Sie jetzt die Abfragegruppe zurück, und führen Sie die lange Abfrage erneut aus:

    reset query_group;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

  5. Führen Sie die Abfragen gegen die Ansichten aus, um die Ergebnisse zu sehen.

    select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;

    Nachfolgend sehen Sie einige Beispielergebnisse.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         2 |        5
 
query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 2186 |     3 |          1 | 2014-09-24 23:57:52 | Executing | 0          | 649
 2184 |     3 |          1 | 2014-09-24 23:57:48 | Executing | 0          | 4137349

    Das Ergebnis sollte sein, dass die Abfrage jetzt wieder in Warteschlange 3 ausgeführt wird.

Schritt 3: Erstellen eines Datenbankbenutzers und einer Benutzergruppe

Bevor Sie in dieser Warteschlange Abfragen ausführen können, müssen Sie die Benutzergruppe in der Datenbank erstellen und ihr einen Benutzer hinzufügen. Dann melden Sie sich mit den RSQL Anmeldeinformationen des neuen Benutzers an und führen Abfragen aus. Um Datenbankbenutzer zu erstellen, müssen Sie Abfragen als Superuser (etwa als „admin user“) ausführen.

So erstellen Sie einen neuen Datenbankbenutzer und eine Benutzergruppe

  1. Erstellen Sie in der Datenbank einen neuen Datenbankbenutzer mit dem Namen, adminwlm indem Sie den folgenden Befehl in einem RSQL Fenster ausführen.

    create user adminwlm createuser password '123Admin';

  2. Führen Sie dann die folgenden Befehl aus, um die neue Benutzergruppe zu erstellen und den neuen Benutzer adminwlm hinzuzufügen.

    create group admin;
alter group admin add user adminwlm;

Schritt 4: Ausführen einer Abfrage mit der Benutzergruppenwarteschlange

Führen Sie als Nächstes eine Abfrage aus und leiten Sie sie zur Benutzergruppenwarteschlange weiter. Sie tun dies, wenn Sie Ihre Abfrage zu einer Warteschlange weiterleiten möchten, die für die Bearbeitung der Art der auszuführenden Abfrage konfiguriert ist.

So führen Sie eine Abfrage mit der Benutzergruppenwarteschlange aus

  1. Führen Sie in RSQL Fenster 2 die folgenden Abfragen aus, um zu dem adminwlm Konto zu wechseln, und führen Sie eine Abfrage als dieser Benutzer aus.

    set session authorization 'adminwlm';
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

  2. Führen Sie in RSQL Fenster 1 die folgende Abfrage aus, um die Abfragewarteschlange zu sehen, an die die Abfragen weitergeleitet werden.

    select * from wlm_query_state_vw;
select * from wlm_queue_state_vw;

    Nachfolgend sehen Sie einige Beispielergebnisse.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        0
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        8
 
query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 2202 |     2 |          1 | 2014-09-25 00:01:38 | Executing | 0          | 4885796
 2204 |     3 |          1 | 2014-09-25 00:01:43 | Executing | 0          | 650

    Die Warteschlange, in der diese Abfrage ausgeführt wurde, ist Warteschlange 2, die Warteschlange für admin-Benutzer. Immer wenn Sie als dieser Benutzer Abfragen ausführen, werden diese in Warteschlange 2 ausgeführt, sofern Sie nicht eine andere Abfragegruppe zur Verwendung angeben. Die ausgewählte Warteschlange ist abhängig von den Zuweisungsregeln für Warteschlangen. Weitere Informationen finden Sie unter WLMRegeln für die Warteschlangenzuweisung.

  3. Führen Sie nun die folgende Abfrage in RSQL Fenster 2 aus.

    set query_group to test;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

  4. Führen Sie in RSQL Fenster 1 die folgende Abfrage aus, um die Abfragewarteschlange zu sehen, an die die Abfragen weitergeleitet werden.

    select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;

    Nachfolgend sehen Sie einige Beispielergebnisse.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        1
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        1
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       10
 
query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 2218 |     1 |          1 | 2014-09-25 00:04:30 | Executing | 0          | 4819666
 2220 |     3 |          1 | 2014-09-25 00:04:35 | Executing | 0          | 685

  5. Setzen Sie anschließend die Abfragegruppe zurück.

    reset query_group;

Abschnitt 4: Verwenden von wlm_query_slot_count zur temporären Übergehung der Gleichzeitigkeitsstufe in einer Warteschlange

Gelegentlich benötigen Benutzer mehr Ressourcen für eine bestimmte Abfrage. Wenn dies der Fall ist, können Sie die Konfigurationseinstellung wlm_query_slot_count verwenden, um die Zuweisungsweise für Slots in einer Abfragewarteschlange vorübergehend zu übergehen. Steckplätze sind SpeichereinheitenCPU, die zur Verarbeitung von Abfragen verwendet werden. Sie können die Anzahl der Steckplätze überschreiben, wenn Sie gelegentlich Abfragen haben, die viele Ressourcen im Cluster beanspruchen, z. B. wenn Sie einen VACUUM Vorgang in der Datenbank ausführen.

Sie werden möglicherweise feststellen, dass Benutzer oft für bestimmte Typen von Abfragen wlm_query_slot_count festlegen müssen. Falls ja, sollten Sie in Erwägung ziehen, die WLM Konfiguration anzupassen und den Benutzern eine Warteschlange zur Verfügung zu stellen, die den Anforderungen ihrer Abfragen besser entspricht. Für weitere Informationen zum temporären Übergehen der Gleichzeitigkeitsstufe auf der Grundlage der Slotzahl vgl. wlm_query_slot_count.

Schritt 1: Übergehen der Gleichzeitigkeitsstufe mit wlm_query_slot_count

Für die Zwecke dieses Tutorials führen wir dieselbe SELECT Abfrage mit langer Laufzeit aus. Wir führen diese als Benutzer adminwlm aus und verwenden wlm_query_slot_count zur Erhöhung der Zahl der für die Abfrage verfügbaren Slots.

So übergehen Sie die Gleichzeitigkeitsstufe mit wlm_query_slot_count

  1. Erhöhen Sie das Limit für die Abfrage, um sicherzustellen, dass Sie genügend Zeit haben, um die WLM _ QUERY _ STATE _VW-Ansicht abzufragen und ein Ergebnis zu sehen. 

    set wlm_query_slot_count to 3; 
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

  2. Fragen Sie jetzt WLM _ QUERY _ STATE _VW beim Admin-Benutzer ab, um zu sehen, wie die Abfrage ausgeführt wird.

    select * from wlm_query_state_vw;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 2240 |     2 |          1 | 2014-09-25 00:08:45 | Executing | 0          | 3731414
 2242 |     3 |          1 | 2014-09-25 00:08:49 | Executing | 0          | 596

    Beachten Sie, dass die Slotzahl für die Abfrage 3 ist. Diese Zahl bedeutet, dass die Abfrage alle drei Slots für die Verarbeitung verwendet, wobei alle Ressourcen in der Warteschlange dieser Abfrage zugewiesen werden.

  3. Führen Sie jetzt die folgende Abfrage aus.

    select * from WLM_QUEUE_STATE_VW;

    Nachfolgend sehen Sie ein Beispielergebnis.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        4
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        3
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       25

    Die Konfigurationseinstellung wlm_query_slot_count gilt nur für die aktuelle Sitzung. Wenn diese Sitzung abläuft oder ein anderer Benutzer eine Abfrage ausführt, wird die WLM Konfiguration verwendet.

  4. Setzen Sie die Slotzahl zurück, und führen Sie den Test erneut aus.

    reset wlm_query_slot_count;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

    Nachfolgend sehen Sie einige Beispielergebnisse.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        2
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        2
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       14
 
query | queue | slot_count | start_time          | state     | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
 2260 |     2 |          1 | 2014-09-25 00:12:11 | Executing | 0          | 4042618
 2262 |     3 |          1 | 2014-09-25 00:12:15 | Executing | 0          | 680

Schritt 2: Ausführen von Abfragen aus verschiedenen Sitzungen

Führen Sie dann Abfragen aus verschiedenen Sitzungen aus.

So führen Sie Abfragen aus verschiedenen Sitzungen aus

  1. Führen Sie in RSQL Fenster 1 und 2 den folgenden Befehl aus, um die Testabfragegruppe zu verwenden.

    set query_group to test;

  2. Führen Sie in RSQL Fenster 1 die folgende Abfrage mit langer Laufzeit aus.

    select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

  3. Da die Abfrage mit langer Laufzeit immer noch in RSQL Fenster 1 ausgeführt wird, führen Sie den folgenden Befehl aus. Durch diese Befehle wird die Slot-Zahl erhöht, so dass alle Slots für die Warteschlange verwendet werden. Anschließend wird die länger andauernde Abfrage gestartet.

    set wlm_query_slot_count to 2;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

  4. Öffnen Sie ein drittes RSQL Fenster und fragen Sie die Ansichten ab, um die Ergebnisse zu sehen.

    select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;

    Nachfolgend sehen Sie einige Beispielergebnisse.

    query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
    0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
    1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      1 |         1 |        2
    2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        3
    3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       18
 
query | queue | slot_count | start_time          | state         | queue_time | exec_time
------+-------+------------+---------------------+---------------+------------+-----------
 2286 |     1 |          2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950    | 0
 2282 |     1 |          1 | 2014-09-25 00:16:33 | Executing     | 0          | 19335850
 2288 |     3 |          1 | 2014-09-25 00:16:52 | Executing     | 0          | 666

    Beachten Sie, dass die erste Abfrage einen der Slots verwendet, die der Warteschlange 1 für das Ausführen der Abfrage zugeordnet sind. Beachten Sie außerdem, dass es eine Abfrage gibt, die in der Warteschlange wartet (queued ist hierbei 1 und state ist QueuedWaiting). Nachdem die erste Abfrage abgeschlossen ist, beginnt die Ausführung der zweiten. Dies geschieht, da beide Abfragen zur Abfragegruppe test geleitet werden und die zweite Abfrage auf eine ausreichende Zahl von Slots warten muss, bevor sie ausgeführt werden kann.

Abschnitt 5: Bereinigen Ihrer Ressourcen

Solange dieser ausgeführt wird, fallen Gebühren für Ihren Cluster an. Setzen Sie, wenn Sie dieses Tutorial abgeschlossen haben, Ihre Umgebung wieder auf den ursprünglichen Zustand zurück, indem Sie die folgenden Schritte in Suchen von zusätzlichen Ressourcen und Zurücksetzen der Umgebung im Handbuch Erste Schritte mit Amazon Redshift durchführen.

Weitere Informationen zu finden WLM Sie unterWorkload-Management.