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.
**Topics**
+ [Versions de moteur prises en charge](#apg-waits.lockextend.context.supported)
+ [Contexte](#apg-waits.lockextend.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#apg-waits.lockextend.causes)
+ [Actions](#apg-waits.lockextend.actions)
## 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.
**Topics**
+ [Réduisez les insertions et les mises à jour simultanées dans la même relation](#apg-waits.lockextend.actions.action1)
+ [Augmentez la bande passante réseau](#apg-waits.lockextend.actions.increase-network-bandwidth)
### 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\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) 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\$1partman](PostgreSQL_Partitions.md).
+ 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](https://www.postgresql.org/docs/13/sql-createtable.html) 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 plus d’informations sur les métriques CloudWatch, consultez [CloudWatch Métriques Amazon pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). 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'instances de base de données pour Aurora](Concepts.DBInstanceClass.Summary.md).