# LWLock:buffer\_content (BufferContent)
<a name="apg-waits.lockbuffercontent"></a>

`LWLock:buffer_content` 이벤트는 다른 세션에서 특정 데이터 페이지에 대해 쓰기 잠금을 설정한 동안 세션에서 메모리 내 해당 페이지 읽기 또는 쓰기를 대기 중일 때 발생합니다. Aurora PostgreSQL 13 이상에서는 `BufferContent` 대기 이벤트가 호출됩니다.

**Topics**
+ [지원되는 엔진 버전](#apg-waits.lockbuffercontent.context.supported)
+ [컨텍스트](#apg-waits.lockbuffercontent.context)
+ [대기 증가의 가능한 원인](#apg-waits.lockbuffercontent.causes)
+ [작업](#apg-waits.lockbuffercontent.actions)

## 지원되는 엔진 버전
<a name="apg-waits.lockbuffercontent.context.supported"></a>

이 대기 이벤트 정보는 모든 Aurora PostgreSQL 버전에서 지원됩니다.

## 컨텍스트
<a name="apg-waits.lockbuffercontent.context"></a>

데이터를 읽거나 조작하기 위해 PostgreSQL 공유 메모리 버퍼를 통해 데이터에 액세스합니다. 버퍼에서 읽기 위해 프로세스는 공유 모드에서 버퍼 콘텐츠에 대한 경량 잠금(LWLock) 을 가져옵니다. 버퍼에 쓰려면 배타적 모드에서 해당 잠금을 가져옵니다. 공유 잠금을 사용하면 다른 프로세스가 동시에 해당 콘텐츠에 대한 공유 잠금을 획득할 수 있습니다. 배타적 잠금은 다른 프로세스에서 모든 유형의 잠금을 얻지 못하게 합니다.

`LWLock:buffer_content`(`BufferContent`) 이벤트는 여러 프로세스가 특정 버퍼의 내용에 대해 경량 잠금(LWLocks)을 가져오려고 시도하고 있음을 나타냅니다.

## 대기 증가의 가능한 원인
<a name="apg-waits.lockbuffercontent.causes"></a>

`LWLock:buffer_content`(`BufferContent`) 이벤트가 정상보다 많이 나타나 성능 문제를 나타내는 경우 일반적인 원인은 다음과 같습니다.

**동일한 데이터에 대한 동시 업데이트 증가**  
동일한 테이블에 삽입하거나 업데이트하는 쿼리의 동시 세션 수가 증가할 수 있습니다. 이 경합은 인덱스가 많은 테이블에서 더 두드러질 수 있습니다.

**워크로드 데이터가 메모리에 없습니다.**  
활성 워크로드에서 처리 중인 데이터가 메모리에 없으면 이러한 대기 이벤트가 증가할 수 있습니다. 이 효과는 잠금을 유지하는 프로세스가 디스크 I/O 작업을 수행하는 동안 더 오래 유지할 수 있기 때문입니다.

**외래 키 제약 조건을 과도하게 사용**  
외래 키 제약 조건은 프로세스가 버퍼 콘텐츠 잠금에 보관하는 시간을 늘릴 수 있습니다. 이 효과는 해당 키가 업데이트되는 동안 읽기 작업에서 참조된 키에 대해 공유 버퍼 콘텐츠 잠금이 필요하기 때문입니다.

## 작업
<a name="apg-waits.lockbuffercontent.actions"></a>

대기 이벤트의 원인에 따라 다른 작업을 권장합니다. Amazon RDS 성능 개선 도우미를 사용하거나 `pg_stat_activity` 뷰를 쿼리하여 `LWLock:buffer_content`(`BufferContent`) 이벤트를 식별할 수 있습니다.

**Topics**
+ [인메모리 효율성 향상](#apg-waits.lockbuffercontent.actions.in-memory)
+ [외래 키 제약 조건 사용 감소](#apg-waits.lockbuffercontent.actions.foreignkey)
+ [사용되지 않는 인덱스 삭제](#apg-waits.lockbuffercontent.actions.indexes)
+ [중복 인덱스 제거](#apg-waits.lockbuffercontent.actions.duplicate-indexes)
+ [잘못된 인덱스 삭제 또는 REINDEX](#apg-waits.lockbuffercontent.actions.invalid-indexes)
+ [부분 인덱스 사용](#apg-waits.lockbuffercontent.actions.partial-indexes)
+ [테이블 및 인덱스 팽창 제거](#apg-waits.lockbuffercontent.actions.bloat)

### 인메모리 효율성 향상
<a name="apg-waits.lockbuffercontent.actions.in-memory"></a>

활성 워크로드 데이터가 메모리에 있을 확률을 높이려면 테이블을 분할하거나 인스턴스 클래스를 확장하세요. DB 인스턴스 클래스에 대한 자세한 내용은 [Amazon AuroraDB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하세요.

DB 클러스터에서 DB 인스턴스의 버퍼 캐시가 제공하는 요청 백분율을 측정하는 `BufferCacheHitRatio` 지표를 모니터링합니다. 이 지표는 메모리에서 제공되는 데이터의 양에 대한 인사이트를 제공합니다. 적중률이 높으면 DB 인스턴스에 작업 데이터 세트에 사용할 수 있는 메모리가 충분하다는 의미이고, 낮으면 쿼리가 스토리지에서 데이터에 자주 액세스하고 있다는 의미입니다.

[PG Collector](https://github.com/awslabs/pg-collector) 보고서의 메모리 설정 섹션에 있는 테이블당 캐시 읽기 적중 및 인덱스당 캐시 읽기 적중은 테이블 및 인덱스 캐시 적중률에 대한 인사이트를 제공할 수 있습니다.

### 외래 키 제약 조건 사용 감소
<a name="apg-waits.lockbuffercontent.actions.foreignkey"></a>

외래 키 제약 조건을 사용을 위해 많은 수의 `LWLock:buffer_content`(`BufferContent`) 대기 이벤트를 경험하는 워크로드를 조사합니다. 불필요한 외래 키 제약 조건을 제거합니다.

### 사용되지 않는 인덱스 삭제
<a name="apg-waits.lockbuffercontent.actions.indexes"></a>

많은 수의 `LWLock:buffer_content`(`BufferContent`) 대기 이벤트를 경험하는 워크로드를 위해 사용하지 않는 인덱스를 식별하고 제거합니다.

[PG Collector](https://github.com/awslabs/pg-collector) 보고서의 미사용 인덱스 섹션은 데이터베이스의 미사용 인덱스에 대한 인사이트를 제공할 수 있습니다.

### 중복 인덱스 제거
<a name="apg-waits.lockbuffercontent.actions.duplicate-indexes"></a>

중복 인덱스를 식별하고 제거합니다.

[PG Collector](https://github.com/awslabs/pg-collector) 보고서의 중복 인덱스 섹션은 데이터베이스의 중복 인덱스에 대한 인사이트를 제공할 수 있습니다.

### 잘못된 인덱스 삭제 또는 REINDEX
<a name="apg-waits.lockbuffercontent.actions.invalid-indexes"></a>

잘못된 인덱스는 일반적으로 `CREATE INDEX CONCURRENTLY` 또는 `REINDEX CONCURRENTLY`를 사용하고 명령이 실패하거나 중단될 때 발생합니다.

잘못된 인덱스는 여전히 업데이트되고 디스크 공간을 차지하지만, 쿼리에 사용할 수 없습니다.

[PG Collector](https://github.com/awslabs/pg-collector) 보고서의 잘못된 인덱스 섹션은 데이터베이스의 잘못된 인덱스에 대한 인사이트를 제공할 수 있습니다.

### 부분 인덱스 사용
<a name="apg-waits.lockbuffercontent.actions.partial-indexes"></a>

부분 인덱스를 활용하여 쿼리 성능을 개선하고 인덱스 크기를 줄일 수 있습니다. 부분 인덱스는 조건식으로 정의된 하위 집합을 사용하여 테이블의 하위 집합을 통해 빌드된 인덱스입니다. [부분 인덱스](https://www.postgresql.org/docs/current/indexes-partial.html) 설명서에 설명된 대로 부분 인덱스는 인덱스 유지 관리 오버헤드를 줄일 수 있습니다. PostgreSQL은 모든 경우에 인덱스를 업데이트할 필요가 없기 때문입니다.

### 테이블 및 인덱스 팽창 제거
<a name="apg-waits.lockbuffercontent.actions.bloat"></a>

과도한 테이블 및 인덱스 팽창은 데이터베이스 성능에 부정적인 영향을 미칠 수 있습니다. 테이블과 인덱스가 팽창하면 활성 작업 세트 크기가 증가하여 인 메모리 효율성이 저하됩니다. 또한 팽창은 스토리지 비용을 늘리고 쿼리 실행 속도를 늦춥니다. 팽창을 진단하려면 [테이블 및 인덱스 팽창 진단](AuroraPostgreSQL.diag-table-ind-bloat.md) 섹션을 참조하세요. 또한 [PG Collector](https://github.com/awslabs/pg-collector) 보고서의 조각화(팽창) 섹션은 테이블 및 인덱스 팽창에 대한 인사이트를 제공할 수 있습니다.

테이블 및 인덱스 팽창을 해결하기 위한 몇 가지 옵션이 있습니다.

**VACUUM FULL**  
`VACUUM FULL`은 라이브 튜플만 복사하여 테이블의 새 복사본을 만든 다음, `ACCESS EXCLUSIVE` 잠금을 유지하는 동안 이전 테이블을 새 테이블로 바꿉니다. 이렇게 하면 테이블에 대한 읽기 또는 쓰기가 방지되어 중단이 발생할 수 있습니다. 또한 테이블이 크면 `VACUUM FULL`에 더 오래 걸립니다.

** pg\_repack **  
`pg_repack`은 `VACUUM FULL`이 적합하지 않은 상황에서 유용합니다. 팽창된 테이블의 데이터가 포함된 새 테이블을 만들고 원본 테이블의 변경 사항을 추적한 다음 원본 테이블을 새 테이블로 바꿉니다. 새 테이블을 빌드하는 동안 읽기 또는 쓰기 작업을 위해 원본 테이블을 잠그지 않습니다. `pg_repack`을 사용하는 방법에 대한 자세한 내용은 [pg\_repack](https://reorg.github.io/pg_repack/) 및 [Removing bloat with pg\_repack](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/pg-repack.html)을 참조하세요.

**REINDEX**  
`REINDEX` 명령을 활용하여 인덱스 팽창을 해결할 수 있습니다. `REINDEX`는 데드 페이지 또는 비어 있거나 거의 비어 있는 페이지 없이 인덱스의 새 버전을 작성하여 인덱스의 공간 소비를 줄입니다. [https://www.postgresql.org/docs/current/sql-reindex.html](https://www.postgresql.org/docs/current/sql-reindex.html) 명령에 대한 자세한 내용은 REINDEX 설명서를 참조하세요.

테이블 및 인덱스에서 팽창을 제거한 후 해당 테이블의 autovacuum 빈도를 늘려야 할 수 있습니다. 테이블 수준에서 적극적인 autovacuum 설정을 구현하면 향후 팽창이 발생하지 않도록 방지할 수 있습니다. 자세한 내용은 [https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html)의 설명서를 참조하세요.