Lock:extend - 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.

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.

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

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 dans la documentation PostgreSQL.

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. Si tel est le cas, utilisez les métriques Amazon CloudWatch WriteThroughput et ReadThroughput pour surveiller le trafic lié au stockage sur le cluster de bases 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 CloudWatch Métriques Amazon pour Amazon Aurora. Pour en savoir plus sur les performances réseau de chaque classe d'instance de base de données, consultez Spécifications matérielles pour les classes d'instance de base de données pour Aurora.