Wie verwende und verwalte ich die Amazon Redshift WLM-Speicherzuweisung?

Kurzbeschreibung

Verwende eine der folgenden Methoden, um WLM so zu konfigurieren, dass Ressourcen effektiv verwaltet werden:

• Automatisches WLM: Amazon Redshift verwaltet die Parallelität der Warteschlangen und die Speicherzuweisung für jede versendete Abfrage. Mit der versendeten Abfrage kannst du die Abfragepriorität der Workload oder der Benutzer für jede der Abfragewarteschlangen definieren.
• Manuelles WLM: Du hast mehr Kontrolle über den Grad der Parallelität und die Speicherzuweisung zu den Warteschlangen. Daher können Abfragen mit höherem Ressourcenverbrauch in Warteschlangen mit mehr Ressourcenzuweisung ausgeführt werden.

Es hat sich bewährt, automatisches WLM zu verwenden, da es maschinelles Lernen verwendet, um die Größe des Speichers vorherzusagen, der den Abfragen zugewiesen werden muss. Wenn du manuelles WLM verwendest und auf automatisches WLM migrieren möchtest, findest du weitere Informationen unter Migration von manuellem WLM zu automatischem WLM.

Hinweis: Um auf metrik basierende Leistungsgrenzen zu definieren, verwende eine Query Monitoring Rule (Abfrageüberwachungsregel, QMR) mit der WLM-Konfiguration.

Lösung

Gehe wie folgt vor, um die Parallelitätsstufe und die WLM-Zuordnung zu den Warteschlangen zu überprüfen:

• Überprüfe die aktuelle WLM-Konfiguration des Amazon Redshift-Clusters.
• Erstelle eine Test-WLM-Konfiguration und gib die Verteilungs- und Parallelitätsstufe der Abfragewarteschlange an.
• (Optional) Wenn du manuelles WLM verwendest, lege fest, wie der Speicher auf die Anzahl der Steckplätze verteilt wird.

Aktuelle WLM-Konfiguration und Speicherauslastung überprüfen

Verwende die Tabelle STV_WLM_SERVICE_CLASS_CONFIG, um die aktuelle WLM-Konfiguration des Amazon Redshift-Clusters zu überprüfen.

Beispiel für eine WLM-Konfiguration:

[
  {
    "query_concurrency": 2,
    "memory_percent_to_use": 30,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [
      "user_group1"
    ],
    "user_group_wild_card": 0,
    "rules": [
      {
        "rule_name": "BlockstoDiskSpill",
        "predicate": [
          {
            "metric_name": "query_temp_blocks_to_disk",
            "operator": ">",
            "value": 50
          }
        ],
        "action": "abort"
      }
    ]
  },
  {
    "query_concurrency": 5,
    "memory_percent_to_use": 40,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [
      "user_group2"
    ],
    "user_group_wild_card": 0
  },
  {
    "query_concurrency": 5,
    "memory_percent_to_use": 10,
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [],
    "user_group_wild_card": 0,
    "rules": [
      {
        "rule_name": "abort_query",
        "predicate": [
          {
            "metric_name": "scan_row_count",
            "operator": ">",
            "value": 1000
          }
        ],
        "action": "abort"
      }
    ]
  },
  {
    "query_group": [],
    "query_group_wild_card": 0,
    "user_group": [],
    "user_group_wild_card": 0,
    "auto_wlm": false
  },
  {
    "short_query_queue": false
  }
]

Hinweis: Das vorherige Beispiel für eine WLM-Konfiguration ist im JSON-Format und verwendet QMR, Warteschlange 1. Im Beispiel ist memory_percent_to_use die tatsächliche Menge an Arbeitsspeicher, die der Serviceklasse zugewiesen ist.

Amazon Redshift weist Speicher aus dem gemeinsam genutzten Ressourcenpool in dem Cluster zu. „Warteschlange 1“ hat eine Speicherzuweisung von 30 %, die in zwei gleiche Slots aufgeteilt ist, da die Parallelität auf „2“ festgelegt ist. Jeder Slot erhält einen gleichen Anteil von 15 % an der aktuellen Speicherzuweisung.

