WLM query monitoring rules - 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.

WLM query monitoring rules

Dans la gestion de la charge de travail Amazon Redshift (WLM), les règles de surveillance de requête définissent les limites de performance reposant sur les métriques des 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.

Vous définissez les règles de surveillance de requête dans le cadre de la configuration de la gestion de la charge de travail (WLM). Vous pouvez définir jusqu'à 25 règles par file d'attente, et jusqu'à 25 règles au total pour toutes les files d'attente. Chaque règle est composée au maximum de trois conditions (prédicats) et d'une action. A predicate consiste en une mesure, une condition de comparaison (=, < ou > ) et une valeur. Si les conditions de l'ensemble des prédicats d'une règle sont respectées, l'action associée à cette règle est déclenchée. Les règles peuvent être associées aux actions log, hop et abort, comme discuté ci-après.

Les règles dans une file d'attente donnée s'appliquent uniquement aux requêtes en cours d'exécution dans cette file d'attente. Une règle est indépendante des autres règles.

WLM évalue les métriques toutes les 10 secondes. Si plusieurs règles sont déclenchées durant la même période, WLM déclenche l'action la plus grave —: abort, puis hop, puis log. Si l'action est hop ou abort, elle est consignée et la requête est expulsée de la file d'attente. Si l'action est log, la requête continue à s'exécuter dans la file d'attente. WLM déclenche une seule action log par requête et par règle. Si la file d'attente contient d'autres règles, celles-ci restent en vigueur. Si l'action est hop et que la requête est acheminée vers une autre file d'attente, les règles relatives à la nouvelle file d'attente s'appliquent.

Lorsque l'ensemble des prédicats d'une règle sont respectés, WLM écrit une ligne dans la table système STL_WLM_RULE_ACTION. En outre, Amazon Redshift enregistre les métriques des requêtes en cours d'exécution dans STV_QUERY_METRICS. Les métriques des requêtes terminées sont stockées dans STL_QUERY_METRICS.

Defining a query monitoring rule

Vous créez des règles de surveillance de requête dans le cadre de la configuration WLM, que vous définissez lors de la définition du groupe de paramètres de votre cluster.

Vous pouvez créer des règles à l'aide d'AWS Management Console ou par programmation en utilisant JSON.

Note

Si vous créez des règles par programmation, il est recommandé d'utiliser la console afin de générer les données JSON à inclure dans la définition du groupe de paramètres. Pour de plus amples informations, veuillez consulter Création ou modification d'une règle de surveillance de requête à l'aide de la console et Configuration des valeurs des paramètres à l'aide de l'interface de ligne de commande AWS dans le Amazon Redshift Cluster Management Guide.

Pour définir une règle de surveillance de requête, spécifiez les éléments suivants :

  • A rule name – Rule names must be unique within the WLM configuration. Rule names can be up to 32 alphanumeric characters or underscores, and can't contain spaces or quotation marks. You can have up to 25 rules per queue, and the total limit for all queues is 25 rules.

  • One or more predicates – You can have up to three predicates per rule. If all the predicates for any rule are met, the associated action is triggered. A predicate is defined by a metric name, an operator ( =, <, or > ), and a value. An example is query_cpu_time > 100000. For a list of metrics and examples of values for different metrics, see Query monitoring metrics following in this section.

  • An action – If more than one rule is triggered, WLM chooses the rule with the most severe action. Possible actions, in ascending order of severity, are:

    • Log – Record information about the query in the STL_WLM_RULE_ACTION system table. Use the Log action when you want to only write a log record. WLM creates at most one log per query, per rule. Following a log action, other rules remain in force and WLM continues to monitor the query.

    • Hop (only available with manual WLM) – Log the action and hop the query to the next matching queue. If there isn't another matching queue, the query is canceled. QMR hops only CREATE TABLE AS (CTAS) statements and read-only queries, such as SELECT statements. For more information, see WLM query queue hopping.

    • Abort – Log the action and terminate the query. QMR doesn't abort COPY statements and maintenance operations, such as ANALYZE and VACUUM.

    • Change priority (only available with automatic WLM) – Change the priority of a query.

Pour limiter la durée d'exécution des requêtes, nous vous recommandons de créer une règle de surveillance de requête au lieu d'utiliser le délai WLM. Par exemple, vous pouvez définir max_execution_time sur 50 000 millisecondes, comme illustré dans cet extrait JSON.

