Pourquoi ma requête Amazon Redshift dépasse-t-elle le délai d'expiration WLM que j'ai défini ?

Brève description

Un délai WLM s’applique aux requêtes uniquement pendant la phase d'exécution des requêtes. Si WLM ne met pas fin à une requête au moment prévu, c'est généralement parce que la requête a passé du temps à des étapes autres que la phase d'exécution. Par exemple, la requête peut attendre d'être analysée ou réécrite, attendre un verrou ou attendre une place dans la file d'attente WLM. La requête peut également atteindre l'étape retour ou passer à une autre file d'attente.

Résolution

Lorsque STV_RECENTS est interrogé, l'heure de début est l’heure à laquelle la requête est entrée dans le cluster, et non l'heure à laquelle la requête commence à s'exécuter. Lorsque la requête est en cours d'exécution dans STV_RECENTS, elle est active dans le système. Cependant, la requête n'utilise pas les ressources du nœud de calcul tant qu'elle n'a pas atteint le statut STV_INFLIGHT. Pour plus d'informations sur la planification des requêtes, consultez la section Flux de travail d’exécution et de planification de requête.

Pour afficher l'état d'une requête en cours d'exécution, interrogez STV_INFLIGHT au lieu de STV_RECENTS :

select \* from STV\_INFLIGHT where query = your\_query\_id;

Pour plus d'informations sur les étapes de requête, exécutez la requête suivante :

select \* from SVL\_QUERY\_REPORT where query = your\_query\_id ORDER BY segment, step, slice;

Utilisez la tableSTV_EXEC_STATE pour connaître l'état actuel de toutes les requêtes qui s'exécutent activement sur les nœuds de calcul :

select \* from STV\_EXEC\_STATE where query = your\_query\_id ORDER BY segment, step, slice;

Les raisons courantes pour lesquelles une requête peut sembler s'exécuter plus longtemps que le délai WLM sont les suivantes.

La requête est en phase de « retour »

Il existe deux étapes de « retour ». Vérifiez STV_EXEC_STATE pour voir si la requête est entrée dans l'une des phases de retour suivantes :

• Le retour au nœud principal depuis les nœuds de calcul
• Le retour au client depuis le nœud principal

Un restauration est en cours

Une opération en langage de manipulation de données (DML) peut rencontrer une erreur et être restaurée. Cette opération peut ne pas apparaître comme « arrêtée » car elle est déjà en cours de restauration. Vous pouvez interroger STV_EXEC_STATE pour afficher les restaurations et trouver plus d'informations dans STL_UNDONE.

La requête passe du temps à être mise en file d'attente avant de s'exécuter

Interrogez STV_WLM_QUERY_STATE pour voir le temps de file d'attente :

select \* from STV\_WLM\_QUERY\_STATE where query = your\_query\_id;

La requête est en attente d'un verrou

Si la requête est visible dans STV_RECENTS, mais pas dans STV_WLM_QUERY_STATE, il se peut que la requête soit en attente d'un verrou et qu'elle n'est pas entrée dans la file d'attente. Pour plus d’informations, consultez Comment puis-je détecter et désactiver les verrous dans Amazon Redshift ?

Une requête a été redirigée vers une autre file d’attente

Si une requête de lecture atteint le délai d'expiration de sa file d'attente WLM actuelle, elle est transmise à la file d'attente WLM suivante. En outre, s'il existe une règle de surveillance des requêtes qui spécifie une action de saut, la requête est transmise à la file d'attente WLM suivante. Pour vérifier si la requête est envoyée à la file d'attente suivante, effectuez la requête suivante en fonction de votre scénario :

• Si la requête est en cours d'exécution, interrogez STV_WLM_QUERY_STATE.
• Si la requête est terminée, interrogez STL_WLM_QUERY

Pour empêcher les requêtes de sauter vers une autre file d'attente, configurez la file d'attente WLM ou les règles de surveillance des requêtes WLM. Pour plus d'informations sur le saut de requêtes, consultez la section Saut de file d’attente des requêtes WLM.

Un problème de réseau ou de pare-feu

Si un serveur Amazon Redshift rencontre des problèmes de communication avec votre client, il est possible que le serveur reste bloqué dans l'état « retour au client ». Vérifiez les conflits avec les composants réseau, tels que les paramètres de pare-feu locaux entrants, les règles des groupes de sécurité sortantes ou les règles de liste de contrôle d'accès au réseau (ACL réseau) sortantes. Pour plus d'informations, consultez la section Connexion depuis l’extérieur d’Amazon EC2 — problème de dépassement de délai du pare-feu.

Un problème avec le cluster

Des problèmes liés au cluster lui-même, tels que des problèmes matériels, peuvent entraîner le blocage de la requête. Lorsque la requête se bloque en raison de problèmes de cluster, le cluster est en état de « panne matérielle ». Pour restaurer un cluster à nœud unique, restaurez un instantané. Dans les clusters multi-nœuds, les nœuds défaillants sont automatiquement remplacés.

Informations connexes

Réglage de performances des requêtes

Analyse et amélioration des requêtes