Amazon Redshift에서 쿼리 계획 시간이 실제 실행 시간보다 훨씬 깁니다. 왜 이런 현상이 발생합니까?
간략한 설명
프로덕션 로드에 대한 배타적 잠금을 포함하는 쿼리가 있는 경우 잠금 대기 시간이 증가할 수 있습니다. 이로 인해 Amazon Redshift의 쿼리 계획 시간이 실제 실행 시간보다 훨씬 길어집니다. [워크로드 실행 분석] 지표를 확인하여 쿼리 계획 시간이 갑자기 증가하는지 확인합니다. 이 시간 증가는 잠금을 대기 중인 트랜잭션으로 인해 발생할 수 있습니다.
해결 방법
잠금을 대기 중인 트랜잭션을 감지하려면 다음 단계를 수행합니다.
1. 첫 번째 잠금을 위한 새 세션을 엽니다.
begin; lock table1;
2. 병렬로 실행되는 두 번째 세션을 엽니다.
select * from table1 limit 1000;
이 두 번째 세션의 쿼리는 AccessSharedLock 요청을 제출합니다. 하지만 첫 번째 세션에서 이미 요청했기 때문에 쿼리는 AccessExclusiveLock을 기다려야 합니다. 그러면 ExclusiveLock이 table1에서 다른 모든 작업을 차단합니다.
3. [워크로드 실행 분석] 지표를 확인합니다. 쿼리 계획 시간이 갑자기 급증하면 잠금 대기 중인 트랜잭션이 있음을 의미합니다.
4. (선택 사항) 잠금을 대기 중인 트랜잭션이 존재하는 경우, 세션을 수동으로 종료하여 잠금을 해제합니다.
select pg_terminate_backend(PID);
잠금 해제에 대한 자세한 내용은 Amazon Redshift에서 잠금을 감지하고 해제하려면 어떻게 해야 합니까?를 참조하십시오.
관련 정보
워크로드 성능 분석
쿼리 계획 및 실행 워크플로우