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

Brève description

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

Résolution

Lors de l'interrogation de STV_RECENTS, starttime correspond à l'heure à laquelle la requête est entrée dans le cluster, et non à l'heure à laquelle elle a commencé à s'exécuter. Lorsque la requête est à l'état Running (En cours d'exécution) dans STV_RECENTS, elle est active dans le système. Toutefois, la requête n'utilise pas les ressources du nœud de calcul tant qu'elle n'est pas arrivée à l'état STV_INFLIGHT. Pour plus d'informations sur la planification des requêtes, consulter Flux de travail de planification et d'exécution des requêtes.

Pour afficher le statut 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;

Utilisez cette requête pour obtenir plus d'informations sur les étapes de requête :

select * from SVL_QUERY_REPORT where query = your_query_id ORDER BY segment, step, slice;

Utilisez la table STV_EXEC_STATE pour 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;

Voici quelques raisons courantes pour lesquelles une requête peut sembler s'exécuter plus longtemps que le délai d’expiration WLM défini :

La requête se trouve dans la phase « return »

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

• Retour au nœud principal à partir des nœuds de calcul
• Retour au client à partir du nœud principal

Une restauration est en cours

Si une opération DML (Data Manipulation Language) rencontre une erreur et amorce une restauration, l'opération ne semble pas être annulée, car elle est déjà en cours de restauration. Vous pouvez afficher les restaurations en interrogeant STV_EXEC_STATE. Vous pouvez trouver des informations supplémentaires dans STL_UNDONE.

La requête passe du temps dans la file d'attente avant d'exécuter

Interrogez STV_WLM_QUERY_STATE pour voir l'heure de mise en file d'attente :

select * from STV_WLM_QUERY_STATE where query = your_query_id;

La requête attend un verrou.

Si la requête est visible dans STV_RECENTS mais pas dans STV_WLM_QUERY_STATE, il est possible qu'elle attende un verrou et ne soit pas entrée dans la file d'attente. Pour plus d'informations sur la recherche de verrous, voir Comment détecter et libérer les verrous dans Amazon Redshift ?

Une requête a été placée dans une autre file d'attente.

Si une requête en lecture atteint la limite de délai d’expiration pour sa file d'attente WLM actuelle, ou s'il existe une règle de surveillance de requête qui spécifie une action de saut, la requête est alors envoyée dans la file d'attente WLM suivante. Pour confirmer si la requête a été placée dans la file d'attente suivante :

• Pendant l'exécution de la requête : requête STV_WLM_QUERY_STATE
• Après l'exécution de la requête : requête STL_WLM_QUERY

Pour empêcher les requêtes de passer à 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ête, consultez Saut de file d’attente de requêtes.

Problème de mise en réseau ou de pare-feu

Si un serveur Amazon Redshift rencontre un problème lors de la communication avec votre client, il se peut que le serveur reste bloqué à l'état « Retour au client ». Vérifiez les conflits avec les composants de mise en réseau, tels que les paramètres de pare-feu sur site entrants, les règles de groupe de sécurité sortantes ou les règles de liste ACL réseau sortantes. Pour plus d'informations, voirConnexion depuis l'extérieur d'Amazon EC2 —problème de délai d'expiration du pare-feu.

Problème avec le cluster

Des problèmes avec le cluster lui-même, tels que des problèmes matériels, peuvent entraîner le plantage de la requête. Dans ce cas, le cluster est en état de défaillance matérielle. Pour récupérer un cluster à nœud unique, restaurez un instantané. Dans les clusters à plusieurs nœuds, les nœuds défaillants sont automatiquement remplacés.

---

Informations connexes

Tuning query performance

Analyzing and improving queries