LWLock:lock_manager - Amazon Aurora
지원되는 엔진 버전컨텍스트대기 증가의 가능한 원인작업

LWLock:lock_manager

이 이벤트는 Aurora PostgreSQL 엔진이 빠른 경로 잠금이 불가능할 때 잠금을 할당, 확인 및 할당 해제하기 위해 공유 잠금 메모리 영역을 유지 관리하는 경우에 발생합니다.

지원되는 엔진 버전

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

컨텍스트

SQL 문을 실행하면 Aurora PostgreSQL 동시 작업 중에 데이터베이스의 구조, 데이터 및 무결성을 보호하기 위해 잠금을 기록합니다. 엔진은 빠른 경로 잠금 또는 빠르지 않은 경로 잠금을 사용하여 이 목표를 달성할 수 있습니다. 빠르지 않은 경로 잠금은 빠른 경로 잠금보다 비용이 많이 들고 오버헤드가 더 많이 발생합니다.

빠른 경로 잠금

자주 수행되고 해제되지만 충돌이 거의 발생하지 않는 잠금의 오버헤드를 줄이기 위해 백엔드 프로세스에서 빠른 경로 잠금을 사용할 수 있습니다. 데이터베이스는 다음 기준을 충족하는 잠금에 대해 이 메커니즘을 사용합니다.

  • DEFAULT 잠금 방법을 사용합니다.

  • 공유 관계가 아닌 데이터베이스 관계에 대한 잠금을 나타냅니다.

  • 그들은 충돌할 가능성이 없는 약한 잠금입니다.

  • 엔진은 충돌하는 잠금이 존재하지 않을 수 있는지 신속하게 확인할 수 있습니다.

다음 조건 중 하나에 부합할 때 엔진은 빠른 경로 잠금을 사용할 수 없습니다.

  • 이 잠금이 이전 기준을 충족하지 않습니다.

  • 백엔드 프로세스에 사용할 수 있는 슬롯이 더 이상 없습니다.

고속 경로 잠금에 대한 자세한 내용은 잠금 관리자 README의 빠른 경로와 PostgreSQL 설명서의 pg-locks를 참조하세요.

잠금 관리자의 배율 조정 문제 예

이 예에서는 이름이 purchases인 테이블이 매일로 분할된 5년짜리 데이터를 저장합니다. 각 파티션에는 두 개의 인덱스가 있습니다. 다음과 같은 일련의 이벤트가 발생합니다.

  1. 며칠 분량의 데이터를 쿼리하면 데이터베이스가 많은 파티션을 읽어야 합니다.

  2. 데이터베이스는 각 파티션에 대한 잠금 항목을 만듭니다. 파티션 인덱스가 최적기 액세스 경로의 일부인 경우 데이터베이스도 해당 인덱스에 대한 잠금 항목을 만듭니다.

  3. 동일한 백엔드 프로세스에 대해 요청된 잠금 항목 수가 FP_LOCK_SLOTS_PER_BACKEND의 값인 16보다 높은 경우 잠금 관리자는 비고속 경로 잠금 방법을 사용합니다.

최신 애플리케이션에는 수백 개의 세션이 있을 수 있습니다. 동시 세션이 적절한 파티션 정리 없이 부모를 쿼리하는 경우 데이터베이스는 수백 또는 수천 개의 고속 경로 잠금을 생성할 수 있습니다. 일반적으로 이 동시성이 vCPU 수보다 높으면 LWLock:lock_manager 대기 이벤트가 표시됩니다.

참고

LWLock:lock_manager 대기 이벤트는 데이터베이스 스키마의 파티션 또는 인덱스 수와 관련이 없습니다. 대신 데이터베이스가 제어해야 하는 비고속 경로 잠금 수와 관련이 있습니다.

대기 증가의 가능한 원인

LWLock:lock_manager 대기 이벤트가 정상보다 더 발생하여 성능 문제를 나타낼 수 있으며 갑작스런 스파이크의 가장 큰 원인은 다음과 같습니다.

  • 동시 활성 세션은 빠른 경로 잠금을 사용하지 않는 쿼리를 실행하고 있습니다. 이러한 세션도 최대 vCPU를 초과합니다.

  • 많은 수의 동시 활성 세션이 심하게 분할된 테이블에 액세스하고 있습니다. 각 파티션에는 여러 개의 인덱스가 있습니다.

  • 데이터베이스에 연결 폭풍이 발생합니다. 기본적으로 일부 애플리케이션 및 연결 풀 소프트웨어는 데이터베이스 속도가 느릴 때 더 많은 연결을 만듭니다. 이 관행은 문제를 악화시킵니다. 연결 스톰이 발생하지 않도록 연결 풀 소프트웨어를 튜닝합니다.

  • 많은 수의 세션이 파티션을 정리하지 않고 상위 테이블을 쿼리합니다.

  • 데이터 정의 언어 (DDL), 유지 관리 명령은 자주 액세스하거나 수정되는 사용 중인 관계식 또는 튜플을 독점적으로 잠급니다.

작업

대기 이벤트의 원인에 따라 다른 작업을 권장합니다.

파티션 정리 사용

파티션 정리는 테이블 검색에서 불필요한 파티션을 제외하여 성능을 향상시키는 쿼리 최적화 전략입니다. 파티션 정리는 기본적으로 활성화되어 있습니다. 꺼져 있으면 다음과 같이 켭니다.

SET enable_partition_pruning = on;

WHERE 절에 파티셔닝에 사용되는 열이 들어 있으면 쿼리는 파티션 정리를 활용할 수 있습니다. 더 자세한 내용은 PostgreSQL 설명서의 파티션 정리를 참조하세요.

불필요한 인덱스 삭제

데이터베이스에 사용되지 않거나 거의 사용되지 않는 인덱스가 포함되어 있을 수 있습니다. 이 경우 삭제하는 것이 좋습니다. 다음 중 하나를 수행하세요.

  • 불필요한 인덱스를 찾아내려면, PostgreSQL 위키의 사용되지 않는 인덱스를 읽어보세요.

  • PG 컬렉터를 실행합니다. 이 SQL 스크립트는 데이터베이스 정보를 수집하여 통합 HTML 보고서로 표시합니다. '사용되지 않은 인덱스' 섹션을 확인하세요. 자세한 내용은 AWS Labs GitHub 리포지토리의 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 인스턴스 유형을 참조하세요.

연결 풀러 사용

총 활성 연결 수가 최대 vCPU를 초과하는 경우 인스턴스 유형이 지원할 수 있는 것보다 많은 OS 프로세스에 CPU가 필요합니다. 이 경우에는 연결 풀을 사용하거나 튜닝하는 것이 좋습니다. 인스턴스 유형별 vCPU 수에 대한 자세한 내용은 Amazon RDS 인스턴스 유형을 참조하세요.

연결 풀링에 대한 자세한 내용은 다음 리소스를 참조하세요.

Aurora PostgreSQL 버전 업그레이드

현재 버전의 Aurora PostgreSQL이 12보다 낮은 경우 버전 12 이상으로 업그레이드하세요. PostgreSQL 버전 12 및 13에는 향상된 파티션 메커니즘이 있습니다. 버전 12의 더 자세한 정보는 PostgreSQL 릴리스 12.0을 참조하세요. Aurora PostgreSQL 업그레이드에 대한 자세한 내용은 Amazon Aurora PostgreSQL 업데이트 섹션을 참조하세요.