Implementing automatic WLM - Amazon Redshift

Si nous fournissons une traduction de la version anglaise du guide, la version anglaise du guide aura préséance en cas de contradiction. La traduction sera une traduction automatique.

Implementing automatic WLM

En mode de gestion automatique de la charge de travail, Amazon Redshift gère la simultanéité des requêtes et l'allocation de mémoire. Huit files d'attente sont créées avec les identificateurs de classe de service 100–107. Chaque file d'attente a une priorité. Pour plus d'informations, consultez Query priority,

En revanche, le mode de gestion manuelle de la charge de travail implique de spécifier les valeurs pour la simultanéité des requêtes et l'allocation de mémoire. Par défaut, en mode de gestion manuelle de la charge de travail, le nombre de requêtes simultanées est 5 et la mémoire est divisée équitablement entre les cinq requêtes. La gestion automatique de la charge de travail détermine la quantité de ressources nécessaires pour les requêtes et ajuste la simultanéité en fonction de la charge de travail. Lorsque des requêtes dans le système nécessitent une grande quantité de ressources (par exemple, des jointures de hachage entre des tables volumineuses), la simultanéité est plus faible. Lorsque des requêtes nécessitant moins de ressources (par exemple des insertions, des suppressions, des analyses ou des agrégations simples) sont soumises, la simultanéité est plus élevée.

Pour plus de détails sur la migration de la gestion automatique de la charge de travail à la gestion manuelle de la charge de travail, veuillez consulter Migrating from manual WLM to automatic WLM.

La gestion automatique de la charge de travail est différente de l'accélération des requêtes courtes (SQA) et évalue différemment les requêtes. La gestion automatique de la charge de travail et l'accélération des requêtes courtes collaborent pour autoriser les requêtes légères à exécution rapide à être prises en charge même lorsque des requêtes lourdes nécessitant beaucoup de ressources sont en court d’exécution. Pour de plus amples informations sur SQA, veuillez consulter Working with short query acceleration.

Amazon Redshift active la gestion automatique de la charge de travail via des groupes de paramètres :

  • If your clusters use the default parameter group, Amazon Redshift enables automatic WLM for them.

  • If your clusters use custom parameter groups, you can configure the clusters to enable automatic WLM. We recommend that you create a separate parameter group for your automatic WLM configuration.

Pour configurer la gestion de la charge de travail, modifiez le paramètre (wlm_json_configuration) dans un groupe de paramètres qui peut être associé à un ou plusieurs clusters. Pour plus d'informations, consultez Modifying the WLM configuration,

Vous définissez des files d'attente de requête au sein de la configuration WLM. Vous pouvez ajouter des files d'attente de requête supplémentaires à la configuration WLM par défaut (huit files d'attente de l'utilisateur au maximum). Vous pouvez configurer les éléments suivants pour chaque file d'attente de requête :

  • Priority

  • Concurrency scaling mode

  • User groups

  • Query groups

  • Query monitoring rules

Priority

Vous pouvez définir l'importance relative des requêtes dans une charge de travail en définissant une valeur de priorité. La priorité est spécifiée pour une file d'attente et héritée par toutes les requêtes associées à la file d'attente. Pour plus d'informations, consultez Query priority,

Concurrency scaling mode

Lorsque la mise à l'échelle de la simultanéité est activée, Amazon Redshift ajoute automatiquement de la capacité de cluster supplémentaire lorsque vous en avez besoin pour traiter une augmentation des requêtes de lecture simultanées. Les opérations d'écriture se poursuivent normalement sur votre cluster principal. Les utilisateurs voient les données les plus récentes, que les requêtes s'exécutent sur le cluster principal ou sur un cluster de mise à l'échelle de la simultanéité.

Vous gérez quelles sont les requêtes envoyées au cluster de mise à l'échelle de la simultanéité en configurant les files d'attente de la gestion de la charge de travail. Lorsque vous activez la mise à l'échelle de la simultanéité pour une file d'attente, les requêtes éligibles sont envoyées au cluster de mise à l'échelle de la simultanéité au lieu d'attendre en ligne. Pour plus d'informations, consultez Working with concurrency scaling,

