Lock:transactionid

L'événement Lock:transactionid se produit lorsqu'une transaction attend un verrou au niveau ligne.

Versions de moteur prises en charge

Ces informations sur les événements d'attente s'appliquent à toutes les versions d'Aurora PostgreSQL.

Contexte

L'événement Lock:transactionid se produit lorsqu'une transaction tente d'acquérir un verrou de niveau ligne qui a déjà été accordé à une transaction exécutée en même temps. La session qui présente l'événement d'attente Lock:transactionid est bloquée à cause de ce verrou. Une fois la transaction de blocage terminée dans une instruction COMMIT ou ROLLBACK, la transaction bloquée peut se poursuivre.

La sémantique de contrôle de simultanéité multiversion d'Aurora PostgreSQL garantit l'absence de blocage des lecteurs par les dispositifs d'écriture, et vice versa. Pour que des conflits se produisent au niveau ligne, les transactions de blocage et les transactions bloquées doivent émettre des instructions conflictuelles des types suivants :

• UPDATE

• SELECT … FOR UPDATE

• SELECT … FOR KEY SHARE

L'instruction SELECT … FOR KEY SHARE est un cas particulier. La base de données utilise la clause FOR KEY SHARE pour optimiser les performances de l'intégrité référentielle. La présence d'un verrou de niveau ligne sur une ligne peut bloquer les commandes INSERT, UPDATE et DELETE sur d'autres tables qui font référence à la ligne.

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

Un événement trop fréquent est généralement dû à des instructions UPDATE, SELECT … FOR UPDATE ou SELECT … FOR KEY SHARE combinées aux conditions suivantes.

Rubriques

• Forte simultanéité
• État Idle in transaction (Transaction inactive)
• Transactions de longue durée

Forte simultanéité

Aurora PostgreSQL peut utiliser une sémantique de verrouillage détaillée de niveau ligne. La probabilité de conflits au niveau ligne augmente lorsque les conditions suivantes sont réunies :

• Une charge de travail à forte simultanéité se dispute les mêmes lignes.

• La simultanéité augmente.

État Idle in transaction (Transaction inactive)

Parfois, la colonne pg_stat_activity.state affiche la valeur idle in transaction. Cette valeur apparaît pour les sessions qui ont entamé une transaction, mais qui n'ont pas encore émis de commande COMMIT ou ROLLBACK. Si la valeur pg_stat_activity.state n'est pas active, la requête affichée dans pg_stat_activity est la plus récente à avoir été exécutée. La session de blocage ne traite pas activement une requête, car une transaction ouverte comporte un verrou.

Si une transaction inactive a acquis un verrou au niveau ligne, cela peut empêcher d'autres sessions de l'acquérir. Cette condition entraîne l'apparition fréquente de l'événement d'attente Lock:transactionid. Pour diagnostiquer le problème, examinez la sortie de pg_stat_activity et pg_locks.

Transactions de longue durée

Les transactions qui s'exécutent depuis longtemps comportent des verrous pendant longtemps. Ces verrous de longue durée peuvent bloquer l'exécution d'autres transactions.

Actions

Le verrouillage de ligne correspond à un conflit entre les instructions UPDATE, SELECT … FOR UPDATE ou SELECT … FOR KEY SHARE. Avant de rechercher une solution, déterminez quand ces instructions sont exécutées sur la même ligne. Utilisez ces informations pour choisir une des stratégies décrites dans les sections suivantes.

Rubriques

• Réagissez à une forte simultanéité
• Réagissez aux transactions inactives
• Réagissez aux transactions de longue durée

Réagissez à une forte simultanéité

En cas de problème lié à la simultanéité, essayez l'une des techniques suivantes :

• Réduisez la simultanéité dans l'application. Par exemple, réduisez le nombre de sessions actives.

• Implémentez un groupe de connexions. Pour savoir comment regrouper des connexions à l'aide de RDS Proxy, consultez Utilisation d'Amazon RDS Proxy pour Aurora.

• Concevez l'application ou le modèle de données de manière à éviter les instructions UPDATE et SELECT … FOR UPDATE conflictuelles. Vous pouvez également réduire le nombre de clés étrangères accessibles par les instructions SELECT … FOR KEY SHARE.

Réagissez aux transactions inactives

Si pg_stat_activity.state indique idle in transaction, utilisez les stratégies suivantes :

• Si possible, activez la validation automatique. Cette approche empêche les transactions de bloquer d'autres transactions en attendant une instruction COMMIT ou ROLLBACK.

• Recherchez les chemins de code qui ne contiennent pas d'instruction COMMIT, ROLLBACK ou END.

• Assurez-vous que la logique de gestion des exceptions de votre application comporte toujours un chemin vers une end of transaction valide.

• Assurez-vous que votre application traite les résultats des requêtes après avoir mis fin à la transaction avec COMMIT ou ROLLBACK.

Réagissez aux transactions de longue durée

Si des transactions de longue durée sont à l'origine de l'apparition fréquente de Lock:transactionid, essayez les stratégies suivantes :

• N'utilisez pas de verrous de ligne dans les transactions de longue durée.

• Limitez la longueur des requêtes en implémentant la validation automatique chaque fois que possible.