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

LWLock:MultiXact

LWLock:MultiXactMemberBuffer, LWLock:MultiXactOffsetBuffer, LWLock:MultiXactMemberSLRU 및 LWLock:MultiXactOffsetSLRU 대기 이벤트는 세션이 지정된 테이블에 있는 동일한 행을 수정하는 트랜잭션 목록을 검색하기 위해 대기 중임을 나타냅니다.

  • LWLock:MultiXactMemberBuffer – 프로세스가 multixact 멤버를 위해 가장 오래전에 사용된 단순(SLRU) 버퍼에서 I/O를 기다리고 있습니다.

  • LWLock:MultiXactMemberSLRU – 프로세스가 multixact 멤버를 위해 가장 오래전에 사용된 단순(SLRU) 캐시에 액세스하기 위해 대기 중입니다.

  • LWLock:MultiXactOffsetBuffer – 프로세스가 multixact 오프셋을 위해 가장 오래전에 사용된 단순(SLRU) 버퍼에서 I/O를 기다리고 있습니다.

  • LWLock:MultiXactOffsetSLRU – 프로세스가 multixact 오프셋을 위해 가장 오래전에 사용된 단순(SLRU) 캐시에 액세스하기 위해 대기 중입니다.

지원되는 엔진 버전

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

컨텍스트

multixact는 동일한 테이블 행을 수정하는 트랜잭션 ID(XID) 목록을 저장하는 데이터 구조입니다. 단일 트랜잭션이 특정 테이블의 행을 참조하는 경우 트랜잭션 ID가 해당 테이블의 헤더 행에 저장됩니다. 여러 트랜잭션이 특정 테이블의 동일한 행을 참조하는 경우 트랜잭션 ID 목록이 multixact 데이터 구조에 저장됩니다. multixact 대기 이벤트는 세션이 데이터 구조에서 테이블의 지정된 행을 참조하는 트랜잭션 목록을 검색하고 있음을 나타냅니다.

대기 증가의 가능한 원인

multixact를 사용하는 세 가지 일반적인 원인은 다음과 같습니다.

  • 명시적 세이브 포인트의 하위 트랜잭션 – 트랜잭션에서 명시적으로 저장점을 생성하면 동일한 행에 대한 새 트랜잭션이 생성됩니다. 예를 들자면 SELECT FOR UPDATE를 사용한 다음 SAVEPOINT와 UPDATE를 차례대로 사용하는 식입니다.

    일부 드라이버, ORM(객체 관계 매퍼) 및 추상화 계층에는 모든 작업을 저장점으로 자동 래핑하는 구성 옵션이 있습니다. 이 옵션 때문에 일부 워크로드에서 multixact 대기 이벤트가 많이 생성될 수 있습니다. PostgreSQL JDBC 드라이버의 autosave 옵션이 대표적인 예입니다. 자세한 내용은 PostgreSQL JDBC 설명서의 pgJDBC를 참조하세요. 또 다른 예는 PostgreSQL ODBC 드라이버와 이 드라이버의 protocol 옵션입니다. 자세한 내용은 PostgreSQL ODBC 드라이버 설명서의 psqlODBC 구성 옵션을 참조하세요.

  • PL/pgSQL EXCEPTION 조항의 하위 트랜잭션 - PL/pgSQL 함수 또는 프로시저에서 작성한 각 EXCEPTION 절은 SAVEPOINT를 내부에서 생성합니다.

  • 외래 키 - 여러 트랜잭션이 상위 행에 대한 공유 잠금을 획득합니다.

지정된 행이 다중 트랜잭션 작업에 포함된 경우, 행을 처리하려면 multixact 목록에서 트랜잭션 ID를 검색해야 합니다. 조회 시 메모리 캐시에서 multixact를 가져올 수 없는 경우, Aurora 스토리지 계층에서 데이터 구조를 읽어야 합니다. 스토리지의 이 I/O에서는 SQL 쿼리가 더 오래 걸릴 수 있습니다. 다중 트랜잭션이 너무 많아 사용량이 많아지만 메모리 캐시 누락이 발생할 수 있습니다. 이러한 모든 요인은 이 대기 이벤트의 증가를 유발합니다.

작업

대기 이벤트의 원인에 따라 다른 작업을 권장합니다. 이러한 작업 중 일부는 대기 이벤트를 즉시 줄이는 데 도움이 될 수 있습니다. 하지만 워크로드의 규모를 조정하기 위해 조사 및 수정이 필요한 경우도 있습니다.

이 대기 이벤트가 발생한 테이블에서 vacuum freeze 수행

이 대기 이벤트가 급증하여 프로덕션 환경에 영향을 미치는 경우, 다음과 같은 임시 방법 중 하나를 사용하여 이벤트 수를 줄일 수 있습니다.

  • 영향을 받는 테이블 또는 테이블 파티션에서 VACUUM FREEZE를 사용하여 문제를 즉시 해결합니다. 자세한 내용은 VACUUM을 참조하세요.

  • VACUUM(FREEZE, INDEX_CLEANUP FALSE) 절을 사용하여 인덱스를 건너뛰고 빠르게 vacuum을 수행합니다. 자세한 내용은 테이블에 최대한 신속하게 vacuum 실행을 참조하세요.

