Un délai d'expiration WLM est défini pour ma requête Amazon Redshift, mais son exécution se poursuit après l'expiration. Pourquoi ?

Le délai d'expiration WLM s'applique aux requêtes pendant la phase d'exécution uniquement. Si WLM ne parvient pas à arrêter la requête selon la limite prescrite, cela est généralement dû au fait que la requête a passé du temps dans d'autres étapes avant son passage à l'étape d'exécution. Par exemple, la requête peut attendre son analyse ou sa réécriture, un verrou, une place dans la file d'attente WLM, avoir atteint l'étape de retour ou être passée à une autre file d'attente.

Lors des requêtes STV_RECENTS, starttime représente le moment où la requête pénètre dans le cluster et non l'heure de début d'exécution de la requête. Lorsque la requête est en état En cours d'exécution dans STV_RECENTS, elle est présente dans le système, mais n'utilise pas de ressources de nœud de calcul tant qu'elle n'est pas à l'état STV_INFLIGHT. Pour en savoir plus sur la planification des requêtes, consultez Planification de requêtes et flux de travail d'exécution. Pour consulter l'état d'une requête en cours d'exécution, effectuez une requête STV_INFLIGHT et non STV_RECENTS :

select * from STV_INFLIGHT where query = <queryid>;

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

select * from SVL_QUERY_REPORT where query = <queryid> ORDER BY segment, step, slice;

Utilisez cette requête pour obtenir l'état d'exécution actuel de la requête :

select * from STV_EXEC_STATE where query = <queryid> ORDER BY segment, step, slice;

Voici certaines des raisons principales pour lesquelles une requête semble s'exécuter plus longtemps que le délai d'expiration WLM :

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 une de ces phases de retour :

  • le retour vers le nœud principal à partir des nœuds de calcul
  • le retour vers le client à partir du nœud principal

Restauration en cours

Si une opération DML (insertion, mise a jour, suppression) est réalisée, mais qu'elle rencontre une erreur et doit effectuer une restauration, l'opération n'apparaît pas comme supprimée, parce qu'elle est déjà en cours de restauration. Vous pouvez consulter les restaurations en effectuant une requête vers STV_EXEC_STATE. STL_UNDONE fournit des informations supplémentaires.

La requête passe du temps en file d'attente avant son exécution

Vous pouvez consulter le temps passé en file d'attente dans STV_WLM_QUERY_STATE :

select * from STV_WLM_QUERY_STATE where query = <queryid>;

La requête attend un verrou

Si la requête s'affiche dans STV_RECENTS, mais pas dans STV_WLM_QUERY_STATE, il est possible qu'elle attende un verrou et qu'elle ne soit pas encore dans la file d'attente. Utilisez une requête semblable à la suivante pour trouver les verrous attendus par le processus bloqué :

sélectionnez * dans SVV_TRANSACTIONS

où granted='f'

et pid in (sélectionnez pid dans STV_RECENTS où query = );

Utilisez une requête semblable à la suivante pour identifier le processus à l'origine du blocage :

sélectionnez b.* dans SVV_TRANSACTIONS b, SVV_TRANSACTIONS w

où b.granted='t'

et w.granted = 'f'

et b.txn_db = w.txn_db

et b.relation = w.relation

et w.pid in (sélectionnez pid dans STV_RECENTS où query = ) ;

Pour en savoir plus sur le pid potentiellement à l'origine du blocage (comme la requête qu'il exécute actuellement), exécutez des requêtes semblables à ce qui suit :

sélectionnez * dans STL_QUERY où pid =  ;

sélectionnez * dans SVL_STATEMENTTEXT où pid =  ;

Pour arrêter une requête bloquée ou le processus que vous suspectez être à l'origine du blocage, utilisez une requête semblable à la suivante :

sélectionnez pg_terminate_backend(pid);

Une requête est passée à une autre file d'attente

Si une requête de lecture atteint la limite d'expiration pour sa file d'attente WLM actuelle ou si une règle de surveillance de requête spécifie un saut, la requête est transmise à la file d'attente WLM suivante pour exécution. Vous pouvez vérifier si une requête a été transférée en utilisant STV_WLM_QUERY_STATE pendant que la requête est en cours d'exécution ou en utilisant STL_WLM_QUERY après l'exécution de la requête. Pour éviter que les requêtes ne passent dans une autre file d'attente, vous pouvez configurer les Règles de surveillance des requêtes WLM de façon à annuler les actions dans les files d'attente WLM. Pour obtenir plus d'informations sur les sauts de files d'attente par les requêtes, consultez 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, le serveur peut être bloqué sur l'état « retour au client » décrit ci-dessus. Cherchez des conflits avec des composants réseau pouvant bloquer le trafic vers votre serveur, y compris les paramètres entrants de pare-feu sur site, les règles des groupes de sécurité sortantes ou des ACL réseau. Pour en savoir plus, consultez Connexion hors d'Amazon EC2 : problème d'expiration de pare-feu.

Un problème avec le cluster

Des problèmes sur le cluster, notamment liés au matériel, peuvent entraîner un blocage de la requête, même si cela est rare. Vérifiez l'état du cluster dans la console Amazon Redshift, potentiellement « panne de matériel ». Si votre cluster se trouve dans cet état et qu'il est à nœud simple, restaurez votre cluster à partir d'un instantané. Sur un cluster a plusieurs nœuds, le nœud en échec devrait être remplacé automatiquement.


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support.

Date de publication : 11/04/2017

Date de mise à jour : 26/02/2018