User groups

Vous pouvez affecter un ensemble de groupes d'utilisateurs à une file d'attente en spécifiant chaque nom de groupe d'utilisateurs ou en utilisant des caractères génériques. Lorsqu'un membre d'un groupe d'utilisateurs répertorié exécute une requête, celle-ci s'exécute dans la file d'attente correspondante. Il n'y a pas de limite au nombre de groupes d'utilisateurs qui peut être assigné à une file d'attente. Pour plus d'informations, consultez Wildcards,

Query groups

Vous pouvez affecter un ensemble de groupes de requêtes à une file d'attente en spécifiant chaque nom de groupe de requêtes ou en utilisant des caractères génériques. A query group est simplement une étiquette. Au moment de l'exécution, vous pouvez affecter l'étiquette de groupe de requête à une série de requêtes. Toutes les requêtes qui sont affectées à un groupe de requêtes répertorié sont exécutées dans la file d'attente correspondante. Il n'y a pas de limite au nombre de groupes de requêtes qui peut être assigné à une file d'attente. Pour plus d'informations, consultez Wildcards,

Wildcards

Si les caractères génériques sont activés dans la configuration de file d'attente WLM, vous pouvez affecter des groupes d'utilisateurs et des groupes de requêtes à une file d'attente individuellement ou en utilisant des caractères génériques de style shell Unix. Le modèle correspondant est sensible à la casse.

Par exemple, le caractère générique « * » correspond à n'importe quel nombre de caractères. Ainsi, si vous ajoutez dba_* à la liste de groupes d'utilisateurs pour une file d'attente, toute requête exécutée par un utilisateur et appartenant à un groupe dont le nom commence par dba_ est affectée à cette file d'attente. Exemples : dba_admin ou DBA_primary. Le caractère générique «  ? » correspond à un caractère unique. Ainsi, si la file d'attente comprend le groupe utilisateur dba?1, alors les groupes utilisateur nommés dba11 et dba21 correspondent, mais le groupe dba12 ne correspond pas.

PPar défaut, les caractères génériques sont désactivés.

Query monitoring rules

Les règles de surveillance de requête définissent les limites de performance reposant sur les métriques pour les files d'attente WLM et spécifient quelle action exécuter quand une requête dépasse ces limites. Par exemple, pour une file d'attente dédiée aux requêtes de courte durée, vous pouvez créer une règle qui interrompt les requêtes qui s'exécutent pendant plus de 60 secondes. Si vous souhaitez effectuer un suivi des requêtes mal conçues, vous pouvez configurer une autre règle qui consigne les requêtes contenant des boucles imbriquées. Pour plus d'informations, consultez WLM query monitoring rules,

Checking for automatic WLM

Pour vérifier si la gestion automatique de la charge de travail est activée, exécutez la requête suivante. Si la requête renvoie au moins une ligne, cela signifie que la gestion automatique de la charge de travail est activée.

select * from stv_wlm_service_class_config where service_class >= 100;

La requête suivante affiche le nombre de requêtes ayant parcouru chaque file d'attente de requête (classe de service). Elle affiche aussi la durée d'exécution moyenne, le nombre de requêtes avec un délai d'attente au 90e percentile et le délai d'attente moyen. Les requêtes en mode de gestion automatique de la charge de travail utilisent les classes de service 100 à 107.

select final_state, service_class, count(*), avg(total_exec_time), percentile_cont(0.9) within group (order by total_queue_time), avg(total_queue_time) from stl_wlm_query where userid >= 100 group by 1,2 order by 2,1;

Pour savoir quelles requêtes ont été exécutées par la gestion automatique de la charge de travail et exécutées avec succès, exécutez la requête suivante.

select a.queue_start_time, a.total_exec_time, label, trim(querytxt) from stl_wlm_query a, stl_query b where a.query = b.query and a.service_class >= 100 and a.final_state = 'Completed' order by b.query desc limit 5;