„Warteschlange 2“ hat eine Speicherzuweisung von 40 %, die in zwei gleiche Slots aufgeteilt ist, da die Parallelität auf „5“ festgelegt ist. Jeder Slot erhält die gleichen 8 % der Speicherzuweisung. Die Standardwarteschlange verwendet 10 % der Speicherzuweisung mit einer Stufe „5“ der Warteschlangenparallelität.

Verwende die folgende Abfrage, um die Serviceklassenkonfiguration zu überprüfen:

select rtrim(name) as name,
num_query_tasks as slots,
query_working_mem as mem,
max_execution_time as max_time,
user_group_wild_card as user_wildcard,
query_group_wild_card as query_wildcard
from stv_wlm_service_class_config
where service_class > 4;

Beispielausgabe:

                        name                        | slots | mem | max_time | user_wildcard | query_wildcard
----------------------------------------------------+-------+-----+----------+---------------+----------------
 Service class for super user                       |     1 | 297 |        0 | false         | false
 Queue 1                                            |     2 | 522 |        0 | false         | false
 Queue 2                                            |     5 | 278 |        0 | false         | false
 Default queue                                      |     5 |  69 |        0 | false         | false
 Service class for vacuum/analyze                   |     0 |   0 |        0 | false         | false

„Warteschlange 1“ hat eine Slot-Anzahl von 2 und der für jeden Slot oder Knoten zugewiesene Speicher beträgt 522 MB. Die Speicherzuweisung, die der Serviceklasse zugewiesen ist, ist die tatsächliche Größe des aktuellen Arbeitsspeichers in MB pro Slot für jeden Knoten.

Hinweis: Wenn alle Abfrage-Slots verwendet werden, verwaltet Amazon Redshift den nicht zugewiesenen Speicher. Wenn eine Warteschlange zusätzlichen Speicher anfordert, gibt das System vorübergehend nicht zugewiesenen Speicher an die Warteschlange weiter.

Weitere Informationen zur Verwaltung nicht zugewiesener Speicher findest du unter Zu verwendender WLM-Speicher in Prozent.

Wichtige Tuning-Parameter identifizieren

Verwende die Tabelle SVL_QUERY_METRICS_SUMMARY, um die detaillierte Ausführung zu überprüfen, und die Spalte query_queue_time, um die Abfragen anzuzeigen, die sich in der Warteschlange befinden. Die Spalte query_queue_time zeigt, dass sich die Abfrage in der Warteschlange für die Ausführung eines WLM-Slots befindet.

Beispieltabelle:

dev=# select userid, query, service_class, query_cpu_time, query_blocks_read, query_execution_time, query_cpu_usage_percent, query_temp_blocks_to_disk, query_queue_time  from SVL_QUERY_METRICS_SUMMARY where query=29608;

 userid | query | service_class | query_cpu_time | query_blocks_read | query_execution_time | query_cpu_usage_percent | query_temp_blocks_to_disk | query_queue_time
--------+-------+---------------+----------------+-------------------+----------------------+-------------------------+---------------------------+------------------
    100 | 29608 |                    8 |                       18 |                          942 |                                64 |                                   10.05 |                                               |
(1 row)


ev=# select query, step, rows, workmem, label, is_diskbased
from svl_query_summary
where query = 29608
order by workmem desc;

 query | step |   rows   | workmem  |                  label                  | is_diskbased
