LWLock:lock_manager (LWLock:lockmanager) - 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.

LWLock:lock_manager (LWLock:lockmanager)

Cet événement se produit lorsque le moteur RDS for PostgreSQL conserve la zone de mémoire du verrou partagé pour allouer, vérifier et libérer un verrou quand il est impossible d'utiliser un verrou à chemin d'accès rapide.

Versions de moteur prises en charge

Ces informations sur les événements d'attente s'appliquent à RDS for PostgreSQL 9.6 et versions ultérieures. Pour les versions de RDS for PostgreSQL antérieures à la version 13, le nom de cet événement d'attente est LWLock:lock_manager. Pour RDS for PostgreSQL 13 et versions ultérieures, le nom de cet événement d'attente est LWLock:lockmanager.

Contexte

Lorsque vous émettez une instruction SQL, RDS for PostgreSQL enregistre des verrous pour protéger la structure, les données et l'intégrité de votre base de données pendant les opérations simultanées. Le moteur peut atteindre cet objectif en utilisant un verrou à chemin d'accès rapide ou non rapide. Un verrou à chemin d'accès non rapide est plus coûteux et génère plus de frais qu'un verrou à chemin d'accès rapide.

Verrouillage à chemin d'accès rapide

Pour réduire les frais liés aux verrous qui sont fréquemment acquis et libérés, mais qui entrent rarement en conflit, les processus backend peuvent utiliser le verrouillage à chemin d'accès rapide. La base de données utilise ce mécanisme pour les verrous qui répondent aux critères suivants :

  • Ils utilisent la méthode de verrouillage DEFAULT.

  • Ils représentent un verrou sur une relation de base de données plutôt qu'une relation partagée.

  • Il s'agit de verrous faibles qui sont peu susceptibles d'entrer en conflit.

  • Le moteur peut rapidement vérifier qu'aucun verrou conflictuel ne peut exister.

Le moteur ne peut pas utiliser de verrouillage à chemin d'accès rapide lorsque l'une des conditions suivantes est vraie :

  • Le verrou ne répond pas aux critères précédents.

  • Il n'y a plus d'emplacements disponibles pour le processus backend.

Pour ajuster vos requêtes pour le verrouillage à chemin d'accès rapide, vous pouvez utiliser la requête suivante.

SELECT count(*), pid, mode, fastpath
  FROM pg_locks
 WHERE fastpath IS NOT NULL
 GROUP BY 4,3,2
 ORDER BY pid, mode;
 count | pid  |      mode       | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock   | t

La requête suivante affiche uniquement le total sur la base de données.

SELECT count(*), mode, fastpath
  FROM pg_locks
 WHERE fastpath IS NOT NULL
 GROUP BY 3,2
 ORDER BY mode,1;
count |      mode       | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock   | t
(3 rows)

Pour en savoir plus sur le verrouillage à chemin d'accès rapide, consultez fast path dans le fichier README du gestionnaire de verrous PostgreSQL et pg-locks dans la documentation PostgreSQL.

Exemple de problème de mise à l'échelle pour le gestionnaire de verrous

Dans cet exemple, une table nommée purchases stocke cinq ans de données, partitionnées par jour. Chaque partition possède deux index. La séquence d'événements suivante se produit :

  1. Vous interrogez des données réparties sur différents jours, ce qui oblige la base de données à lire de nombreuses partitions.

  2. La base de données crée une entrée de verrou pour chaque partition. Si les index de partition font partie du chemin d'accès de l'optimiseur, la base de données crée également une entrée de verrou pour eux.

  3. Lorsque le nombre d'entrées de verrou demandées pour le même processus backend est supérieur à 16, ce qui correspond à la valeur de FP_LOCK_SLOTS_PER_BACKEND, le gestionnaire de verrous utilise la méthode de verrouillage à chemin d'accès non rapide.

Les applications modernes peuvent comporter des centaines de sessions. Si des sessions simultanées interrogent le parent sans élaguer correctement les partitions, la base de données peut créer des centaines, voire des milliers, de verrous à chemin d'accès non rapide. En général, lorsque cette simultanéité est supérieure au nombre de vCPU, l'événement d'attente LWLock:lock_manager apparaît.

Note

L'événement d'attente LWLock:lock_manager n'est pas lié au nombre de partitions ou d'index contenus dans un schéma de base de données. Il est plutôt lié au nombre de verrous à chemin d'accès non rapide que la base de données doit contrôler.

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

