Règles de surveillance de requête WLM

Dans la gestion des charges de travail (WLM) d’Amazon Redshift, les règles de surveillance des requêtes définissent des limites de performance basées sur des mesures pour les files d’attente WLM et spécifient les mesures à prendre lorsqu’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 annule 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. Un prédicat est composé d’une métrique, d’une condition de comparaison (=, < ou > ) et d’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. Pour plus d’informations sur la surveillance des requêtes et le suivi des actions entreprises sur des requêtes spécifiques, consultez la collection d’exemples sur Utilisation de l’accélération des requêtes courtes.

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.

Définition d’une règle de surveillance de requête

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 du AWS Management Console JSON ou par programmation.

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 plus d’informations, consultez 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’ AWS CLI dans le Guide de la gestion du cluster Amazon Redshift.

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

• Un nom de règle – Les noms des règles doivent être uniques au sein de la configuration WLM. Les noms de règles peut comporter jusqu’à 32 caractères alphanumériques ou traits de soulignement et ne doivent pas contenir d’espaces ni de guillemets. Vous pouvez disposer de jusqu’à 25 règles par file d’attente et la limite totale pour toutes les files d’attente est de 25 règles.

• Un ou plusieurs prédicats – Chaque règle peut comporter jusqu’à trois prédicats. Si l’ensemble des prédicats d’une règle sont respectés, l’action associée est déclenchée. Un prédicat se définit par un nom de métrique, un opérateur (=, < ou >) et une valeur. Par exemple : query_cpu_time > 100000. Pour obtenir une liste des métriques, ainsi que des exemples de valeurs pour différentes métriques, voir Métriques de surveillance des requêtes pour cluster Amazon Redshift provisionné plus loin dans cette section.

• Une action – Si plusieurs règles sont déclenchées, WLM choisit celle dont l’action est la plus grave. Les actions possibles sont les suivantes, par ordre croissant de gravité :

  • Log – Cette action enregistre des informations sur la requête dans la table système STL_WLM_RULE_ACTION. Utilisez cette action si vous souhaitez uniquement écrire un enregistrement de journal. WLM crée au maximum un journal par requête et par règle. Suite à une action log, les autres règles restent en vigueur et WLM continue à surveiller la requête.

  • Hop (uniquement disponible avec la gestion manuelle de la charge de travail) – Consigne l’action et fait sauter la requête vers la file d’attente correspondante suivante. S’il n’existe aucune autre file d’attente correspondante, la requête est annulée. QMR replace uniquement les instructions CREATE TABLE AS (CTAS) et les requêtes en lecture seule, telles que les instructions SELECT. Pour de plus amples informations, veuillez consulter Saut de file d’attente des requêtes WLM.

  • Abort – Journalise l’action et annule la requête. QMR n’arrête pas les instructions COPY et les opérations de maintenance, comme ANALYZE et VACUUM.

  • Change priority (Modifier la priorité) (uniquement disponible avec la gestion automatique de la charge de travail) – Pour modifier la priorité d’une requête.

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 les étapes de création ou de modification d’une règle de surveillance des requêtes, consultez Création ou modification d’une règle de surveillance des requêtes à l’aide de la console et Propriétés du paramètre wlm_json_configuration dans le Guide de la gestion du cluster Amazon Redshift.

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

• Métriques de surveillance des requêtes pour cluster Amazon Redshift provisionné

• Modèles de règles de surveillance de requête

• Création d’une règle à l’aide de la console

• Configuration de la gestion de la charge de travail

• Tables et vues système pour les règles de surveillance de requête

Métriques de surveillance des requêtes pour cluster Amazon Redshift provisionné

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 plus d’informations sur les segments et les étapes, consultezWorkflow d’exécution et de planification de requête.

Note

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