-------+------+----------+----------+-----------------------------------------+--------------
 29608 |    3 |    49999 | 54263808 | hash   tbl=714                          | f
 29608 |    2 |    49999 |        0 | project                                 | f
 29608 |    0 |    49999 |        0 | scan   tbl=255079 name=part             | f
 29608 |    1 |    49999 |        0 | project                                 | f
 29608 |    6 |  1561938 |        0 | return                                  | f
 29608 |    4 |  1561938 |        0 | project                                 | f
 29608 |    5 |  1561938 |        0 | project                                 | f
 29608 |    2 | 29995220 |        0 | project                                 | f
 29608 |    1 |  1561938 |        0 | return                                  | f
 29608 |    1 | 29995220 |        0 | project                                 | f
 29608 |    0 |  1561938 |        0 | scan   tbl=4893 name=Internal Worktable | f
 29608 |    3 |  1561938 |        0 | hjoin  tbl=714                          | f
 29608 |    0 | 29995220 |        0 | scan   tbl=255087 name=lineorder        | f
(13 rows)

Verwende die Tabelle SVL_QUERY_SUMMARY, um die Ressourcenzuweisung bei jedem Schritt der Abfrage zu überprüfen.

Überprüfe die Spalten is_diskbased und workmem, um die Ressourcenauslastung anzuzeigen. Weitere Informationen findest du unter Analysieren der Abfragezusammenfassung.

Zu dynamischen WLM-Konfigurationseigenschaften aktualisieren

Verwende die dynamischen WLM-Konfigurationseigenschaften, um sich an sich ändernde Workloads anzupassen. Du kannst dynamische Eigenschaften für die Datenbank anwenden, ohne dass ein Cluster-Neustart erforderlich ist. Der Wechsel zwischen automatischem WLM und manuellem WLM ist jedoch statisch und erfordert einen Cluster-Neustart, um wirksam zu werden.

Weitere Informationen findest du unter STV_WLM_SERVICE_CLASS_CONFIG.

Das Folgende ist ein Beispiel für einen Cluster, der mit zwei Warteschlangen konfiguriert ist:

Queue    Concurrency    % Memory to Use            1        5              60%  
2        5              40%

Wenn der Cluster über 200 GB verfügbaren Arbeitsspeicher verfügt, ähnelt die aktuelle Speicherzuweisung für jeden der Warteschlangen-Slots dem folgenden Beispiel:

Queue 1: (200 GB * 60% ) / 5 slots  = 24 GB
Queue 2: (200 GB * 40% ) / 5 slots  = 16 GB

Um die WLM-Konfigurationseigenschaften so zu aktualisieren, dass sie dynamisch sind, ändere die Einstellungen. Sieh dir das folgende Beispiel für eine Änderung an:

Queue    Concurrency    % Memory to Use            1        3              75%  
2        4              25%

Nachdem du die WLM-Konfiguration geändert hast, wird die Speicherzuweisung aktualisiert, um der geänderten Workload Rechnung zu tragen. Sieh dir folgendes Update an:

Queue 1: (200 GB * 75% ) / 3 slots = 50 GB
Queue 2: (200 GB * 25% ) / 4 slots = 12.5 GB

Hinweis: Wenn sich während eines dynamischen Konfigurations-Updates Abfragen in der WLM-Warteschlange befinden, wartet Amazon Redshift, bis die Abfragen abgeschlossen sind. Nach Abschluss der Abfrage aktualisiert Amazon Redshift den Cluster mit den aktualisierten Einstellungen.

Verwende die Tabelle STV_WLM_SERVICE_CLASS_CONFIG, wenn du zu dynamischen WLM-Konfigurationseigenschaften wechselst.

Wenn die Werte num_query_tasks und target_num_query_tasks unterschiedlich sind, ist ein dynamischer WLM-Übergang in Bearbeitung. Ein Wert von „–1“ zeigt, dass Auto-WLM konfiguriert ist.

Zu wenig für eine Abfrage zugewiesenen Speicher identifizieren

Wenn ein Ausführungsplan für eine Abfrage in SVL_QUERY_SUMMARY den Wert is_diskbased von true hat, weise der Abfrage mehr Speicher zu. Um mehr Speicher zuzuweisen, erhöhe die Anzahl der Abfrage-Slots.

Weitere Informationen findest du unter wlm_query_slot_count.