Lock:transactionid - Amazon Aurora

Lock:transactionid

Lock:transactionid 이벤트는 트랜잭션이 행 수준 잠금을 대기 중일 때 발생합니다.

지원되는 엔진 버전

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

컨텍스트

이벤트 Lock:transactionid 트랜잭션이 동시에 실행 중인 트랜잭션에 이미 부여된 행 수준 잠금을 획득하려고 할 때 발생합니다. Lock:transactionid 대기 이벤트를 보여주는 세션이 이 잠금으로 인해 차단되었습니다. 차단 트랜잭션이 종료된 후 COMMIT 또는ROLLBACK 문, 차단된 트랜잭션을 진행할 수 있습니다.

Aurora PostgreSQL의 다중 버전 동시성 제어 의미는 리더가 라이터를 차단하지 않으며 라이터는 리더를 차단하지 않는다는 것을 보장합니다. 행 수준 충돌이 발생하려면 차단 및 차단된 트랜잭션이 다음 유형의 충돌하는 명령문을 실행해야 합니다.

  • UPDATE

  • SELECT … FOR UPDATE

  • SELECT … FOR KEY SHARE

명령문 SELECT … FOR KEY SHARE는 특별한 경우입니다. 데이터베이스가 FOR KEY SHARE 절을 사용해 참조 무결성의 성능을 최적화합니다. 행의 행 수준 잠금은 행을 참조하는 다른 테이블에서 INSERT, UPDATE, DELETE 명령을 차단할 수 있습니다.

대기 증가의 가능한 원인

이 이벤트가 정상보다 많이 나타나는 경우 일반적으로 원인은 다음 조건과 결합된 UPDATE, SELECT … FOR UPDATE, 또는 SELECT … FOR KEY SHARE 문입니다.

높은 동시성

Aurora PostgreSQL 세분화된 행 수준 잠금 의미를 사용할 수 있습니다. 다음 조건이 충족되면 행 수준 충돌 확률이 높아집니다.

  • 동일한 행에 대해 높은 동시 워크로드가 경합됩니다.

  • 동시성이 증가합니다.

트랜잭션의 유휴 상태

가끔 pg_stat_activity.state 열에 idle in transaction 값이 표시됩니다. 이 값은 트랜잭션을 시작했지만 아직 COMMIT 또는 ROLLBACK을 실행하지 않은 세션에 대해 표시됩니다. 만약 pg_stat_activity.state 값이 active가 아니라면, pg_stat_activity에 표시된 쿼리는 실행을 마친 가장 최근의 쿼리입니다. 차단 세션은 열려 있는 트랜잭션이 잠금을 유지하고 있기 때문에 쿼리를 능동적으로 처리하지 않습니다.

유휴 트랜잭션이 행 수준 잠금을 획득한 경우 다른 세션에서 잠금을 획득하지 못할 수 있습니다. 이 조건으로 인해 Lock:transactionid 대기 이벤트가 자주 발생합니다. 문제를 진단하려면 pg_stat_activitypg_locks의 출력을 검사하세요.

장기 실행 트랜잭션

오랫동안 실행되는 트랜잭션은 오랜 시간 동안 잠금을 얻습니다. 이러한 장기 잠금은 다른 트랜잭션의 실행을 차단할 수 있습니다.

작업

행 잠금은 UPDATE, SELECT … FOR UPDATE, 또는 SELECT … FOR KEY SHARE 문 사이의 충돌입니다. 솔루션을 시도하기 전에 이러한 명령문이 동일한 행에서 실행되는 시점을 확인하세요. 다음 섹션에 설명된 전략을 선택하려면 이 정보를 사용하세요.

동시성에 대응

동시성이 문제가 되는 경우 다음 기술 중 하나를 시도해 보세요.

  • 애플리케이션의 동시성을 낮춥니다. 예를 들어 활성 세션 수를 줄일 수 있습니다.

  • 연결 풀을 구현합니다. RDS 프록시로 연결을 풀링하는 방법에 대한 자세한 내용은 Aurora용 Amazon RDS 프록시 사용 섹션을 참조하세요.

  • UPDATE 문과 SELECT … FOR UPDATE 문의 경쟁 방지를 위한 애플리케이션 또는 데이터 모델을 설계하세요. SELECT … FOR KEY SHARE 문으로 액세스하는 외래 키 수를 줄일 수도 있습니다.

유휴 트랜잭션에 대응

pg_stat_activity.stateidle in transaction을 나타낸다면, 다음 전략을 시도해 보세요.

  • 가능하면 자동 커밋을 켭니다. 이 접근 방식은 트랜잭션이 COMMIT이나 ROLLBACK을 대기하는 동안 다른 트랜잭션을 차단하는 것을 방지합니다.

  • COMMIT, ROLLBACK, 또는 END가 누락된 코드 경로 검색

  • 애플리케이션의 예외 처리 논리에 항상 유효한 end of transaction으로 향하는 경로가 있는지 확인하세요.

  • COMMITROLLBACK과의 트랜잭션을 종료한 후 애플리케이션이 쿼리 결과를 처리하는지 확인하세요.

장기 실행 트랜잭션에 대응

장기 실행 트랜잭션으로 인해 Lock:transactionid가 자주 발생하는 경우 다음 전략을 시도해 보세요.

  • 장기 실행 트랜잭션에서 행 잠금을 차단합니다.

  • 가능하면 자동 커밋을 구현하여 쿼리 길이를 제한합니다.