Métrique	Name (Nom)	Description
Temps UC de la requête	query_cpu_time	Temps UC utilisé par la requête (en secondes). CPU time diffère de Query execution time. Les valeurs valides sont comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 99.
Asymétrie d’I/O	io_skew	Ratio du nombre maximal de blocs lus (I/O) 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 comprises entre 0 et 99.
Lignes jointes	join_row_count	Nombre de lignes traitées dans une étape de jonction. Les valeurs valides sont comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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 comprises entre 0 et 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. Si on compare query_priority à l’aide des signes supérieur à (>) et inférieur à (<), HIGHEST est supérieur à HIGH, HIGH est supérieur à NORMAL, etc.

Note

• L’action de saut n’est pas prise en charge avec le prédicat query_queue_time. Autrement dit, les règles définies pour le saut lorsqu’un prédicat query_queue_time est atteint sont ignorées.

• La courte durée d’exécution de segment peut entraîner des erreurs d’échantillonnage avec certaines métriques, notamment io_skew et query_cpu_usage_percent. Pour éviter ou réduire les risques d’erreurs d’échantillonnage, incluez une durée d’exécution de segment à vos règles. segment_execution_time > 10 vous donne un bon point de départ.

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.

Métriques de surveillance des requêtes pour Amazon Redshift sans serveur

La table suivante décrit les métriques utilisées dans les règles de surveillance de requête pour Amazon Redshift sans serveur.

Métrique	Name (Nom)	Description
Temps UC de la requête	max_query_cpu_time	Temps UC utilisé par la requête (en secondes). CPU time diffère de Query execution time. Les valeurs valides sont comprises entre 0 et 999 999.
Blocs lus	max_query_blocks_read	Nombre de blocs de données d’1 Mo lus par la requête. Les valeurs valides sont comprises entre 0 et 1 048 575.
Nombre de lignes d’analyse	max_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 comprises entre 0 et 999 999 999 999 999.
Durée d’exécution de la requête	max_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. Si une requête dépasse le délai d’exécution défini, Amazon Redshift sans serveur arrête la requête. Les valeurs valides sont comprises entre 0 et 86 399.
Temps de file d’attente de la requête	max_query_queue_time	Temps passé à attendre dans une file d’attente, en secondes. Les valeurs valides sont comprises entre 0 et 86 399.
Utilisation de l’UC	max_query_cpu_usage_percent	Pourcentage de la capacité de l’UC utilisée par la requête. Les valeurs valides sont comprises entre 0 et 6 399.
Mémoire sur disque	max_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 comprises entre 0 et 319 815 679.
Lignes jointes	max_join_row_count	Nombre de lignes traitées dans une étape de jonction. Les valeurs valides sont comprises entre 0 et 999 999 999 999 999.
Nombre de lignes jointes de boucle imbriquée	max_nested_loop_join_row_count	Nombre de lignes dans une jonction de boucles imbriquées. Les valeurs valides sont comprises entre 0 et 999 999 999 999 999.

Note

• L’action de saut n’est pas prise en charge avec le prédicat max_query_queue_time. Autrement dit, les règles définies pour le saut lorsqu’un prédicat max_query_queue_time est atteint sont ignorées.

• La courte durée d’exécution de segment peut entraîner des erreurs d’échantillonnage avec certaines métriques, notamment max_io_skew et max_query_cpu_usage_percent.

Modèles de règles de surveillance de requête

Lorsque vous ajoutez une règle à l’aide de la console Amazon Redshift, vous pouvez choisir de 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. Pour une file d’attente ad hoc (ponctuelle) destinée à des requêtes rapides et simples, vous pouvez utiliser un nombre inférieur.
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 I/O importante	segment_execution_time > 120 et io_skew > 1.30	L’asymétrie d’I/O survient quand une tranche de nœud présente un débit d’I/O 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’I/O é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.

Tables et vues système pour les règles de surveillance de requête

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.

• Le tableau STV_QUERY_METRICS affiche les métriques des requêtes en cours d’exécution.

• Le tableau STL_QUERY_METRICS enregistre les métriques des requêtes terminées.

• 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.