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:extend
L'événement Lock:extend se produit lorsqu'un processus backend attend de verrouiller une relation pour l'étendre alors qu'un autre processus présente un verrou sur cette relation dans le même but.
Rubriques
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:extend indique qu'un processus backend attend d'étendre une relation sur laquelle un autre processus backend détient un verrou pendant qu'il étend cette relation. Comme un seul processus à la fois peut étendre une relation, le système génère un événement d'attente Lock:extend. Les opérations INSERT, COPY et UPDATE peuvent générer cet événement.
Causes probables de l'augmentation du nombre d'événements d'attente
Un événement Lock:extend trop fréquent peut révéler un problème de performances dont les causes sont généralement les suivantes :
- Augmentation du nombre d'insertions ou de mises à jour simultanées dans la même table
-
Le nombre de sessions simultanées associées à des requêtes d'insertion ou de mise à jour peut augmenter.
- Bande passante réseau insuffisante
-
La bande passante réseau de l'instance de base de données peut être insuffisante pour répondre aux besoins de communication de stockage de la charge de travail actuelle. Cela peut contribuer à une latence de stockage qui entraîne une augmentation des événements
Lock:extend.
Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.
Rubriques
Réduisez les insertions et les mises à jour simultanées dans la même relation
Tout d'abord, déterminez s'il y a une augmentation des métriques tup_inserted et tup_updated, et une augmentation concomitante de cet événement d'attente. Si tel est le cas, déterminez quelles relations sont en conflit pour les opérations d'insertion et de mise à jour. Pour ce faire, interrogez la vue pg_stat_all_tables afin de connaître les valeurs des champs n_tup_ins et n_tup_upd. Pour en savoir plus sur la vue pg_stat_all_tables, consultez pg_stat_all_tables
Pour en savoir plus sur les requêtes de blocage et les requêtes bloquées, interrogez pg_stat_activity comme dans l'exemple suivant :
SELECT blocked.pid, blocked.usename, blocked.query, blocking.pid AS blocking_id, blocking.query AS blocking_query, blocking.wait_event AS blocking_wait_event, blocking.wait_event_type AS blocking_wait_event_type FROM pg_stat_activity AS blocked JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid)) where blocked.wait_event = 'extend' and blocked.wait_event_type = 'Lock'; pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type ------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+-------------------------- 7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
Après avoir identifié les relations qui contribuent à l'augmentation des événements Lock:extend, utilisez les techniques suivantes pour réduire les conflits :
Déterminez si vous pouvez utiliser le partitionnement pour réduire les conflits relatifs à la même table. La séparation des tuples insérés ou mis à jour dans différentes partitions peut réduire les conflits. Pour plus d'informations sur le partitionnement, voir Gestion des partitions PostgreSQL avec l'extension pg_partman.
Si l'événement d'attente est principalement dû à une activité de mise à jour, vous pouvez réduire la valeur du facteur de remplissage de la relation. Cela peut réduire les requêtes de nouveaux blocs lors de la mise à jour. Le facteur de remplissage est un paramètre de stockage relatif à une table qui détermine la quantité maximale d'espace requise pour remplir une page de la table. Il est exprimé en pourcentage de l'espace total d'une page. Pour en savoir plus sur le facteur de remplissage, consultez CREATE TABLE
dans la documentation PostgreSQL. Important
Si vous modifiez le facteur de remplissage, nous vous recommandons vivement de tester votre système, car en fonction de votre charge de travail, la modification de cette valeur peut nuire aux performances.
Augmentez la bande passante réseau
Pour déterminer si la latence d'écriture a augmenté, consultez la métrique WriteLatency dans CloudWatch. Le cas échéant, utilisez les métriques Amazon CloudWatch WriteThroughput et ReadThroughput pour surveiller le trafic lié au stockage sur l'instance de base de données. Ces métriques peuvent vous aider à déterminer si la bande passante réseau est suffisante pour l'activité de stockage de votre charge de travail.
Si la bande passante réseau est insuffisante, augmentez-la. Si votre instance de base de données atteint les limites de sa bande passante réseau, le seul moyen d'augmenter la bande passante est d'augmenter la taille de l'instance de base de données.
Pour de plus amples informations sur les métriques CloudWatch, veuillez consulter Métriques au CloudWatch niveau de l'instance Amazon pour Amazon RDS. Pour en savoir plus sur les performances réseau de chaque classe d'instance de base de données, consultez Métriques au CloudWatch niveau de l'instance Amazon pour Amazon RDS.
