# LWLock:lock\$1manager
이 이벤트는 Aurora PostgreSQL 엔진이 빠른 경로 잠금이 불가능할 때 잠금을 할당, 확인 및 할당 해제하기 위해 공유 잠금 메모리 영역을 유지 관리하는 경우에 발생합니다.
**Topics**
+ [지원되는 엔진 버전](#apg-waits.lw-lock-manager.context.supported)
+ [컨텍스트](#apg-waits.lw-lock-manager.context)
+ [대기 증가의 가능한 원인](#apg-waits.lw-lock-manager.causes)
+ [작업](#apg-waits.lw-lock-manager.actions)
## 지원되는 엔진 버전
이 대기 이벤트 정보는 Aurora PostgreSQL 버전 9.6 이상에서 지원됩니다.
## 컨텍스트
SQL 문을 실행하면 Aurora PostgreSQL 동시 작업 중에 데이터베이스의 구조, 데이터 및 무결성을 보호하기 위해 잠금을 기록합니다. 엔진은 빠른 경로 잠금 또는 빠르지 않은 경로 잠금을 사용하여 이 목표를 달성할 수 있습니다. 빠르지 않은 경로 잠금은 빠른 경로 잠금보다 비용이 많이 들고 오버헤드가 더 많이 발생합니다.
### 빠른 경로 잠금
자주 수행되고 해제되지만 충돌이 거의 발생하지 않는 잠금의 오버헤드를 줄이기 위해 백엔드 프로세스에서 빠른 경로 잠금을 사용할 수 있습니다. 데이터베이스는 다음 기준을 충족하는 잠금에 대해 이 메커니즘을 사용합니다.
+ DEFAULT 잠금 방법을 사용합니다.
+ 공유 관계가 아닌 데이터베이스 관계에 대한 잠금을 나타냅니다.
+ 그들은 충돌할 가능성이 없는 약한 잠금입니다.
+ 엔진은 충돌하는 잠금이 존재하지 않을 수 있는지 신속하게 확인할 수 있습니다.
다음 조건 중 하나에 부합할 때 엔진은 빠른 경로 잠금을 사용할 수 없습니다.
+ 이 잠금이 이전 기준을 충족하지 않습니다.
+ 백엔드 프로세스에 사용할 수 있는 슬롯이 더 이상 없습니다.
고속 경로 잠금에 대한 자세한 내용은 잠금 관리자 README의 [빠른 경로](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76)와 PostgreSQL 설명서의 [pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html)를 참조하세요.
### 잠금 관리자의 배율 조정 문제 예
이 예에서는 이름이 `purchases`인 테이블이 매일로 분할된 5년짜리 데이터를 저장합니다. 각 파티션에는 두 개의 인덱스가 있습니다. 다음과 같은 일련의 이벤트가 발생합니다.
1. 며칠 분량의 데이터를 쿼리하면 데이터베이스가 많은 파티션을 읽어야 합니다.
1. 데이터베이스는 각 파티션에 대한 잠금 항목을 만듭니다. 파티션 인덱스가 최적기 액세스 경로의 일부인 경우 데이터베이스도 해당 인덱스에 대한 잠금 항목을 만듭니다.
1. 동일한 백엔드 프로세스에 대해 요청된 잠금 항목 수가 `FP_LOCK_SLOTS_PER_BACKEND`의 값인 16보다 높은 경우 잠금 관리자는 비고속 경로 잠금 방법을 사용합니다.
최신 애플리케이션에는 수백 개의 세션이 있을 수 있습니다. 동시 세션이 적절한 파티션 정리 없이 부모를 쿼리하는 경우 데이터베이스는 수백 또는 수천 개의 고속 경로 잠금을 생성할 수 있습니다. 일반적으로 이 동시성이 vCPU 수보다 높으면 `LWLock:lock_manager` 대기 이벤트가 표시됩니다.
**참고**
`LWLock:lock_manager` 대기 이벤트는 데이터베이스 스키마의 파티션 또는 인덱스 수와 관련이 없습니다. 대신 데이터베이스가 제어해야 하는 비고속 경로 잠금 수와 관련이 있습니다.
## 대기 증가의 가능한 원인
`LWLock:lock_manager` 대기 이벤트가 정상보다 더 발생하여 성능 문제를 나타낼 수 있으며 갑작스런 스파이크의 가장 큰 원인은 다음과 같습니다.
+ 동시 활성 세션은 빠른 경로 잠금을 사용하지 않는 쿼리를 실행하고 있습니다. 이러한 세션도 최대 vCPU를 초과합니다.
+ 많은 수의 동시 활성 세션이 심하게 분할된 테이블에 액세스하고 있습니다. 각 파티션에는 여러 개의 인덱스가 있습니다.
+ 데이터베이스에 연결 폭풍이 발생합니다. 기본적으로 일부 애플리케이션 및 연결 풀 소프트웨어는 데이터베이스 속도가 느릴 때 더 많은 연결을 만듭니다. 이 관행은 문제를 악화시킵니다. 연결 스톰이 발생하지 않도록 연결 풀 소프트웨어를 튜닝합니다.
+ 많은 수의 세션이 파티션을 정리하지 않고 상위 테이블을 쿼리합니다.
+ 데이터 정의 언어 (DDL), 유지 관리 명령은 자주 액세스하거나 수정되는 사용 중인 관계식 또는 튜플을 독점적으로 잠급니다.
## 작업
대기 이벤트의 원인에 따라 다른 작업을 권장합니다.
**Topics**
+ [파티션 정리 사용](#apg-waits.lw-lock-manager.actions.pruning)
+ [불필요한 인덱스 삭제](#apg-waits.lw-lock-manager.actions.indexes)
+ [빠른 경로 잠금을 위한 쿼리 조정](#apg-waits.lw-lock-manager.actions.tuning)
+ [다른 대기 이벤트 조정](#apg-waits.lw-lock-manager.actions.other-waits)
+ [하드웨어 병목 현상 저감](#apg-waits.lw-lock-manager.actions.hw-bottlenecks)
+ [연결 풀러 사용](#apg-waits.lw-lock-manager.actions.pooler)
+ [Aurora PostgreSQL 버전 업그레이드](#apg-waits.lw-lock-manager.actions.pg-version)
### 파티션 정리 사용
*파티션 정리*는 테이블 검색에서 불필요한 파티션을 제외하여 성능을 향상시키는 쿼리 최적화 전략입니다. 파티션 정리는 기본적으로 활성화되어 있습니다. 꺼져 있으면 다음과 같이 켭니다.
```
SET enable_partition_pruning = on;
```
`WHERE` 절에 파티셔닝에 사용되는 열이 들어 있으면 쿼리는 파티션 정리를 활용할 수 있습니다. 더 자세한 내용은 PostgreSQL 설명서의 [파티션 정리](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING)를 참조하세요.
### 불필요한 인덱스 삭제
데이터베이스에 사용되지 않거나 거의 사용되지 않는 인덱스가 포함되어 있을 수 있습니다. 이 경우 삭제하는 것이 좋습니다. 다음 중 하나를 수행하세요.
+ 불필요한 인덱스를 찾아내려면, PostgreSQL 위키의 [사용되지 않는 인덱스](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes)를 읽어보세요.
+ PG 컬렉터를 실행합니다. 이 SQL 스크립트는 데이터베이스 정보를 수집하여 통합 HTML 보고서로 표시합니다. '사용되지 않은 인덱스' 섹션을 확인하세요. 자세한 내용은 AWS Labs GitHub 리포지토리의 [pg-collector](https://github.com/awslabs/pg-collector)를 참조하세요.
### 빠른 경로 잠금을 위한 쿼리 조정
쿼리에서 빠른 경로 잠금을 사용하는지 확인하려면 `pg_locks` 테이블의 `fastpath` 열을 쿼리하세요. 쿼리에서 빠른 경로 잠금을 사용하지 않는 경우 쿼리당 관계 수를 16 미만으로 줄이세요.
### 다른 대기 이벤트 조정
`LWLock:lock_manager`가 최상위 대기 목록에서 첫 번째 또는 두 번째일 경우, 다음 대기 이벤트도 목록에 나타나는지 확인합니다.
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
위의 이벤트가 목록에서 높게 표시되는 경우 이러한 대기 이벤트를 먼저 조정하는 것이 좋습니다. 이러한 이벤트는 `LWLock:lock_manager` 드라이버가 될 수 있습니다.
### 하드웨어 병목 현상 저감
CPU 부족 또는 Amazon EBS 대역폭의 최대 사용량과 같은 하드웨어 병목 현상이 발생할 수 있습니다. 이 경우에는 하드웨어 병목 현상을 줄이는 것이 좋습니다. 다음 조치를 고려해 보세요.
+ 인스턴스 클래스를 확장하세요.
+ 대량의 CPU와 메모리를 사용하는 쿼리를 최적화하세요.
+ 애플리케이션 로직을 변경하세요.
+ 데이터를 아카이빙하세요.
CPU, 메모리 및 EBS 네트워크 대역폭에 대한 자세한 내용은 [Amazon RDS 인스턴스 유형](https://aws.amazon.com/rds/instance-types/)을 참조하세요.
### 연결 풀러 사용
총 활성 연결 수가 최대 vCPU를 초과하는 경우 인스턴스 유형이 지원할 수 있는 것보다 많은 OS 프로세스에 CPU가 필요합니다. 이 경우에는 연결 풀을 사용하거나 튜닝하는 것이 좋습니다. 인스턴스 유형별 vCPU 수에 대한 자세한 내용은 [Amazon RDS 인스턴스 유형](https://aws.amazon.com/rds/instance-types/)을 참조하세요.
연결 풀링에 대한 자세한 내용은 다음 리소스를 참조하세요.
+ [Aurora용 Amazon RDS Proxy](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ *PostgreSQL 설명서*의 [연결 풀 및 데이터 원본](https://www.postgresql.org/docs/7.4/jdbc-datasource.html)
### Aurora PostgreSQL 버전 업그레이드
현재 버전의 Aurora PostgreSQL이 12보다 낮은 경우 버전 12 이상으로 업그레이드하세요. PostgreSQL 버전 12 및 13에는 향상된 파티션 메커니즘이 있습니다. 버전 12의 더 자세한 정보는 [PostgreSQL 릴리스 12.0]( https://www.postgresql.org/docs/release/12.0/)을 참조하세요. Aurora PostgreSQL 업그레이드에 대한 자세한 내용은 [Amazon Aurora PostgreSQL에 대한 데이터베이스 엔진 업데이트](AuroraPostgreSQL.Updates.md) 섹션을 참조하세요.