"max_execution_time": 50000

Mais, nous vous recommandons de définir une règle de surveillance de requête équivalente qui définit query_execution_time sur 50 secondes, comme illustré dans cet extrait JSON.

"rules": [ { "rule_name": "rule_query_execution", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 50 } ], "action": "abort" } ]

Pour connaître les étapes permettant de créer ou de modifier une règle de surveillance de requête, consultez Création ou modification d'une règle de surveillance de requête à l'aide de la console et Propriétés du paramètre wlm_json_configuration dans le Amazon Redshift Cluster Management Guide.

Vous trouverez plus d'informations sur les règles de surveillance de requête dans les rubriques suivantes :

Query monitoring metrics

Le tableau suivant décrit les métriques utilisées dans les règles de surveillance de requête. (Ces métriques diffèrent des métriques stockées dans les tables système STV_QUERY_METRICS et STL_QUERY_METRICS.)

Pour une métrique donnée, le seuil de performance fait l'objet d'un suivi au niveau de la requête ou du segment. Pour de plus amples informations sur les segments et les étapes, veuillez consulterWorkflow d'exécution et de planification de requête.

Note

Le paramètre WLM timeout diffère des règles de surveillance de requête.

Métrique Nom Description :
Temps UC de la requête query_cpu_time Temps UC utilisé par la requête (en secondes). CPU time est distinct de Query execution time.

Les valeurs valides sont 0–999 999.

Blocs lus query_blocks_read Nombre de blocs de données d'1 Mo lus par la requête.

Les valeurs valides sont 0–1 048 575.

Nombre de lignes d'analyse scan_row_count

Nombre de lignes dans une étape d'analyse. Le nombre de lignes correspond au nombre total de lignes émises avant le filtrage des lignes marquées pour la suppression (lignes fantôme) et avant l'application des filtres de requête définis par l'utilisateur.

Les valeurs valides sont 0–999 999 999 999 999.

Durée d'exécution de la requête query_execution_time Délai écoulé pour l'exécution d'une requête (en secondes). Le délai d'exécution n'inclut pas le temps d'attente dans une file d'attente.

Les valeurs valides sont 0–86 399.

Temps de file d'attente de la requête query_queue_time Temps passé à attendre dans une file d'attente, en secondes.

Les valeurs valides sont 0–86 399.

Utilisation de l'UC query_cpu_usage_percent Pourcentage de la capacité de l'UC utilisée par la requête.

Les valeurs valides sont 0–6 399.

Mémoire sur disque query_temp_blocks_to_disk Espace disque temporairement utilisé pour écrire des résultats intermédiaires, en blocs d'1 Mo.

Les valeurs valides sont 0–319,815,679.

Asymétrie d'UC cpu_skew Ratio de l'utilisation maximale de l'UC pour une tranche afin d'obtenir l'utilisation moyenne de l'UC pour toutes les tranches. Cette métrique est définie au niveau du segment.

Les valeurs valides sont 0–99.

Asymétrie d'E/S io_skew Ratio du nombre maximal de blocs lus (E/S) pour une tranche quelconque afin d'obtenir le nombre moyen de blocs lus pour toutes les tranches. Cette métrique est définie au niveau du segment.

Les valeurs valides sont 0–99.

Lignes jointes join_row_count Nombre de lignes traitées dans une étape de jonction.

Les valeurs valides sont 0–999 999 999 999 999.

Nombre de lignes jointes de boucle imbriquée nested_loop_join_row_count Nombre de lignes dans une jonction de boucles imbriquées.

Les valeurs valides sont 0–999 999 999 999 999.

Nombre de lignes renvoyées return_row_count Nombre de lignes retournées par la requête.

Les valeurs valides sont 0–999 999 999 999 999.

Durée d'exécution de segment segment_execution_time Délai écoulé pour l'exécution d'un seul segment (en secondes). Pour éviter ou réduire les risques d'erreurs d'échantillonnage, incluez segment_execution_time > 10 à vos règles.

Les valeurs valides sont 0–86 388.

Nombre de lignes d'analyse Spectrum spectrum_scan_row_count Nombre de lignes de données dans Amazon S3 analysées par une requête Amazon Redshift Spectrum.

Les valeurs valides sont 0–999 999 999 999 999.

Taille d'analyse Spectrum spectrum_scan_size_mb Taille des données dans Amazon S3, en Mo, analysées par une requête Amazon Redshift Spectrum.

