Comment utiliser et gérer l'allocation de mémoire WLM Amazon Redshift ?

Brève description

Utilisez l'une des méthodes suivantes pour configurer la gestion de la charge de travail (WLM) afin de gérer efficacement les ressources :

• WLM automatique : Amazon Redshift gère le niveau de simultanéité des files d'attente et l'allocation de mémoire pour chaque requête envoyée. La requête envoyée vous permet de définir la priorité de requête de la charge de travail ou des utilisateurs pour chacune des files d'attente de requêtes.
• WLM manuelle : Vous pouvez mieux contrôler le niveau de simultanéité et l'allocation de mémoire aux files d'attente. Par conséquent, les requêtes consommant plus de ressources peuvent être exécutées dans des files d'attente avec une allocation de ressources plus importante.

Il est recommandé d'utiliser la WLM automatique, car elle utilise l'apprentissage automatique pour prédire la quantité de mémoire à attribuer aux requêtes. Si vous utilisez la WLM manuelle et que vous souhaitez migrer vers la WLM automatique, consultez la section Migration de la WLM manuelle le vers la WLM automatique.

Remarque : Pour définir des limites de performances basées sur des métriques, utilisez une règle de surveillance de requête (QMR) avec la configuration de votre WLM.

Résolution

Pour vérifier le niveau de simultanéité et l'allocation de la WLM aux files d'attente, effectuez les actions suivantes :

• Vérifiez la configuration WLM actuelle de votre cluster Amazon Redshift.
• Créez une configuration WLM de test et spécifiez la distribution et le niveau de simultanéité de la file d'attente de requêtes.
• (Facultatif) Si vous utilisez la WLM manuelle, déterminez comment la mémoire est distribuée entre les emplacements.

Vérifier la configuration WLM actuelle et l'utilisation de la mémoire

Utilisez la table STV_WLM_SERVICE_CLASS_CONFIG pour vérifier la configuration WLM actuelle de votre cluster Amazon Redshift.

Exemple de configuration WLM :

[
  {
    "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
  }
]

Remarque : L'exemple de configuration WLM précédent est au format JSON et utilise la QMR, file d’attente 1. Dans l'exemple, memory_percent_to_use est la quantité réelle de mémoire de travail attribuée à la classe de service.

Amazon Redshift alloue de la mémoire à partir du groupe de ressources partagé de votre cluster. La file d'attente 1 a une allocation de mémoire de 30 % qui est divisée en deux emplacements égaux car la simultanéité est définie sur 2. Chaque emplacement reçoit une part égale de 15 % de l'allocation de mémoire actuelle.

La file d’attente 2 a une allocation de mémoire de 40 % qui est divisée en cinq emplacements égaux car la simultanéité est définie sur 5. Chaque emplacement reçoit une part égale de 8 % de la mémoire allouée. La file d'attente par défaut utilise 10 % de la mémoire allouée avec un niveau de simultanéité de file d'attente de 5.

Utilisez la requête suivante pour vérifier la configuration de la classe de service :

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;

Exemple de sortie :

                        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

La file d'attente 1 compte 2 emplacements et la mémoire allouée à chaque emplacement, ou nœud, est de 522 Mo. L'allocation de mémoire attribuée à la classe de service est la quantité réelle de mémoire de travail actuelle en Mo par emplacement pour chaque nœud.

Remarque : Si tous les emplacements de requête sont utilisés, Amazon Redshift gère la mémoire non allouée. Lorsqu'une file d'attente demande de la mémoire supplémentaire, le système fournit temporairement de la mémoire non allouée à la file d'attente.

Pour plus d'informations sur la gestion de la mémoire non allouée, consultez la section Pourcentage de mémoire de WLM à utiliser.

Identifier les paramètres de réglage de haut niveau

Utilisez la table SVL_QUERY_METRICS_SUMMARY pour vérifier l'exécution détaillée et la colonne query_queue_time pour afficher les requêtes mises en file d'attente. La colonne query_queue_time indique que la requête se trouve dans la file d'attente pour qu'un emplacement WLM soit exécuté.

Exemple de table :

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)

Utilisez la table SVL_QUERY_SUMMARY pour vérifier l'allocation des ressources à chaque étape de la requête.

Vérifiez les colonnes is_diskbased et workmem pour voir l'utilisation des ressources. Pour plus d'informations, consultez la section Analyse du résumé de la requête.

Mettre à jour les propriétés de configuration dynamique de la WLM

Utilisez les propriétés de configuration dynamique de la WLM pour vous adapter aux charges de travail qui changent. Vous pouvez appliquer des propriétés dynamiques à la base de données sans redémarrer le cluster. Cependant, le changement entre la WLM automatique et la WLM manuelle est statique et nécessite un redémarrage du cluster pour prendre effet.

Pour plus d'informations, consultez la section STV_WLM_SERVICE_CLASS_CONFIG.

Un exemple de cluster configuré avec deux files d'attente est présenté ci-dessous :

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

Si le cluster dispose de 200 Go de mémoire disponible, l'allocation de mémoire actuelle pour chacun des emplacements de file d'attente est similaire à l'exemple suivant :

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

Pour mettre à jour les propriétés de configuration de votre WLM afin qu'elles soient dynamiques, modifiez vos paramètres. Consultez l'exemple de modification suivant :

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

Une fois que vous avez modifié la configuration de la WLM, l'allocation de mémoire est mise à jour pour s'adapter à la charge de travail modifiée. Consultez l'exemple suivant :

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

Remarque : Si des requêtes apparaissent dans la file d'attente WLM lors d'une mise à jour de configuration dynamique, Amazon Redshift attend que les requêtes soient terminées. Une fois la requête terminée, Amazon Redshift met à jour le cluster avec les paramètres mis à jour.

Utilisez la table STV_WLM_SERVICE_CLASS_CONFIG lorsque vous passez aux propriétés de configuration WLM dynamiques.

Si les valeurs num_query_tasks et target_num_query_tasks sont différentes, une transition WLM dynamique est en cours. La valeur -1 indique que la WLM automatique est configurée.

Identifier la mémoire insuffisante allouée à la requête

Si la valeur true d'un plan d'exécution de requête dans SVL_QUERY_SUMMARY est is_diskbased, allouez plus de mémoire à la requête. Pour allouer plus de mémoire, augmentez le nombre d'emplacements de requête.

Pour plus d'informations, consultez la section wlm_query_slot_count.