# Lock:extend
`Lock:extend` 이벤트는 백엔드 프로세스가 릴레이션을 확장하기 위해 릴레이션을 잠그기를 기다리는 동안 다른 프로세스에서 동일한 목적으로 해당 릴레이션에 대한 잠금이 있는 경우에 발생합니다.
**Topics**
+ [지원되는 엔진 버전](#apg-waits.lockextend.context.supported)
+ [컨텍스트](#apg-waits.lockextend.context)
+ [대기 증가의 가능한 원인](#apg-waits.lockextend.causes)
+ [작업](#apg-waits.lockextend.actions)
## 지원되는 엔진 버전
이 대기 이벤트 정보는 모든 Aurora PostgreSQL 버전에서 지원됩니다.
## 컨텍스트
이벤트 `Lock:extend`는 백엔드 프로세스가 관계를 확장하는 동안 다른 백엔드 프로세스가 잠금을 유지하는 관계를 확장하기 위해 대기 중임을 나타냅니다. 한 번에 하나의 프로세스만 관계를 확장할 수 있기 때문에 시스템은 `Lock:extend` 대기 이벤트를 생성합니다. `INSERT`,`COPY`, 및 `UPDATE` 연산은 이 이벤트를 생성할 수 있습니다.
## 대기 증가의 가능한 원인
`Lock:extend` 이벤트가 정상보다 많이 나타나 성능 문제를 나타내는 경우 일반적인 원인은 다음과 같습니다.
**동일한 테이블에 대한 동시 삽입 또는 업데이트 서지 **
동일한 테이블에 삽입하거나 업데이트하는 쿼리의 동시 세션 수가 증가할 수 있습니다.
**네트워크 대역폭 부족**
DB 인스턴스의 네트워크 대역폭이 현재 워크로드의 스토리지 통신 요구 사항에 따라 충분하지 않을 수 있습니다. 이로 인해 `Lock:extend` 이벤트에서 스토리지 지연 시간이 증가할 수 있습니다.
## 작업
대기 이벤트의 원인에 따라 다른 작업을 권장합니다.
**Topics**
+ [동일한 관계식으로 동시 삽입 및 업데이트 감소](#apg-waits.lockextend.actions.action1)
+ [네트워크 대역폭 향상](#apg-waits.lockextend.actions.increase-network-bandwidth)
### 동일한 관계식으로 동시 삽입 및 업데이트 감소
먼저, 증가가 있는지 확인합니다. `tup_inserted`와 `tup_updated` 지표 및 이 대기 이벤트의 증가가 수반됩니다. 그렇다면 삽입 및 업데이트 작업에 대한 경합이 높은 관계식을 확인합니다. 이를 확인하려면 `n_tup_ins` 및 `n_tup_upd` 필드의 값을 위한 `pg_stat_all_tables` 뷰를 쿼리하세요. `pg_stat_all_tables` 뷰에 대한 자세한 내용은 PostgreSQL 설명서의 [pg\_stat\_statements](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW)를 참조하세요.
차단 및 차단된 쿼리에 대한 자세한 정보를 위해서 다음 예와 같이 `pg_stat_activity`를 쿼리하세요.
```
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
```
`Lock:extend` 이벤트 증가에 기여하는 관계를 파악한 후 다음 기슬을 사용하여 경합을 줄입니다.
+ 파티셔닝을 사용하여 동일한 테이블에 대한 경합을 줄일 수 있는지 확인합니다. 삽입되거나 업데이트된 튜플을 다른 파티션으로 분리하면 경합을 줄일 수 있습니다. 파티셔닝에 대한 자세한 내용은 [pg\_partman 확장자를 사용하여 PostgreSQL 파티션 관리하기](PostgreSQL_Partitions.md) 섹션을 참조하세요.
+ 대기 이벤트가 주로 업데이트 활동으로 인한 경우 관계식의 채우기 요소 값을 줄이는 것이 좋습니다. 이렇게 하면 업데이트 중에 새 블록에 대한 요청을 줄일 수 있습니다. 필팩터는 테이블 페이지를 포장하기 위한 최대 공간을 결정하는 테이블의 저장 파라미터입니다. 이 값은 페이지의 전체 공간의 백분율로 표시됩니다. 필팩터 파라미터에 대한 자세한 내용은 PostgreSQL 설명서의 [테이블 생성](https://www.postgresql.org/docs/13/sql-createtable.html)을 참조하세요.
**중요**
필팩터를 변경하는 경우 이 값을 변경하면 워크로드에 따라 성능에 부정적인 영향을 줄 수 있으므로 시스템을 테스트하는 것이 좋습니다.
### 네트워크 대역폭 향상
쓰기 지연 시간이 증가하는지 확인하려면 CloudWatch의 `WriteLatency` 지표를 확인하세요. 그렇다면, `WriteThroughput`과 `ReadThroughput` DB Amazon CloudWatch 지표를 사용하여 DB 클러스터의 스토리지 관련 트래픽을 모니터링하세요. 이러한 지표는 네트워크 대역폭이 워크로드의 스토리지 활동에 충분한지 확인하는 데 도움이 될 수 있습니다.
네트워크 대역폭이 충분하지 않으면 늘리세요. 만약 클라이언트 또는 DB 인스턴스가 네트워크 대역폭 제한에 도달했다면. 대역폭을 늘리는 유일한 방법은 DB 인스턴스 크기를 늘리는 것입니다.
CloudWatch 지표에 대한 자세한 내용은 [Amazon Aurora에 대한 Amazon CloudWatch 지표](Aurora.AuroraMonitoring.Metrics.md) 섹션을 참조하세요. 각 DB 인스턴스 클래스에 대한 네트워크 성능에 관한 자세한 내용은 [Aurora에 대한 DB 인스턴스 클래스의 하드웨어 사양](Concepts.DBInstanceClass.Summary.md) 섹션을 참조하세요.