Les valeurs valides sont 0–999 999 999 999 999.

Priorité de requête query_priority Priorité de la requête.

Les valeurs valides sont HIGHEST, HIGH, NORMAL, LOW, et LOWEST. Lors de la comparaison query_priority en utilisant plus de (>) et moins de (<) opérateurs, HIGHEST est supérieur à HIGH, HIGH est supérieur à NORMAL, et ainsi de suite.

Note
  • The hop action is not supported with the query_queue_time predicate. That is, rules defined to hop when a query_queue_time predicate is met are ignored.

  • Short segment execution times can result in sampling errors with some metrics, such as io_skew and query_cpu_percent. To avoid or reduce sampling errors, include segment execution time in your rules. A good starting point is segment_execution_time > 10.

La vue SVL_QUERY_METRICS affiche les métriques des requêtes terminées. La vue SVL_QUERY_METRICS_SUMMARY affiche les valeurs maximales des métriques des requêtes terminées. Utilisez les valeurs de ces vues afin de vous aider à déterminer les seuils permettant de définir les règles de surveillance des requêtes.

Query monitoring rules templates

Lorsque vous ajoutez une règle à l'aide de la console Amazon Redshift, vous pouvez créer une règle à partir d'un modèle prédéfini. Amazon Redshift crée une règle avec un ensemble de prédicats, auxquels sont attribuées les valeurs par défaut. L'action par défaut est log. Vous pouvez modifier les prédicats et l'action en fonction de votre cas d'utilisation.

Le tableau suivant répertorie les modèles disponibles.

Nom du modèle Prédicats Description :
Jointure de boucle imbriquée nested_loop_join_row_count > 100 Une jonction de boucles imbriquées peut correspondre à un prédicat de jonction incomplet, qui se traduit généralement par un très grand nombre de retours (un produit cartésien). Utilisez un nombre de lignes peu élevé afin de détecter très tôt une potentielle requête d'échappement.
La requête renvoie un grand nombre de lignes return_row_count > 1000000 Si une file d'attente est dédiée aux requêtes simples de courte durée, vous pouvez inclure une règle qui détecte les requêtes renvoyant un nombre élevé de lignes. Par défaut, le modèle utilise 1 million de lignes. Le nombre de lignes pouvant être désigné comme élevé dépend du système : ce sera un million de lignes sur certains systèmes, un milliard voire plus sur d'autres.
Jointure avec un grand nombre de lignes join_row_count > 1000000000 Une étape de jonction qui implique un nombre de lignes anormalement élevé peut signifier qu'il convient d'utiliser des filtres plus restrictifs. Par défaut, le modèle utilise 1 milliard de lignes. Vous pouvez utiliser moins de lignes pour une file d'attente ponctuelle dédiée aux requêtes simples et rapides.
Utilisation du disque élevée lors de l'écriture des résultats intermédiaires query_temp_blocks_to_disk > 100000 Lorsque les requêtes en cours d'exécution utilisent davantage que la mémoire RAM système disponible, le moteur d'exécution des requêtes écrit les résultats intermédiaires sur le disque (mémoire déversée). En général, cette condition dérive d'une requête non autorisée, qui est habituellement la requête qui consomme le plus d'espace disque. Le seuil acceptable d'utilisation du disque varie selon le type et le nombre des nœuds de cluster. Par défaut, le modèle utilise 100 000 blocs ou 100 Go. Si le cluster est petit, vous pouvez utiliser un nombre inférieur.
Requête de longue durée avec asymétrie E/S importante segment_execution_time > 120 et io_skew > 1.30 L'asymétrie d'E/S survient quand une tranche de nœud présente un débit d'E/S beaucoup plus élevé que les autres tranches. À la base, une asymétrie de 1,30 (1,3 X la moyenne) est considérée comme élevée. Une asymétrie d'E/S élevée ne constitue pas systématiquement un problème en soi. Si, toutefois, elle est combinée à une requête de longue durée, elle peut signifier la présence d'un problème au niveau du style de distribution ou de la clé de tri.

System tables and views for query monitoring rules

Lorsque l'ensemble des prédicats d'une règle sont respectés, WLM écrit une ligne dans la table système STL_WLM_RULE_ACTION. Cette ligne contient les informations relatives à la requête qui a déclenché la règle et l'action qui en résulte.

En outre, Amazon Redshift enregistre les métriques des requêtes dans les tables système et les vues suivantes.