Amazon Redshift 유지 관리 후 쿼리가 더 오래 실행되는 이유는 무엇입니까?

간략한 설명

버전 업그레이드 중에 Amazon Redshift는 쿼리 캐시와 컴파일 캐시를 지웁니다. 업그레이드 후 처음으로 쿼리를 실행하면 컴파일 시간이 오래 걸립니다. 하지만 Amazon Redshift가 캐시를 다시 빌드하면서 성능이 점차 개선됩니다.

Amazon Redshift는 모든 유지 관리 기간 작업의 클러스터 버전을 변경하지 않습니다. 버전 변경을 확인하려면 SYS_QUERY_HISTORY 테이블의 redshift_version 열을 확인합니다.

Amazon Redshift의 캐시 유형에 대한 자세한 내용은 결과 캐싱 및 컴파일된 코드를 참조하십시오. 쿼리 성능에 대한 자세한 내용은 쿼리 성능에 영향을 미치는 요인을 참조하십시오.

해결 방법

유지 관리 전후의 쿼리 성능 분석

유지 관리 전후에 실행한 쿼리를 파악합니다. 쿼리 모니터링 콘솔 또는 SYS_QUERY_HISTORY 시스템 보기를 사용할 수 있습니다.

마지막 20개의 사용자 쿼리를 찾으려면 다음 쿼리를 실행합니다.

SELECT * FROM sys_query_history
WHERE user_id>1
ORDER BY start_time desc
limit 20;

출력에서 user_query_hash 열을 사용하여 동일한 쿼리 텍스트와 쿼리를 비교합니다. 또는 generic_query_hash를 사용하여 쿼리 텍스트는 비슷하지만 쿼리 리터럴이 다른 쿼리를 비교합니다.

지난 7일 동안 특정 쿼리를 실행한 각 시간을 보려면 다음 쿼리를 실행합니다.

SELECT * FROM sys_query_history
WHERE user_query_hash = 'ExampleText'
ORDER BY start_time desc;

참고: ExampleText를 쿼리 해시 값으로 바꿉니다.

출력에서 여러 실행의 compile_time 값을 비교합니다. 유지 관리 직후에 실행한 쿼리의 컴파일 시간은 더 길어질 수 있습니다.

컴파일 시간을 줄이려면 유지 관리 후에 주요 쿼리를 실행하도록 예약하거나 사용량이 많지 않은 시간에 중요한 쿼리를 워밍업하십시오.

참고: 쿼리 실행 엔진은 Java 데이터베이스 연결(JDBC) 및 Microsoft Open Database Connectivity(ODBC) 연결 프로토콜에 대해 서로 다른 코드를 컴파일합니다. 서로 다른 프로토콜을 사용하는 두 개의 클라이언트가 있는 경우 각 클라이언트마다 코드를 컴파일하기 위한 최초 비용이 발생합니다. 하지만 동일한 프로토콜을 사용하는 클라이언트는 캐시된 코드를 공유합니다. JDBC를 사용하여 클러스터에 연결하고 쿼리를 실행하면 Amazon Redshift가 JDBC 연결에 대해서만 캐시를 저장합니다. ODBC를 사용하는 클라이언트에서 동일한 쿼리를 실행하는 경우 Amazon Redshift는 ODBC 연결을 위한 또 다른 캐시를 생성합니다.

문제 해결

쿼리 컴파일이 유지 관리 전후에 거의 차이를 보이지 않는 경우 때때로 관련 없는 성능 문제가 발생할 수 있습니다. 쿼리 및 데이터베이스 모니터링 콘솔을 사용하여 지표에서 비정상적인 급증을 모니터링합니다. 컴파일 시간을 비교하여 문제의 원인을 파악합니다.

급증은 발견하지 못했지만 여전히 문제가 발생하는 경우 지원 사례를 생성합니다.

관련 정보

SVL_COMPILE