데이터베이스 부하 - Amazon Relational Database Service
활성 세션평균 활성 세션평균 활성 실행측정기준

데이터베이스 부하

데이터베이스 로드(DB 로드)는 데이터베이스의 세션 활동 수준을 측정합니다. 성능 개선 도우미의 핵심 지표는 DBLoad이며, 1초 간격으로 수집됩니다.

활성 세션

데이터베이스 세션은 관계형 데이터베이스와 애플리케이션의 대화를 나타냅니다. 활성 세션이란 DB 엔진에 작업을 제출하여 현재 응답 대기 중인 연결 세션을 말합니다.

세션은 CPU에서 실행 중이거나 리소스가 계속 진행될 수 있도록 대기 중일 때 활성화됩니다. 예를 들어 활성 세션은 페이지(또는 블록)가 메모리로 읽힐 때까지 기다린 다음 페이지에서 데이터를 읽는 동안 CPU를 사용할 수 있습니다.

평균 활성 세션

평균 활성 세션(AAS)은 성능 개선 도우미의 DBLoad 지표에 대한 단위입니다. 데이터베이스에서 동시에 활성화된 세션 수를 측정합니다.

성능 개선 도우미는 매초 쿼리를 동시에 실행하는 세션 수를 샘플링합니다. 각 활성 세션에 대해 성능 개선 도우미는 다음 데이터를 수집합니다.

  • SQL 문

  • 세션 상태(CPU에서 실행 중이거나 대기 중)

  • Host

  • SQL을 실행하는 사용자

성능 개선 도우미는 특정 기간 동안의 총 세션 수를 총 샘플 수로 나눠 AAS를 계산합니다. 예를 들어 다음 표는 1초 간격으로 채취된 실행 중인 쿼리의 연속된 5개 샘플을 보여 줍니다.

샘플 쿼리를 실행 중인 세션 수 AAS 계산
1 2 2 총 세션 2회/샘플 1개
2 0 1 총 세션 2회/샘플 2개
3 4 2 총 세션 6회/샘플 3개
4 0 1.5 총 세션 6회/샘플 4개
5 4 2 총 세션 10회/샘플 5개

이전 예시에서 시간 간격에 대한 DB 로드는 2 AAS입니다. 이 측정은 5개의 샘플을 채취한 간격 동안 평균적으로 2회의 세션이 동시에 활성화 상태였음을 의미합니다.

DB 로드는 창고의 작업자 활동에 비유할 수 있습니다. 창고에 100명의 근로자를 고용한다고 가정합니다. 한 주문이 들어오면 한 명의 작업자가 주문을 이행하고 99명의 작업자는 유휴 상태입니다. 100개의 주문이 접수되면 100명의 근로자 모두가 동시에 주문을 처리합니다. 관리자가 15분마다 동시에 활동하는 작업자 수를 기록하고 하루가 끝날 때 이 숫자를 더한 다음 합계를 샘플 수로 나누면 관리자는 동시에 활동하는 작업자의 평균 수를 계산할 수 있습니다. 어제 작업자 평균이 50명이고 오늘은 75명이라면 창고의 평균 활동 수준은 높아진 것입니다. 마찬가지로 데이터베이스 세션 활동이 증가함에 따라 DB 로드가 증가합니다.

평균 활성 실행

초당 평균 활성 실행(AAE)은 AAS와 관련이 있습니다. Performance Insights는 AAE를 계산하기 위해 쿼리의 총 실행 시간을 시간 간격으로 나눕니다. 다음 표는 앞의 표와 동일한 쿼리의 AAE 계산을 보여 줍니다.

경과 시간(초) 총 실행 시간(초) AAE 계산
60 120 2 120초 실행/60초 경과
120 120 1 120초 실행/120초 경과
180 380 2.11 380초 실행/180초 경과
240 380 1.58 380초 실행/240초 경과
300 600 2 600초 실행/300초 경과

