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

LWLock:lock_manager

Cet événement se produit lorsque le moteur Aurora PostgreSQL conserve la zone de mémoire du verrou partagé pour allouer, vérifier et annuler l'allocation d'un verrou parce qu'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 à Aurora PostgreSQL 9.6 et versions ultérieures.

Contexte

Lorsque vous émettez une instruction SQL, Aurora 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 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

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

Élaguez les partitions

L'élagage des partitions est une stratégie d'optimisation des requêtes 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 :

Mettez à niveau votre version d'Aurora PostgreSQL

Si votre version actuelle d'Aurora PostgreSQL est inférieure à la version 12, procédez à une mise à niveau vers la version 12 ou ultérieure. Les versions 12 et 13 de PostgreSQL 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 en savoir plus sur la mise à niveau d'Aurora PostgreSQL, consultez Mises à jour du moteur de base de données pour Amazon Aurora Postgre SQL.