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

Brève description

La fonctionnalité de gestion des charges de travail (WLM) Amazon Redshift vous permet de gérer et de définir plusieurs files d'attente de requêtes. Elle permet d'acheminer les requêtes vers les files d'attente appropriées avec l'allocation de mémoire pour les requêtes lors de l'exécution. Certaines requêtes peuvent consommer plus de ressources de cluster, ce qui affecte les performances d'autres requêtes.

Vous pouvez configurer la gestion des charges de travail pour gérer efficacement les ressources de l'une ou l'autre des manières ci-dessous.

• WLM automatique : permet à Amazon Redshift de gérer le niveau de simultanéité de l'allocation de files d'attente et de mémoire pour chaque requête envoyée. La requête distribuée permet aux utilisateurs 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 permet d'avoir plus de contrôle sur le niveau de simultanéité et l'allocation de mémoire aux files d'attente. Par conséquent, les requêtes qui consomment plus de ressources peuvent s'exécuter dans les files d'attente ayant plus d'allocation de ressources.

Remarque : pour définir des limites de performances basées sur les métriques, utilisez une règle de surveillance des requêtes (QMR) ainsi que votre configuration de gestion des charges de travail.

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

1.FSPVérifiez la configuration WLM actuelle de votre cluster Amazon Redshift.

2.FSPCréez une configuration de gestion des charges de travail test, en spécifiant le niveau de distribution et de simultanéité de la file d'attente de requêtes.

3.FSP(Facultatif) Si vous utilisez la WLM manuelle, déterminez la répartition de la mémoire entre le nombre d'emplacements.

Résolution

Vérification de la configuration WLM et de 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 :

[
  {
    "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 : dans cet exemple, la configuration WLM est au format JSON et utilise une règle de surveillance des requêtes (file d'attente 1).

Dans la configuration WLM, le paramètre « memory_percent_to_use » représente la quantité réelle de mémoire de travail, affectée à la classe de service.

Notez qu'Amazon Redshift alloue de la mémoire à partir du groupe de ressources partagées dans votre cluster. Par conséquent, la file d'attente 1 a une allocation de mémoire de 30 %, qui est ensuite divisée en deux emplacements égaux. Chaque emplacement reçoit une part égale de 15 % de l'allocation de mémoire actuelle. Pendant ce temps, la file d'attente 2 a une allocation de mémoire de 40 %, qui est ensuite divisée en cinq emplacements égaux. Chaque emplacement obtient une part égale de 8 % de l'allocation de mémoire. La file d'attente par défaut utilise 10 % de l'allocation de mémoire 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 pour Amazon Redshift WLM :

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;

Voici un 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 a un nombre d'emplacements de 2, et la mémoire allouée à chaque emplacement (ou nœud) est de 522 Mo. L'allocation de mémoire représente la quantité réelle de mémoire de travail actuelle (en Mo) par emplacement pour chaque nœud, affectée à la classe de service.

Remarque : si tous les emplacements de requêtes sont utilisés, la mémoire non allouée est gérée par Amazon Redshift. La mémoire non allouée peut être temporairement affectée à une file d'attente si la file d'attente demande de la mémoire supplémentaire pour le traitement. Par exemple, si vous configurez quatre files d'attente, vous pouvez allouer votre mémoire comme suit : 20 pour cent, 30 pour cent, 15 pour cent et 15 pour cent. Les 20 % restants ne sont pas alloués et sont gérés par le service. Pour plus d'informations sur la gestion de la mémoire non allouée, consultez Pourcentage de mémoire WLM à utiliser.

Identification des paramètres de réglage de haut niveau

Voici un exemple de plan d'exécution de requête pour une requête :

• Utilisez la table SVL_QUERY_METRICS_SUMMARY pour vérifier l'exécution détaillée, et la colonne « query_queue_time » pour voir quelles requêtes sont mises en file d'attente. La colonne « query_queue_time » indique que la requête attend dans la file d'attente qu'un emplacement WLM s'exécute.
• Utilisez la table SVL_QUERY_SUMMARY pour vérifier la consommation de mémoire de la requête, même si la requête s'exécutait en mémoire.

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 obtenir une vue détaillée de l'allocation des ressources à chaque étape de la requête. Vérifiez les colonnes is_diskbased et workmem pour afficher la consommation des ressources. Pour plus d'informations, voir Analyse du résumé de la requête.

Mise à jour vers les propriétés de configuration dynamique WLM

Vous pouvez également utiliser les propriétés de configuration dynamique WLM pour vous adapter à la modification des charges de travail. Vous pouvez appliquer des propriétés dynamiques à la base de données sans redémarrage du cluster. Toutefois, les propriétés de configuration statique WLM nécessitent un redémarrage du cluster pour que les modifications prennent effet.

Voici un exemple de cluster configuré avec deux files d'attente :

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 peut ressembler à ceci :

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

Pour mettre à jour vos propriétés de configuration WLM afin qu'elles soient dynamiques, modifiez vos paramètres comme ceci :

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

Par conséquent, l'allocation de mémoire a été mise à jour pour tenir compte de la charge de travail modifiée :

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

Remarque : si des requêtes sont exécutées 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 pendant que la transition vers les propriétés de configuration WLM dynamique est en cours. Lorsque les colonnes num_query_tasks (simultanéité) et query_working_mem (pourcentage de mémoire dynamique) deviennent égales dans les valeurs cibles, la transition est terminée.

Identification de la mémoire insuffisante allouée à la requête

Si un plan d'exécution de requête dans SVL_QUERY_SUMMARY a la valeur is_diskbased « true », envisagez d'allouer plus de mémoire à la requête. Vous pouvez allouer plus de mémoire en augmentant le nombre d'emplacements de requêtes utilisés. Pour plus d'informations, reportez-vous à l'étape 1 : Remplacer le niveau de simultanéité à l'aide du paramètre wlm_query_slot_count.

Remarque : il est recommandé d'identifier d'abord l'étape qui cause un déversement de disque. Ensuite, décidez si l'allocation de mémoire supplémentaire à la file d'attente peut résoudre le problème. Ou vous pouvez optimiser votre requête.

---