대부분의 경우 쿼리의 AAS와 AAE는 거의 동일합니다. 하지만 계산에 입력되는 데이터 원본이 다르기 때문에 계산 결과가 약간 다른 경우가 많습니다.

측정기준

db.load 지표는 차원이라는 하위 구성 요소로 구분할 수 있다는 점에서 다른 시계열 지표와 다릅니다. 차원을 DBLoad 지표의 다양한 특성에 대한 "분할 기준" 범주로 생각할 수 있습니다.

성능 문제를 진단할 때 다음과 같은 차원이 가장 유용한 경우가 많습니다.

Amazon RDS 엔진의 전체 차원 목록은 차원을 기준으로 분할된 DB 로드 섹션을 참조하세요.

대기 이벤트

대기 이벤트란 SQL 문이 계속 실행되려면 특정 이벤트가 발생할 때까지 기다려야 합니다. 대기 이벤트는 작업이 방해되는 위치를 나타내므로 DB 로드에 대해 중요한 측정기준이나 범주입니다.

모든 활성 세션이 CPU에서 실행 중이거나 대기 중입니다. 예를 들어 세션은 메모리에서 버퍼를 검색하거나 계산을 수행하거나 프로시저 코드를 실행할 때 CPU를 사용합니다. 세션에서 CPU를 사용하지 않는 경우 메모리 버퍼가 비어 있거나 읽을 데이터 파일 또는 기록할 로그가 나올 때까지 대기할 수 있습니다. 세션이 리소스를 기다리는 시간이 길수록 CPU에서 실행되는 시간이 줄어듭니다.

데이터베이스를 튜닝할 때 세션이 기다리는 리소스를 찾으려고 하는 경우가 많습니다. 예를 들어 두 개 또는 세 개의 대기 이벤트가 DB 로드의 90%를 차지할 수 있습니다. 이 측정은 평균적으로 활성 세션이 소수의 리소스를 기다리는 데 대부분의 시간을 소비한다는 것을 의미합니다. 이러한 대기의 원인을 찾을 수 있는 경우 해결 방법을 시도할 수 있습니다.

창고 작업자 비유를 기억하세요. 책에 대한 주문이 들어옵니다. 작업자의 주문 이행은 지연될 수 있습니다. 예를 들어 다른 작업자가 현재 선반을 재입고 중이어서 트롤리를 사용하지 못할 수 있습니다. 또는 주문 상태를 입력하는 데 사용된 시스템이 느릴 수 있습니다. 작업자가 기다리는 시간이 길수록 주문을 이행하는 것이 더 오래 걸립니다. 대기는 창고 워크플로의 자연스러운 부분이지만 대기 시간이 지나치게 되면 생산성이 떨어집니다. 같은 방식으로 세션 대기가 반복되거나 길면 데이터베이스 성능이 저하될 수 있습니다. 자세한 내용은 Amazon Aurora 사용 설명서의 Aurora PostgreSQL의 대기 이벤트를 사용한 튜닝과 Aurora MySQL의 대기 이벤트를 사용한 튜닝을 참조하세요.

대기 이벤트는 DB 엔진마다 다릅니다.

참고

Oracle의 경우 연결된 SQL 없이 백그라운드 프로세스가 때때로 수행됩니다. 이 경우 성능 개선 도우미는 콜론으로 연결된 백그라운드 프로세스의 유형과 이 백그라운드 프로세스에 연결된 대기 클래스를 보고합니다. 백그라운드 프로세스의 유형으로는 LGWR, ARC0, PMON 등이 있습니다.

예를 들어 아카이버가 I/O를 수행할 경우 성능 개선 도우미는 ARC1:System I/O와 같이 보고합니다. 경우에 따라 백그라운드 프로세스 유형이 누락되고 성능 개선 도우미가 대기 클래스만 보고할 때도 있습니다(예: :System I/O).

상위 SQL

