WLMrègles de surveillance des requêtes

Dans le cadre de la gestion de la charge de travail Amazon Redshift (WLM), les règles de surveillance des requêtes définissent les limites de performance basées sur des métriques pour les WLM files d'attente 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 des requêtes dans le cadre de votre configuration de 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 au cours de la même période, WLM choisit la règle comportant l'action la plus sévère. Si l'action pour deux règles a la même sévérité, WLM exécute les règles par ordre alphabétique, en fonction du nom de la règle. 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. WLMlance une seule action de journalisation 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 Accélération des requêtes courtes.

Lorsque tous les prédicats d'une règle sont respectés, WLM écrit une ligne dans la table STL_WLM_RULE_ACTION système. 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 des requêtes dans le cadre de votre WLM configuration, que vous définissez dans le cadre 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 ou par programmation à l'aide de. JSON

Note

Si vous choisissez de créer des règles par programmation, nous vous recommandons vivement d'utiliser la console pour générer celles JSON que vous incluez 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 :

• Nom de règle : les noms de règles doivent être uniques dans la WLM configuration. 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 la règle comportant l'action la plus sévère. Les actions possibles sont les suivantes, par ordre croissant de gravité :

  • Journal — Enregistrez les informations relatives à la requête dans la table ACTION système STL WLM RULE _ _ _. Utilisez cette action si vous souhaitez uniquement écrire un enregistrement de journal. WLMcrée au maximum un journal par requête, par règle. Après une action de journalisation, les autres règles restent en vigueur et WLM continuent de surveiller la requête.

  • Hop (uniquement disponible en mode manuelWLM) : enregistrez l'action et passez la requête à la file d'attente correspondante suivante. S’il n’existe aucune autre file d’attente correspondante, la requête est annulée. QMRsaute uniquement les instructions CREATETABLEAS (CTAS) et les requêtes en lecture seule, telles que les instructions. SELECT Pour de plus amples informations, veuillez consulter WLMsaut dans la file d'attente des requêtes.

  • Abort – Journalise l’action et annule la requête. QMRn'arrête pas COPY les instructions et les opérations de maintenance, telles que ANALYZE etVACUUM.

  • Modifier la priorité (uniquement disponible en mode automatiqueWLM) : modifiez la priorité d'une requête.

Pour limiter le temps d'exécution des requêtes, nous vous recommandons de créer une règle de surveillance des requêtes au lieu d'utiliser le WLM délai d'attente. Par exemple, vous pouvez définir une valeur max_execution_time de 50 000 millisecondes, comme indiqué dans l'extrait de code suivant. JSON

"max_execution_time": 50000

Mais nous vous recommandons plutôt de définir une règle de surveillance des requêtes équivalente. L'exemple suivant illustre une règle de surveillance des requêtes définie query_execution_time sur 50 secondes :

"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 WLMdélai d'expiration diffère des règles de surveillance de requête.

Métrique	Name (Nom)	Description
CPUHeure de la requête	query_cpu_time	CPUtemps utilisé par la requête, en secondes. CPU timeest distinct deQuery 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.
CPUutilisation	query_cpu_usage_percent	Pourcentage de CPU capacité 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.
CPUbiais	cpu_skew	Rapport entre l'CPUutilisation maximale pour une tranche et l'CPUutilisation moyenne 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
CPUHeure de la requête	max_query_cpu_time	CPUtemps utilisé par la requête, en secondes. CPU timeest distinct deQuery 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.
CPUutilisation	max_query_cpu_usage_percent	Pourcentage de CPU capacité 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 plus que le système disponibleRAM, 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 tous les prédicats d'une règle sont respectés, WLM écrit une ligne dans la table STL_WLM_RULE_ACTION système. 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.