LWLock:buffer_content (BufferContent)
LWLock:buffer_content 이벤트는 다른 세션에서 특정 데이터 페이지에 대해 쓰기 잠금을 설정한 동안 세션에서 메모리 내 해당 페이지 읽기 또는 쓰기를 대기 중일 때 발생합니다. Aurora PostgreSQL 13 이상에서는 BufferContent 대기 이벤트가 호출됩니다.
지원되는 엔진 버전
이 대기 이벤트 정보는 모든 Aurora PostgreSQL 버전에서 지원됩니다.
컨텍스트
데이터를 읽거나 조작하기 위해 PostgreSQL 공유 메모리 버퍼를 통해 데이터에 액세스합니다. 버퍼에서 읽기 위해 프로세스는 공유 모드에서 버퍼 콘텐츠에 대한 경량 잠금(LWLock) 을 가져옵니다. 버퍼에 쓰려면 배타적 모드에서 해당 잠금을 가져옵니다. 공유 잠금을 사용하면 다른 프로세스가 동시에 해당 콘텐츠에 대한 공유 잠금을 획득할 수 있습니다. 배타적 잠금은 다른 프로세스에서 모든 유형의 잠금을 얻지 못하게 합니다.
LWLock:buffer_content(BufferContent) 이벤트는 여러 프로세스가 특정 버퍼의 내용에 대해 경량 잠금(LWLocks)을 가져오려고 시도하고 있음을 나타냅니다.
대기 증가의 가능한 원인
LWLock:buffer_content(BufferContent) 이벤트가 정상보다 많이 나타나 성능 문제를 나타내는 경우 일반적인 원인은 다음과 같습니다.
- 동일한 데이터에 대한 동시 업데이트 증가
-
동일한 테이블에 삽입하거나 업데이트하는 쿼리의 동시 세션 수가 증가할 수 있습니다. 이 경합은 인덱스가 많은 테이블에서 더 두드러질 수 있습니다.
- 워크로드 데이터가 메모리에 없습니다.
-
활성 워크로드에서 처리 중인 데이터가 메모리에 없으면 이러한 대기 이벤트가 증가할 수 있습니다. 이 효과는 잠금을 유지하는 프로세스가 디스크 I/O 작업을 수행하는 동안 더 오래 유지할 수 있기 때문입니다.
- 외래 키 제약 조건을 과도하게 사용
-
외래 키 제약 조건은 프로세스가 버퍼 콘텐츠 잠금에 보관하는 시간을 늘릴 수 있습니다. 이 효과는 해당 키가 업데이트되는 동안 읽기 작업에서 참조된 키에 대해 공유 버퍼 콘텐츠 잠금이 필요하기 때문입니다.
작업
대기 이벤트의 원인에 따라 다른 작업을 권장합니다. Amazon RDS 성능 개선 도우미를 사용하거나 pg_stat_activity 뷰를 쿼리하여 LWLock:buffer_content(BufferContent) 이벤트를 식별할 수 있습니다.
인메모리 효율성 향상
활성 워크로드 데이터가 메모리에 있을 확률을 높이려면 테이블을 분할하거나 인스턴스 클래스를 확장하세요. DB 인스턴스 클래스에 대한 자세한 내용은 Amazon AuroraDB 인스턴스 클래스 섹션을 참조하세요.
DB 클러스터에서 DB 인스턴스의 버퍼 캐시가 제공하는 요청 백분율을 측정하는 BufferCacheHitRatio 지표를 모니터링합니다. 이 지표는 메모리에서 제공되는 데이터의 양에 대한 인사이트를 제공합니다. 적중률이 높으면 DB 인스턴스에 작업 데이터 세트에 사용할 수 있는 메모리가 충분하다는 의미이고, 낮으면 쿼리가 스토리지에서 데이터에 자주 액세스하고 있다는 의미입니다.
PG Collector
외래 키 제약 조건 사용 감소
외래 키 제약 조건을 사용을 위해 많은 수의 LWLock:buffer_content(BufferContent) 대기 이벤트를 경험하는 워크로드를 조사합니다. 불필요한 외래 키 제약 조건을 제거합니다.
사용되지 않는 인덱스 삭제
많은 수의 LWLock:buffer_content(BufferContent) 대기 이벤트를 경험하는 워크로드를 위해 사용하지 않는 인덱스를 식별하고 제거합니다.
PG Collector
중복 인덱스 제거
중복 인덱스를 식별하고 제거합니다.
PG Collector
잘못된 인덱스 삭제 또는 REINDEX
잘못된 인덱스는 일반적으로 CREATE INDEX CONCURRENTLY 또는 REINDEX CONCURRENTLY를 사용하고 명령이 실패하거나 중단될 때 발생합니다.
잘못된 인덱스는 여전히 업데이트되고 디스크 공간을 차지하지만, 쿼리에 사용할 수 없습니다.
PG Collector
부분 인덱스 사용
부분 인덱스를 활용하여 쿼리 성능을 개선하고 인덱스 크기를 줄일 수 있습니다. 부분 인덱스는 조건식으로 정의된 하위 집합을 사용하여 테이블의 하위 집합을 통해 빌드된 인덱스입니다. 부분 인덱스
테이블 및 인덱스 팽창 제거
과도한 테이블 및 인덱스 팽창은 데이터베이스 성능에 부정적인 영향을 미칠 수 있습니다. 테이블과 인덱스가 팽창하면 활성 작업 세트 크기가 증가하여 인 메모리 효율성이 저하됩니다. 또한 팽창은 스토리지 비용을 늘리고 쿼리 실행 속도를 늦춥니다. 팽창을 진단하려면 테이블 및 인덱스 팽창 진단 섹션을 참조하세요. 또한 PG Collector
테이블 및 인덱스 팽창을 해결하기 위한 몇 가지 옵션이 있습니다.
- VACUUM FULL
-
VACUUM FULL은 라이브 튜플만 복사하여 테이블의 새 복사본을 만든 다음,ACCESS EXCLUSIVE잠금을 유지하는 동안 이전 테이블을 새 테이블로 바꿉니다. 이렇게 하면 테이블에 대한 읽기 또는 쓰기가 방지되어 중단이 발생할 수 있습니다. 또한 테이블이 크면VACUUM FULL에 더 오래 걸립니다. - pg_repack
-
pg_repack은VACUUM FULL이 적합하지 않은 상황에서 유용합니다. 팽창된 테이블의 데이터가 포함된 새 테이블을 만들고 원본 테이블의 변경 사항을 추적한 다음 원본 테이블을 새 테이블로 바꿉니다. 새 테이블을 빌드하는 동안 읽기 또는 쓰기 작업을 위해 원본 테이블을 잠그지 않습니다.pg_repack을 사용하는 방법에 대한 자세한 내용은 pg_repack및 Removing bloat with pg_repack을 참조하세요. - REINDEX
-
REINDEX명령을 활용하여 인덱스 팽창을 해결할 수 있습니다.REINDEX는 데드 페이지 또는 비어 있거나 거의 비어 있는 페이지 없이 인덱스의 새 버전을 작성하여 인덱스의 공간 소비를 줄입니다.REINDEX명령에 대한 자세한 내용은 REINDEX 설명서를 참조하세요.
테이블 및 인덱스에서 팽창을 제거한 후 해당 테이블의 autovacuum 빈도를 늘려야 할 수 있습니다. 테이블 수준에서 적극적인 autovacuum 설정을 구현하면 향후 팽창이 발생하지 않도록 방지할 수 있습니다. 자세한 내용은 Vacuuming and analyzing tables
automatically의 설명서를 참조하세요.
