Lock:Relation - Amazon Aurora
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 s’appliquent à toutes les versions d’Aurora 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, Aurora 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 ANALYZE 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 l’a demandé 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.

Recherchez les verrous de lecture

Vous pouvez déterminer comment des sessions ouvertes simultanément sur un enregistreur et un lecteur peuvent détenir des verrous qui se bloquent mutuellement. Une façon de le faire est d’exécuter des requêtes qui renvoient le type de verrou et la relation. Dans le tableau, vous trouverez une séquence de requêtes à deux sessions simultanées de ce type, une session d’enregistreur et une session de lecteur.

Le processus de relecture attend la durée de max_standby_streaming_delay avant d’annuler la requête du lecteur. Comme le montre l’exemple, le délai de verrouillage de 100 ms est bien inférieur au délai max_standby_streaming_delay par défaut de 30 secondes. Le verrouillage s’arrête avant que cela ne devienne un problème.

Événement de la séquence Session Commande ou sortie

Définit une variable d’environnement appelée READER avec la valeur spécifiée et essaie de se connecter à l’instance de base de données avec ce point de terminaison.

Session de lecteur

Commande de la CLI :

export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com

psql -h $READER

Sortie :

psql (15devel, server 10.14)
Type "help" for help.

Définit une variable d’environnement appelée WRITER et essaie de se connecter à l’instance de base de données avec ce point de terminaison.

Session d’enregistreur

Commande de la CLI :

export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER

Sortie :

psql (15devel, server 10.14) 
Type "help" for help.

La session d’enregistreur crée une table t1 sur l’instance d’enregistreur.

Session d’enregistreur

Requête PostgreSQL :

postgres=> CREATE TABLE t1(b integer);
CREATE TABLE

Si l’enregistreur n’a pas de requêtes conflictuelles, le verrou ACCESS EXCLUSIVE est acquis immédiatement au niveau de l’enregistreur.

Session d’enregistreur

Verrou ACCESS EXCLUSIVE activé

La session du lecture définit un intervalle d’expiration de 100 millisecondes pour le verrou.

Session de lecteur

Requête PostgreSQL :

postgres=> SET lock_timeout=100;
SET

La session de lecteur tente de lire les données de la table t1 sur l’instance de lecteur.

Session de lecteur

Requête PostgreSQL :

postgres=> SELECT * FROM t1;

Exemple de sortie :

b
---
(0 rows)

La session d’enregistreur abandonne t1.

Session d’enregistreur

Requête PostgreSQL :

postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>

La requête expire et est annulée sur le lecteur.

Session de lecteur

Requête PostgreSQL :

postgres=> SELECT * FROM t1;

Exemple de sortie :

ERROR:  canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
                      ^

Pour déterminer la cause de l’erreur, la session de lecteur interroge pg_locks et pg_stat_activity.

Session de lecteur

Requête PostgreSQL :

postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;

Le résultat indique que le processus aurora wal replay applique un verrou ACCESS EXCLUSIVE sur la table t1.

Session de lecteur

Résultat de la requête :

 locktype | relation |        mode         |   backend_type
----------+----------+---------------------+-------------------
 relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)