대기 이벤트는 병목 현상을 표시하는 반면, 상위 SQL은 DB 로드에 가장 많이 기여하는 쿼리를 보여줍니다. 예를 들어 현재 데이터베이스에서 여러 쿼리가 실행 중이더라도 단일 쿼리가 DB 부하의 99%를 소비할 수 있습니다. 이 경우 부하가 높으면 쿼리에 문제가 있음을 나타낼 수 있습니다.

기본적으로 성능 개선 도우미 콘솔에는 데이터베이스 부하에 영향을 미치는 상위 SQL 쿼리가 표시됩니다. 콘솔에는 각 문에 관련된 통계도 표시됩니다. 특정 문의 성능 문제를 진단하기 위해 실행 계획을 검사할 수 있습니다.

계획

단순히 계획이라고도 하는 실행 계획은 데이터에 액세스하는 일련의 단계입니다. 예를 들어, 테이블 t1과 t2를 결합하기 위한 계획은 t1의 모든 행을 반복하고 각 행을 t2의 행과 비교할 수 있습니다. 관계형 데이터베이스에서 옵티마이저는 SQL 쿼리에 대한 가장 효율적인 계획을 결정하는 기본 제공 코드입니다.

Oracle DB 인스턴스의 경우 성능 개선 도우미는 실행 계획을 자동으로 수집합니다. SQL 성능 문제를 진단하려면 리소스 사용량이 많은 Oracle SQL 쿼리에 대해 캡처된 계획을 검토합니다. 계획은 Oracle Database가 쿼리를 구문 분석하고 실행하는 방법을 보여줍니다.

계획을 사용하여 DB 로드를 분석하는 방법을 알아보려면 성능 개선 도우미 대시보드를 사용한 Oracle 실행 계획 분석 섹션을 참조하세요.

계획 캡처

성능 개선 도우미는 5분마다 리소스 사용량이 가장 많은 Oracle 쿼리를 식별하고 해당 계획을 캡처합니다. 따라서 수많은 계획을 수동으로 수집하고 관리할 필요가 없습니다. 대신 상위 SQL(Top SQL) 탭을 사용하여 가장 문제가 많은 쿼리에 대한 계획에 집중할 수 있습니다.

참고

성능 개선 도우미는 텍스트가 수집 가능한 쿼리 텍스트의 최대 한도를 초과하는 쿼리에 대한 계획을 캡처하지 않습니다. 자세한 내용은 성능 개선 도우미 대시보드에서 더 많은 SQL 텍스트에 액세스 섹션을 참조하세요.

실행 계획의 보존 기간은 성능 개선 도우미 데이터와 동일합니다. 프리 티어의 보존 설정은 기본값(7일)입니다. 성능 데이터를 더 오래 보존하려면 1~24개월을 지정하십시오. 보존 기간에 대한 자세한 내용은 성능 개선 도우미의 요금 및 데이터 보존 섹션을 참조하세요.

다이제스트 쿼리

상위 SQL(Top SQL) 탭에는 기본적으로 다이제스트 쿼리가 표시됩니다. 다이제스트 쿼리 자체에는 계획이 없지만 리터럴 값을 사용하는 모든 쿼리에는 계획이 있습니다. 예를 들어 다이제스트 쿼리에는 WHERE `email`=? 텍스트가 포함될 수 있습니다. 다이제스트에는 WHERE email=user1@example.com 텍스트가 포함된 쿼리와 WHERE email=user2@example.com 텍스트가 포함된 쿼리, 이렇게 2개의 쿼리가 포함될 수 있습니다. 이러한 리터럴 쿼리 각각에는 여러 계획이 포함될 수 있습니다.

다이제스트 쿼리를 선택하면 해당 다이제스트의 하위 문에 대한 모든 계획이 콘솔에 표시됩니다. 따라서 계획을 찾기 위해 모든 하위 문을 살펴볼 필요가 없습니다. 상위 10개 하위 문의 표시 목록에 없는 계획을 볼 수 있습니다. 쿼리가 상위 10개에 속하는지 여부에 관계없이 계획이 수집된 모든 하위 쿼리에 대한 계획이 콘솔에 표시됩니다.