Lorsque l'événement d'attente LWLock:lock_manager se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performances, les causes les plus probables des pics soudains sont les suivantes :

  • Les sessions actives simultanées exécutent des requêtes qui n'utilisent pas de verrous à chemin d'accès rapide. Ces sessions dépassent également le nombre maximum de vCPU.

  • Un grand nombre de sessions actives simultanées accèdent à une table fortement partitionnée. Chaque partition possède plusieurs index.

  • La base de données subit une tempête de connexions. Par défaut, certaines applications et certains logiciels de regroupement de connexions créent davantage de connexions lorsque la base de données est lente. Cette pratique aggrave le problème. Réglez le logiciel de regroupement de connexions de manière à éviter les tempêtes de connexions.

  • Un grand nombre de sessions interrogent une table parente sans élaguer les partitions.

  • Un langage de définition de données (DDL), un langage de manipulation de données (DML) ou une commande de maintenance verrouille exclusivement une relation occupée ou des tuples fréquemment consultés ou modifiés.

Actions

L'événement d'attente CPU n'est pas nécessairement lié à un problème de performances. Ne réagissez à cet événement que lorsque les performances se dégradent et que cet événement d'attente domine la charge de la base de données.

Élaguez les partitions

L'élagage des partitions est une stratégie d'optimisation des requêtes pour tables partitionnées de manière déclarative, qui exclut les partitions inutiles des analyses de tables, améliorant ainsi les performances. L'élagage des partitions est activé par défaut. S'il est désactivé, activez-le comme suit.

SET enable_partition_pruning = on;

Les requêtes peuvent tirer parti de l'élagage des partitions lorsque leur clause WHERE contient la colonne utilisée pour le partitionnement. Pour en savoir plus, consultez Partition Pruning dans la documentation PostgreSQL.

Supprimez les index inutiles

Votre base de données peut contenir des index inutilisés ou rarement utilisés. Si tel est le cas, pensez à les supprimer. Effectuez l'une des actions suivantes :

  • Pour en savoir plus sur la recherche des index inutiles, consultez Unused Indexes dans le wiki PostgreSQL.

  • Exécutez PG Collector. Ce script SQL rassemble les informations de la base de données et les présente sous forme de rapport HTML. Consultez la section « Unused indexes » (Index inutilisés). Pour en savoir plus, consultez pg-collector dans le référentiel GitHub AWS Labs.

Réglez vos requêtes pour qu'elles utilisent le verrouillage à chemin d'accès rapide

Pour savoir si vos requêtes utilisent le verrouillage à chemin d'accès rapide, interrogez la colonne fastpath de la table pg_locks. Si vos requêtes n'utilisent pas le verrouillage à chemin d'accès rapide, essayez de réduire le nombre de relations par requête à moins de 16.

Procédez au réglage d'autres événements d'attente

Si LWLock:lock_manager est premier ou deuxième dans la liste des attentes les plus fréquentes, vérifiez si les événements d'attente suivants apparaissent également dans la liste :

  • Lock:Relation

  • Lock:transactionid

  • Lock:tuple

S'ils figurent parmi les premiers de la liste, commencez par régler ces événements d'attente. Ces événements peuvent être un moteur pour LWLock:lock_manager.

Réduisez les goulots d'étranglement matériels

Un goulot d'étranglement matériel peut se produire, comme une pénurie d'UC ou une saturation de votre bande passante Amazon EBS. Envisagez alors de réduire les goulots d'étranglement matériels. Procédez comme suit :

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

  • Optimisez les requêtes qui sollicitent énormément l'UC et la mémoire.

  • Modifiez la logique de votre application.

  • Archivez vos données.

Pour en savoir plus sur l'UC, la mémoire et la bande passante réseau EBS, consultez Types d'instances Amazon RDS.

Utilisez une fonction de regroupement de connexions

Si le nombre total de connexions actives dépasse le nombre maximal de vCPU, cela signifie que l'UC requise par les processus du système d'exploitation est supérieure à ce que votre type d'instance peut prendre en charge. Dans ce cas, vous pouvez utiliser ou régler un groupe de connexions. Pour en savoir plus sur les vCPU relatifs à votre type d'instance, consultez Types d'instances Amazon RDS.

Pour en savoir plus sur les groupes de connexions, consultez les ressources suivantes :

Mise à niveau de votre version de RDS for PostgreSQL

Si votre version actuelle de RDS for PostgreSQL est inférieure à 12, procédez à une mise à niveau vers la version 12 ou ultérieure. PostgreSQL versions 12 et ultérieures disposent d'un mécanisme de partition amélioré. Pour en savoir plus la version 12, consultez le document PostgreSQL 12.0 Release Notes. Pour plus d'informations sur la mise à niveau de RDS for PostgreSQL, consultez Mises à niveau du moteur de base de données RDS pour SQL Postgre.