이 대기 이벤트가 있는 테이블의 autovacuum 빈도 상향

모든 데이터베이스의 모든 테이블을 스캔한 후 VACUUM은 multixact를 제거하며, 가장 오래된 multixact 값이 승격됩니다. 자세한 내용은 Multixacts 및 랩어라운드를 참조하세요. LWLock:MultiXact 대기 이벤트를 최소화하려면 VACUUM을 필요한 만큼 자주 실행해야 합니다. 이렇게 하려면 Aurora PostgreSQL DB 클러스터의 VACUUM이 최적으로 구성되어 있어야 합니다.

영향을 받는 테이블 또는 테이블 파티션에서 VACUUM FREEZE를 사용하여 대기 이벤트 문제가 해결되면 인스턴스 수준에서 autovacuum을 조정하는 대신 VACUUM을 수행할 수 있도록 pg_cron 등의 스케줄러를 사용하는 것이 좋습니다.

autovacuum이 더 자주 실행되도록 하려면 영향을 받는 테이블의 스토리지 파라미터 autovacuum_multixact_freeze_max_age의 값을 줄일 수 있습니다. 자세한 내용은 autovacuum_multixact_freeze_max_age를 참조하세요.

메모리 파라미터 상향

다음 파라미터를 조정하여 multixact 캐시의 메모리 사용량을 최적화할 수 있습니다. 이러한 설정은 이러한 캐시에 예약되는 메모리의 양을 제어하므로 워크로드의 multixact 대기 이벤트를 줄이는 데 도움이 될 수 있습니다. 다음 값으로 시작하는 것이 좋습니다.

Aurora PostgreSQL 17 이상의 경우:

  • multixact_offset_buffers = 128

  • multixact_member_buffers = 256

Aurora PostgreSQL 16 이하의 경우:

  • multixact_offsets_cache_size = 128

  • multixact_members_cache_size = 256

참고

Aurora PostgreSQL 17에서는 커뮤니티 PostgreSQL 17에 맞게 파라미터 이름이 multixact_offsets_cache_size에서 multixact_offset_buffers로, multixact_members_cache_size에서 multixact_member_buffers로 변경되었습니다.

클러스터의 모든 인스턴스가 일관되게 유지되도록 클러스터 수준에서 이러한 파라미터를 설정할 수 있습니다. 특정 워크로드 요구 사항 및 인스턴스 클래스에 가장 적합하도록 값을 테스트하고 조정하는 것이 좋습니다. 파라미터 변경 사항을 적용하려면 인스턴스를 재부팅해야 합니다.

파라미터는 multixact 캐시 항목으로 표시됩니다. 각 캐시 항목은 8 KB의 메모리를 사용합니다. 예약된 총 메모리를 계산하려면 각 파라미터 값에 8 KB를 곱합니다. 예를 들어 파라미터를 128로 설정하면 총 예약 메모리는 128 * 8 KB = 1 MB입니다.

장기 실행 트랜잭션 저감

장기 실행 트랜잭션은 트랜잭션이 커밋되거나 읽기 전용 트랜잭션이 종료될 때까지 vacuum이 트랜잭션 정보를 유지합니다. 장기 실행 트랜잭션을 사전에 모니터링하고 관리하는 것이 좋습니다. 자세한 내용은 데이터베이스가 트랜잭션 연결 시 오랫동안 유휴 상태로 실행됨 섹션을 참조하세요. 장기 실행 트랜잭션의 사용을 방지하거나 최소화하도록 애플리케이션을 수정해 보세요.

장기적인 조치

워크로드를 검사하여 multixact 스필오버의 원인을 찾아내세요. 워크로드의 규모를 조정하고 대기 이벤트를 줄이려면 문제를 해결해야 합니다.

  • 테이블을 만드는 데 사용한 DDL(데이터 정의 언어)을 분석해야 합니다. 테이블 구조와 인덱스가 제대로 설계되었는지 확인하세요.

  • 영향을 받는 테이블에 외래 키가 있는 경우, 외래 키가 필요한지 또는 참조 무결성을 적용할 다른 방법이 있는지 파악하세요.

  • 테이블에 사용되지 않은 대용량 인덱스가 있으면 autovacuum이 워크로드에 맞지 않아 실행이 차단될 수 있습니다. 이를 방지하려면 사용되지 않은 인덱스가 있는지 확인하고, 있는 경우 이를 완전히 제거하세요. 자세한 내용은 대용량 인덱스가 있는 autovacuum 관리를 참조하세요.

  • 트랜잭션에서 세이브 포인트 사용을 줄이세요.