LWLock:BufferMapping (LWLock:buffer_mapping)
이 이벤트는 세션이 데이터 블록을 공유 버퍼 풀의 버퍼와 연결하기 위해 대기 중일 때 발생합니다.
참고
RDS for PostgreSQL 버전 13 이상에서 이 이벤트의 이름은 LWLock:BufferMapping입니다. RDS for PostgreSQL 버전 12 이전에서 이 이벤트의 이름은 LWLock:buffer_mapping입니다.
지원되는 엔진 버전
이 대기 이벤트 정보는 RDS for PostgreSQL 버전 9.6 이상과 관련이 있습니다.
컨텍스트
공유 버퍼 풀은 프로세스에서 사용 중이거나 사용되었던 모든 페이지를 보관하는 PostgreSQL 메모리 영역입니다. 프로세스에 페이지가 필요한 경우 페이지를 공유 버퍼 풀로 읽습니다. shared_buffers 파라미터는 공유 버퍼 크기를 설정하고 테이블 및 인덱스 페이지를 저장할 메모리 영역을 예약합니다. 이 파라미터를 변경하는 경우 데이터베이스를 다시 시작해야 합니다.
LWLock:buffer_mapping 대기 이벤트는 다음 시나리오에서 발생합니다.
-
프로세스가 버퍼 테이블에서 페이지를 검색하고 공유 버퍼 매핑 잠금을 획득합니다.
-
프로세스가 페이지를 버퍼 풀로 로드하고 배타적 버퍼 매핑 잠금을 획득합니다.
-
프로세스가 페이지를 버퍼 풀로 로드하고 배타적 버퍼 매핑 잠금을 획득합니다.
원인
이 이벤트가 정상보다 많이 발생하여 성능 문제가 발생할 수 있는 경우 데이터베이스가 공유 버퍼 풀에 페이징 및 페이징 중입니다. 일반적인 원인은 다음과 같습니다.
-
대규모 쿼리
-
부풀린 인덱스 및 테이블
-
전체 테이블 스캔
-
작업 세트보다 작은 공유 풀 크기
작업
대기 이벤트의 원인에 따라 다른 작업을 권장합니다.
버퍼 관련 지표 모니터링
LWLock:buffer_mapping이 스파이크를 기다렸다가 버퍼 적중률을 조사합니다. 이러한 지표를 사용하여 버퍼 캐시에서 발생하는 상황을 더 잘 이해할 수 있습니다. 다음 지표를 검토합니다.
blks_hit-
이 성능 개선 도우미 카운터 지표는 공유 버퍼 풀에서 검색된 블록 수를 나타냅니다.
LWLock:buffer_mapping대기 이벤트가 발생하면blks_hit에서 스파이크가 발생할 수 있습니다. blks_read-
이 성능 개선 도우미 카운터 지표는 공유 버퍼 풀에서 I/O를 읽어야 하는 블록 수를 나타냅니다.
LWLock:buffer_mapping대기 이벤트의 리드업에서blks_read의 스파이크가 발생할 수 있습니다.
인덱싱 전략 평가
인덱싱 전략의 성능 저하가 아닌지 확인하려면 다음을 알아보세요.
- 인덱스 팽창
-
인덱스와 테이블 팽창으로 인해 불필요한 페이지가 공유 버퍼로 읽히지 않는지 확인합니다. 테이블에 사용되지 않는 행이 포함된 경우 데이터를 보관하고 테이블에서 행을 제거하는 것이 좋습니다. 그런 다음 크기가 조정된 테이블의 인덱스를 다시 작성할 수 있습니다.
- 자주 사용하는 쿼리의 인덱스
-
최적의 인덱스가 있는지 확인하려면 성능 개선 도우미에서 DB 엔진 지표를 모니터링하세요.
tup_returned지표는 읽은 행의 수를 보여줍니다.tup_fetched지표는 클라이언트에게 반환되는 행 수를 보여줍니다tup_returned가tup_fetched보다 훨씬 큰 경우, 데이터가 제대로 인덱스화되지 않을 수 있습니다. 또한 테이블 통계가 최신 상태가 아닐 수도 있습니다.
신속하게 할당해야 하는 버퍼 수 저감
LWLock:buffer_mapping 대기 이벤트를 줄이려면, 신속하게 할당해야 하는 버퍼 수를 줄이세요. 한 가지 전략은 소규모 배치 작업을 수행하는 것입니다. 테이블을 분할하여 더 작은 배치를 달성할 수 있습니다.
