Mes requêtes Amazon Redshift dépassent le délai WLM que j'ai défini.

Dernière mise à jour : 21/08/2020

J'ai défini un délai WLM pour une requête Amazon Redshift, mais la requête continue de s'exécuter après l'expiration de cette période. Comment est-ce possible ?

Brève description

Un délai WLM s'applique aux requêtes uniquement pendant la phase d'exécution. Si WLM ne résilie pas une requête au moment prévu, c'est généralement parce que la requête 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 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, consultez Query planning and execution workflow.

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 cette requête pour l'état d'exécution actuel de la requête :

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 WLM :

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 est annulée, 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 à mettre en file d'attente avant l'exécution

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 n'ait pas été entrée dans la file d'attente. Utilisez une requête similaire à la suivante pour vérifier les verrous que le processus bloqué attend :

select *
from SVV_TRANSACTIONS
where granted='f'
and pid in (select pid from STV_RECENTS where query ilike '%concerned_query_search_string%');

Utilisez une requête similaire à la suivante pour identifier le processus qui bloque la requête :

select b.*
from SVV_TRANSACTIONS b, SVV_TRANSACTIONS w
where b.granted='t'
and w.granted = 'f'
and b.txn_db = w.txn_db
and b.relation = w.relation
and w.pid in (select pid from STV_RECENTS where ilike '%concerned_query_search_string%');

Pour trouver plus d'informations sur le processus de blocage (par exemple, la requête qu'il est train d’exécuter), exécutez des requêtes similaires à ce qui suit :

select * from STL_QUERY where pid =  pid_of_blocking_process;
        
select * from SVL_STATEMENTTEXT where pid = pid_of_blocking_process;

Pour arrêter la requête bloquée ou pour arrêter le processus qui la bloque, exécutez une requête similaire à ce qui suit. Pour plus d'informations, consultez PG_TERMINATE_BACKEND.

select pg_terminate_backend(process_or_query_id);

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

Si une requête de lecture atteint le 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 transmise à la file d'attente WLM suivante pour exécution. Pour confirmer si la requête est replacée vers la file d'attente suivante :

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 WLM query queue hopping.

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, consultez Connecting from outside of Amazon EC2—firewall timeout issue.

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


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?