Lock:Relation - Amazon Relational Database Service
Versions de moteur prises en chargeContexteCauses probables de l'augmentation du nombre d'événements d'attenteActions

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Lock:Relation

L'événement Lock:Relation se produit lorsqu'une requête attend d'acquérir un verrou sur une table ou une vue (relation) actuellement verrouillée par une autre transaction.

Versions de moteur prises en charge

Ces informations sur les événements d'attente sont prises en charge pour toutes les versions de RDS for PostgreSQL.

Contexte

La plupart des commandes PostgreSQL utilisent implicitement des verrous pour contrôler les accès simultanés aux données des tables. Vous pouvez également utiliser ces verrous explicitement dans le code de votre application grâce à la commande LOCK. De nombreux modes de verrouillage ne sont pas compatibles entre eux et peuvent bloquer des transactions lorsqu'ils tentent d'accéder au même objet. Dans ce cas, RDS for PostgreSQL génère un événement Lock:Relation. Voici quelques exemples courants :

  • Des verrous exclusifs tels que ACCESS EXCLUSIVE peuvent bloquer tous les accès simultanés. Les opérations en langage de définition de données (DDL) telles que DROP TABLE, TRUNCATE, VACUUM FULL et CLUSTER acquièrent implicitement des verrous ACCESS EXCLUSIVE. ACCESS EXCLUSIVE est également le mode de verrouillage par défaut pour les instructions LOCK TABLE qui ne spécifient pas explicitement de mode.

  • L'utilisation de CREATE INDEX (without CONCURRENT) sur une table entre en conflit avec les instructions du langage de manipulation de données (DML) UPDATE, DELETE et INSERT, qui acquièrent des verrous ROW EXCLUSIVE.

Pour en savoir plus sur les verrous de niveau table et les modes de verrouillage conflictuels, consultez Explicit Locking dans la documentation PostgreSQL.

Le déblocage lié aux requêtes et transactions de blocage s'effectue généralement de l'une des manières suivantes :

  • Requête de blocage – L'application peut annuler la requête ou l'utilisateur peut mettre fin au processus. Le moteur peut également forcer la requête à se terminer en raison de l'expiration du délai d'attente d'une instruction de la session ou d'un mécanisme de détection de blocage.

  • Transaction de blocage – Une transaction met fin à son blocage lorsqu'elle exécute une instruction ROLLBACK ou COMMIT. Les restaurations sont également automatiques lorsque les sessions sont déconnectées par un client ou suite à des problèmes de réseau, ou lorsqu'elles sont interrompues. Les sessions peuvent être interrompues lorsque le moteur de base de données est arrêté, lorsque le système est à court de mémoire, etc.

Causes probables de l'augmentation du nombre d'événements d'attente

Lorsque l'événement Lock:Relation se produit plus fréquemment que la normale, il peut indiquer un problème de performances. Les causes sont généralement les suivantes :

Augmentation du nombre de sessions simultanées avec des verrous de table conflictuels

Le nombre de sessions simultanées peut augmenter lorsque des requêtes verrouillent la même table avec des modes de verrouillage conflictuels.

Opérations de maintenance

Les opérations de maintenance liées à l'état comme VACUUM et ANALYZE peuvent considérablement augmenter le nombre de verrous en conflit. VACUUM FULL acquiert un verrou ACCESS EXCLUSIVE, et ANALYSE acquiert un verrou SHARE UPDATE EXCLUSIVE. Ces deux types de verrous peuvent provoquer un événement d'attente Lock:Relation. Les opérations de maintenance des données d'application telles que l'actualisation d'une vue matérialisée peuvent également augmenter le nombre de requêtes et de transactions bloquées.

Verrous sur les instances de lecture

Il peut y avoir un conflit entre les verrous relationnels des volumes en écriture et des volumes en lecture. Actuellement, seuls les verrous relationnels ACCESS EXCLUSIVE sont répliqués vers les instances de lecture. Cependant, le verrou relationnel ACCESS EXCLUSIVE entrera en conflit avec tout verrou relationnel ACCESS SHARE détenu par le volume en lecture. Cela peut entraîner une augmentation des événements d'attente de relation de verrouillage sur le volume en lecture.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.

Réduisez l'impact des instructions SQL de blocage

Pour réduire l'impact des instructions SQL de blocage, si possible, modifiez le code de votre application. Voici deux techniques courantes pour réduire les blocages :

  • Utilisez l'option NOWAIT – Certaines commandes SQL, telles que les instructions SELECT et LOCK prennent en charge cette option. La directive NOWAIT annule la requête liée à la demande de verrou si le verrou ne peut pas être acquis immédiatement. Cette technique permet d'éviter qu'une session de blocage ne provoque un empilement de sessions bloquées derrière elle.

    Par exemple, supposons que la transaction A attende un verrou détenu par la transaction B. Si B demande un verrou sur une table qui est verrouillée par la transaction C, la transaction A peut être bloquée jusqu'à ce que la transaction C se termine. Mais si la transaction B utilise NOWAIT lorsqu'elle demande le verrou sur C, elle peut échouer rapidement et faire en sorte que la transaction A n'ait pas à attendre indéfiniment.

  • Utilisez SET lock_timeout – Définissez une valeur lock_timeout afin de limiter le délai d'attente d'une instruction SQL pour acquérir un verrou sur une relation. Si le verrou n'est pas acquis dans le délai spécifié, la transaction qui a demandé celui-ci est annulée. Définissez cette valeur au niveau de la session.

Minimisez l'effet des opérations de maintenance

Les opérations de maintenance telles que VACUUM et ANALYZE sont importantes. Nous vous recommandons de ne pas les désactiver parce que vous trouvez des événements d'attente Lock:Relation liés à ces opérations de maintenance. Les approches suivantes peuvent minimiser l'effet de ces opérations :

  • Exécutez les opérations de maintenance manuellement pendant les heures creuses.

  • Pour réduire les attentes Lock:Relation causées par les tâches autovacuum, procédez aux réglages nécessaires de la fonction autovacuum. Pour en savoir plus sur le réglage de la fonction autovacuum, consultez Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS dans le Guide de l'utilisateur Amazon RDS.