Lock:tuple

L'événement Lock:tuple se produit lorsqu'un processus backend attend d'acquérir un verrou sur un tuple.

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

L'événement Lock:tuple indique qu'un backend attend d'acquérir un verrou sur un tuple alors qu'un autre moteur détient un verrou conflictuel sur le même tuple. Le tableau suivant illustre un scénario dans lequel les sessions génèrent l'événement Lock:tuple.

Heure	Session 1	Session 2	Session 3
t1	Démarre une transaction.
t2	Met à jour la ligne 1.
t3		Met à jour la ligne 1. La session acquiert un verrou exclusif sur le tuple, puis attend que la session 1 libère le verrou par le biais d'une validation ou d'une restauration.
t4			Met à jour la ligne 1. La session attend que la session 2 libère le verrou exclusif sur le tuple.

Vous pouvez également simuler cet événement d'attente à l'aide de l'outil de définition de points de référence pgbench. Configurez un nombre élevé de sessions simultanées pour mettre à jour la même ligne au sein d'une table avec un fichier SQL personnalisé.

Pour en savoir plus sur les modes de verrouillage conflictuels, consultez Explicit Locking dans la documentation PostgreSQL. Pour en savoir plus sur pgbench, consultez pgbench dans la documentation PostgreSQL.

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

Un événement de ce type trop fréquent peut révéler un problème de performances dont les causes sont généralement les suivantes :

• Un grand nombre de sessions simultanées tentent d'acquérir un verrou conflictuel pour le même tuple en exécutant des instructions UPDATE ou DELETE.

• Les sessions à forte simultanéité exécutent une instruction SELECT en utilisant les modes de verrouillage FOR UPDATE ou FOR NO KEY UPDATE.

• Divers facteurs poussent les groupes d'applications ou de connexions à ouvrir davantage de sessions pour exécuter les mêmes opérations. Comme de nouvelles sessions tentent de modifier les mêmes lignes, la charge de base de données peut augmenter et un événement Lock:tuple peut apparaître.

Pour en savoir plus, consultez Row-Level Locks dans la documentation PostgreSQL.

Actions

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

Rubriques

• Examinez la logique de votre application

• Recherchez la session de blocage

• Réduisez la simultanéité lorsqu'elle est forte

• Résolvez les problèmes liés aux goulots d'étranglement

Examinez la logique de votre application

Déterminez si une session de blocage est restée longtemps dans l'état idle in transaction. Si tel est le cas, la solution à court terme peut consister à mettre fin à la session de blocage. Vous pouvez utiliser la fonction pg_terminate_backend. Pour en savoir plus sur cette fonction, consultez Server Signaling Functions dans la documentation PostgreSQL.

Pour une solution à long terme, procédez comme suit :

• Modifiez la logique de l'application.

• Utilisez le paramètre idle_in_transaction_session_timeout. Ce paramètre met fin à toute session associée à une transaction ouverte qui est restée inactive plus longtemps que la durée spécifiée. Pour en savoir plus, consultez Client Connection Defaults dans la documentation PostgreSQL.

• Chaque fois que possible, utilisez la validation automatique. Pour en savoir plus, consultez SET AUTOCOMMIT dans la documentation PostgreSQL.

Recherchez la session de blocage

Pendant l'événement d'attente Lock:tuple, identifiez le blocage et la session bloquée en déterminant quels verrous dépendent les uns des autres. Pour en savoir plus, consultez Lock dependency information dans le wiki PostgreSQL.

L'exemple suivant interroge toutes les sessions, en y appliquant le filtre tuple et en les classant par wait_time.

SELECT blocked_locks.pid AS blocked_pid,
         blocking_locks.pid AS blocking_pid,
         blocked_activity.usename AS blocked_user,
         blocking_activity.usename AS blocking_user,
         now() - blocked_activity.xact_start AS blocked_transaction_duration,
         now() - blocking_activity.xact_start AS blocking_transaction_duration,
         concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
         concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
         blocked_activity.state AS blocked_state,
         blocking_activity.state AS blocking_state,
         blocked_locks.locktype AS blocked_locktype,
         blocking_locks.locktype AS blocking_locktype,
         blocked_activity.query AS blocked_statement,
         blocking_activity.query AS blocking_statement
    FROM pg_catalog.pg_locks blocked_locks
    JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
    JOIN pg_catalog.pg_locks blocking_locks
        ON blocking_locks.locktype = blocked_locks.locktype
        AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
        AND blocking_locks.pid != blocked_locks.pid
    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
    WHERE NOT blocked_locks.GRANTED;

Réduisez la simultanéité lorsqu'elle est forte

L'événement Lock:tuple peut se produire constamment, en particulier lorsque la charge de travail est élevée. Dans ce cas, réduisez la simultanéité pour les lignes très occupées. Souvent, quelques lignes seulement contrôlent une file d'attente ou la logique booléenne, ce qui explique pourquoi ces lignes sont très occupées.

Vous pouvez réduire la simultanéité en utilisant différentes approches basées sur les besoins métier, la logique de l'application et le type de charge de travail. Par exemple, vous pouvez effectuer les opérations suivantes :

• Redéfinissez la logique de votre table et de vos données pour réduire la simultanéité.

• Modifiez la logique de l'application pour réduire la simultanéité au niveau ligne.

• Exploitez et redéfinissez les requêtes avec des verrous de niveau ligne.

• Utilisez la clause NOWAIT lors des nouvelles tentatives.

• Envisagez d'utiliser un contrôle de simultanéité logique optimiste et à verrouillage hybride.

• Envisagez de modifier le niveau d'isolement de la base de données.

Résolvez les problèmes liés aux goulots d'étranglement

L'événement Lock:tuple peut se produire avec des goulots d'étranglement tels qu'une pénurie d'UC ou une saturation de la bande passante d'Amazon EBS. Pour réduire les goulots d'étranglement, adoptez les approches suivantes :

• Procédez à une augmentation d'échelle de votre type de classe d'instance.

• Optimisez les requêtes gourmandes en ressources.

• Modifiez la logique de l'application.

• Archivez les données rarement consultées.