Lock:extend
Lock:extend
이벤트는 백엔드 프로세스가 릴레이션을 확장하기 위해 릴레이션을 잠그기를 기다리는 동안 다른 프로세스에서 동일한 목적으로 해당 릴레이션에 대한 잠금이 있는 경우에 발생합니다.
지원되는 엔진 버전
이 대기 이벤트 정보는 모든 Aurora PostgreSQL 버전에서 지원됩니다.
컨텍스트
이벤트 Lock:extend
는 백엔드 프로세스가 관계를 확장하는 동안 다른 백엔드 프로세스가 잠금을 유지하는 관계를 확장하기 위해 대기 중임을 나타냅니다. 한 번에 하나의 프로세스만 관계를 확장할 수 있기 때문에 시스템은 Lock:extend
대기 이벤트를 생성합니다. INSERT
,COPY
, 및 UPDATE
연산은 이 이벤트를 생성할 수 있습니다.
대기 증가의 가능한 원인
Lock:extend
이벤트가 정상보다 많이 나타나 성능 문제를 나타내는 경우 일반적인 원인은 다음과 같습니다.
- 동일한 테이블에 대한 동시 삽입 또는 업데이트 서지
-
동일한 테이블에 삽입하거나 업데이트하는 쿼리의 동시 세션 수가 증가할 수 있습니다.
- 네트워크 대역폭 부족
-
DB 인스턴스의 네트워크 대역폭이 현재 워크로드의 스토리지 통신 요구 사항에 따라 충분하지 않을 수 있습니다. 이로 인해
Lock:extend
이벤트에서 스토리지 지연 시간이 증가할 수 있습니다.
작업
대기 이벤트의 원인에 따라 다른 작업을 권장합니다.
동일한 관계식으로 동시 삽입 및 업데이트 감소
먼저, 증가가 있는지 확인합니다. tup_inserted
와 tup_updated
지표 및 이 대기 이벤트의 증가가 수반됩니다. 그렇다면 삽입 및 업데이트 작업에 대한 경합이 높은 관계식을 확인합니다. 이를 확인하려면 n_tup_ins
및 n_tup_upd
필드의 값을 위한 pg_stat_all_tables
뷰를 쿼리하세요. pg_stat_all_tables
뷰에 대한 자세한 내용은 PostgreSQL 설명서의 pg_stat_statements
차단 및 차단된 쿼리에 대한 자세한 정보를 위해서 다음 예와 같이 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 설명서의 테이블 생성
을 참조하세요. 중요
필팩터를 변경하는 경우 이 값을 변경하면 워크로드에 따라 성능에 부정적인 영향을 줄 수 있으므로 시스템을 테스트하는 것이 좋습니다.
네트워크 대역폭 향상
쓰기 지연 시간이 증가하는지 확인하려면 CloudWatch의 WriteLatency
지표를 확인하세요. 그렇다면, WriteThroughput
과 ReadThroughput
DB Amazon CloudWatch 지표를 사용하여 DB 클러스터의 스토리지 관련 트래픽을 모니터링하세요. 이러한 지표는 네트워크 대역폭이 워크로드의 스토리지 활동에 충분한지 확인하는 데 도움이 될 수 있습니다.
네트워크 대역폭이 충분하지 않으면 늘리세요. 만약 클라이언트 또는 DB 인스턴스가 네트워크 대역폭 제한에 도달했다면. 대역폭을 늘리는 유일한 방법은 DB 인스턴스 크기를 늘리는 것입니다.
CloudWatch 지표에 대한 자세한 내용은 Amazon Aurora에 대한 Amazon CloudWatch 지표 섹션을 참조하세요. 각 DB 인스턴스 클래스에 대한 네트워크 성능에 관한 자세한 내용은 Aurora에 대한 DB 인스턴스 클래스의 하드웨어 사양 섹션을 참조하세요.