이 페이지는 Cloud Translation API를 통해 번역되었습니다.

쿼리 통계를 사용하여 쿼리 성능 개선

이 페이지에서는 쿼리 통계 대시보드를 사용하여 성능 문제를 감지하고 분석하는 방법을 설명합니다. 이 기능에 대한 개요는 쿼리 통계 개요를 참고하세요.

Databases의 Gemini 지원을 사용하여 AlloyDB 리소스를 모니터링하고 문제를 해결할 수 있습니다. 자세한 내용은 Gemini 지원을 통한 모니터링 및 문제 해결을 참고하세요.

시작하기 전에

사용자 또는 다른 사용자가 쿼리 계획을 보거나 엔드 투 엔드 추적을 수행해야 하는 경우 특정 ID 및 액세스 관리 (IAM) 권한이 필요합니다. 커스텀 역할을 만들고 여기에 필요한 IAM 권한을 추가할 수 있습니다. 그런 다음 쿼리 통계를 사용하여 문제를 해결할 각 사용자 계정에 이 역할을 추가할 수 있습니다. 커스텀 역할 만들기를 참고하세요.

커스텀 역할에는 cloudtrace.traces.get IAM 권한이 있어야 합니다.

쿼리 통계 대시보드 열기

쿼리 통계 대시보드를 열려면 다음 단계를 수행합니다.

클러스터 및 인스턴스 목록에서 인스턴스를 클릭합니다.
클러스터 개요 페이지의 측정항목 그래프 아래에 있는 쿼리 통계로 이동하여 쿼리 및 성능에 대한 자세한 정보 보기를 클릭하거나 왼쪽 탐색 패널에서 쿼리 통계 탭을 선택합니다.

다음 페이지에서 다음 옵션을 사용하여 결과를 필터링할 수 있습니다.

인스턴스 선택기 클러스터에서 기본 인스턴스 또는 읽기 풀 인스턴스를 선택할 수 있습니다. 기본적으로 기본 인스턴스가 선택됩니다. 표시된 세부정보는 연결된 모든 읽기 풀 인스턴스와 해당 노드에 대해 집계됩니다.
데이터베이스. 특정 데이터베이스 또는 모든 데이터베이스의 쿼리 부하를 필터링합니다.
사용자. 특정 사용자 계정에서 쿼리 부하를 필터링합니다.
클라이언트 주소. 특정 IP 주소에서 쿼리 부하를 필터링합니다.
기간. 시간, 일, 주 또는 커스텀 범위와 같은 시간 범위별로 쿼리 부하를 필터링합니다.

쿼리 통계 대시보드에는 인스턴스 선택기와 데이터베이스, 사용자, 주소에 대한 드롭다운 메뉴가 있습니다. 드롭다운 메뉴 오른쪽에 시간 범위를 설정하는 필터가 있습니다.

쿼리 통계 구성 수정

쿼리 통계는 AlloyDB 인스턴스에서 기본적으로 사용 설정됩니다. 기본 쿼리 통계 구성을 수정할 수 있습니다.

AlloyDB 인스턴스의 쿼리 통계 구성을 수정하려면 다음 단계를 따르세요.

콘솔

Google Cloud 콘솔에서 클러스터 페이지로 이동합니다.

클러스터로 이동
리소스 이름 열에서 클러스터를 클릭합니다.
왼쪽 탐색 패널에서 쿼리 통계를 클릭합니다.
쿼리 통계 목록에서 기본 또는 읽기 풀을 선택한 다음 수정을 클릭합니다.
쿼리 통계 필드를 수정합니다.
1. AlloyDB가 분석할 쿼리 길이의 기본 한도인 1, 024바이트를 변경하려면 쿼리 길이 맞춤설정 필드에 256~4, 500 사이의 숫자를 입력합니다.
  
  이 입력란을 수정하면 인스턴스가 다시 시작됩니다.
  
  참고: 쿼리 길이 제한이 높을수록 메모리가 더 많이 필요합니다.
2. 쿼리 통계 기능 세트를 맞춤설정하려면 다음 옵션을 조정하세요.
  - 쿼리 계획 사용 설정: 이 체크박스를 선택하면 쿼리 샘플을 실행하는 데 사용된 작업을 확인할 수 있습니다.
    최대 샘플링 레이트 필드에 1~20 사이의 숫자를 입력합니다. 기본적으로 샘플링 레이트는 5로 설정됩니다. 샘플링을 사용 중지하려면 쿼리 계획 사용 설정 체크박스를 선택 해제합니다.
    샘플링 레이트는 AlloyDB가 노드당 인스턴스에 대해 분당 샘플링할 수 있는 최대 쿼리 수를 결정합니다.
  - 클라이언트 IP 주소 저장 이 체크박스를 선택하면 쿼리가 발생한 위치를 파악하고 측정항목을 실행하기 위해 해당 정보를 그룹화할 수 있습니다.
  - 애플리케이션 태그 저장 이 체크박스를 선택하면 태그가 지정된 애플리케이션에서 요청을 생성하는지 확인하고 해당 정보를 그룹화하여 측정항목을 실행할 수 있습니다. 애플리케이션 태그에 관한 자세한 내용은 사양을 참고하세요 .
인스턴스 업데이트를 클릭합니다.

gcloud

gcloud alloydb instances update INSTANCE \
--cluster=CLUSTER \
--project=PROJECT \
--region=REGION \
--insights-config-query-string-length=QUERY_LENGTH \
--insights-config-query-plans-per-minute=QUERY_PLANS} \
--insights-config-record-application-tags \
--insights-config-record-client-address

다음을 바꿉니다.

CLUSTER: 업데이트할 인스턴스의 ID입니다.
CLUSTER: 인스턴스 클러스터의 ID
PROJECT: 클러스터 프로젝트의 ID입니다.
REGION: 클러스터의 리전입니다(예: us-central1).
QUERY_LENGTH: 256~4,500 범위의 쿼리 길이
QUERY_PLANS: 분당 구성할 쿼리 계획 수입니다.

또한 다음 선택적인 플래그를 하나 이상 사용합니다.

--insights-config-query-string-length: 기본 쿼리 길이 제한을 256~4500바이트의 지정된 값으로 설정합니다. 기본 쿼리 길이는 1024바이트입니다. 쿼리 길이가 길수록 분석 쿼리에 더 유용하지만 더 많은 메모리가 필요합니다. 쿼리 길이를 변경하려면 인스턴스를 다시 시작해야 합니다. 길이 제한을 초과하는 쿼리에도 태그를 추가할 수 있습니다.
--insights-config-query-plans-per-minute: 기본적으로 인스턴스의 모든 데이터베이스에서 실행된 쿼리 계획 샘플이 분당 최대 5개까지 캡처됩니다. 이 값을 1~20 사이의 숫자로 변경하세요. 샘플링을 사용 중지하려면 0을 입력합니다. 샘플링 레이트를 늘리면 더 많은 데이터 포인트를 얻을 가능성이 있지만 성능 오버헤드가 추가될 수 있습니다.
--insights-config-record-client-address: 쿼리가 시작되는 클라이언트 IP 주소를 저장하고 측정항목을 실행할 수 있도록 데이터를 그룹화할 수 있게 해줍니다. 쿼리는 두 개 이상의 호스트에서 가져옵니다. 클라이언트 IP 주소에서 쿼리 그래프를 검토하면 문제의 원인을 식별하는 데 도움이 될 수 있습니다. 클라이언트 IP 주소를 저장하지 않으려면 --no-insights-config-record-client-address를 사용하세요.
--insights-config-record-application-tags: 요청을 실행하는 API 및 MVC (Model-View-Controller) 경로를 확인하고 이에 대해 측정항목을 실행할 데이터를 그룹화하는 데 도움이 되는 애플리케이션 태그를 저장합니다. 이 옵션을 사용하려면 특정 태그 집합을 사용하여 쿼리에 주석을 추가해야 합니다. 애플리케이션 태그를 저장하지 않으려면 --no-insights-config-record-application-tags를 사용하세요.

쿼리 성능 향상 단계

쿼리 통계는 AlloyDB 쿼리 문제를 해결하여 성능 문제를 찾습니다. 쿼리 통계 대시보드에는 선택한 요소를 기반으로 쿼리 부하가 표시됩니다. 쿼리 부하는 선택한 기간 내의 인스턴스에 있는 모든 쿼리의 전체 작업을 측정한 것입니다.

쿼리 통계는 쿼리 성능 문제를 감지하고 분석하는 데 도움이 됩니다. 쿼리 통계를 사용하면 4단계로 쿼리 문제를 해결할 수 있습니다.

모든 쿼리의 데이터베이스 부하를 확인합니다.
잠재적으로 문제가 발생할 수 있는 쿼리 또는 태그를 식별합니다.
쿼리 또는 태그를 조사하여 문제를 식별합니다.
문제 원인을 trace합니다.

모든 쿼리의 데이터베이스 부하를 확인합니다.

최상위 수준 쿼리 통계 대시보드에 필터링된 데이터를 사용한 데이터베이스 부하 - 모든 상위 쿼리 그래프가 표시됩니다. 데이터베이스 쿼리 부하는 선택한 데이터베이스에서 실행된 쿼리가 시간에 따라 수행되는 작업 (CPU 초)을 측정합니다. 실행 중인 각 쿼리는 CPU 리소스, IO 리소스 또는 잠금 리소스를 사용하거나 대기합니다. 데이터베이스 쿼리 부하는 지정된 기간에 완료된 모든 쿼리에 걸린 시간과 실제로 경과한 시간의 비율입니다.

CPU 용량, CPU 및 CPU 대기, IO 대기, 잠금 대기에 대한 부하가 포함된 데이터베이스 부하 그래프가 표시됩니다.

그래프에서 색상이 지정된 선은 쿼리 부하를 다음 4개의 카테고리로 구분합니다.

CPU 용량: 인스턴스에서 사용할 수 있는 CPU 수입니다.
CPU 및 CPU 대기: 활성 상태의 쿼리에 걸린 시간과 실제로 경과한 시간의 비율입니다. IO 및 잠금 대기는 활성 상태의 쿼리를 차단하지 않습니다. 이 측정항목은 쿼리가 CPU를 사용하고 있거나 다른 프로세스가 CPU를 사용하는 동안 Linux 스케줄러가 쿼리 실행 서버 프로세스를 예약하도록 기다리고 있음을 의미할 수 있습니다.

참고: CPU 부하는 런타임과 Linux 스케줄러가 실행 중인 서버 프로세스를 예약하는 데 필요한 런타임과 대기 시간을 모두 나타냅니다. 따라서 CPU 부하는 최대 코어 라인을 초과할 수 있습니다.
IO 대기: IO 대기 중인 쿼리에 걸린 시간과 벽시계 시간의 비율입니다. IO 대기에는 읽기 IO 대기 및 쓰기 IO 대기가 포함됩니다. PostgreSQL 이벤트 테이블을 참조하세요. IO 대기에 대한 정보를 분석하려면 Cloud Monitoring에서 확인할 수 있습니다. 자세한 내용은 측정항목 차트를 참고하세요.
잠금 대기: 잠금 대기 중인 쿼리에 걸린 시간과 벽시계 시간의 비율입니다. 여기에는 Lock 대기, LwLock 대기, Buffer pin Lock 대기가 포함됩니다. Lock 대기에 대한 정보를 분석하려면 Cloud Monitoring에서 확인할 수 있습니다. 자세한 내용은 측정항목 차트를 참고하세요.

이제 그래프를 검토하고 필터링 옵션을 사용하여 다음 질문에 답하세요.

쿼리 부하가 높은가요? 시간이 지남에 따라 그래프가 급증하거나 상승했나요? 높은 부하가 없으면 쿼리에 문제가 없는 것입니다.
부하는 얼마 동안 높은 상태였나요? 지금 현재만 높나요? 아니면 오랜 기간 동안 높은 상태였나요? 범위 선택 기능을 사용하여 다양한 기간을 선택하고 문제가 발생한 기간을 확인합니다. 또는 확대하여 쿼리 부하 급증이 관측되는 기간을 확인할 수 있습니다. 타임라인을 최대 1주일까지 축소할 수 있습니다.
부하가 높은 원인은 무엇인가요? 옵션을 선택하여 CPU 용량, CPU 및 CPU 대기, 잠금 대기, IO 대기를 확인할 수 있습니다. 각 옵션의 그래프는 서로 다른 색상으로, 부하가 가장 높은 것을 확인할 수 있습니다. 그래프의 어두운 파란색 선은 시스템의 최대 CPU 용량을 보여줍니다. 쿼리 부하를 최대 CPU 시스템 용량과 비교할 수 있습니다. 이 비교를 통해 인스턴스의 CPU 리소스가 부족한지 확인할 수 있습니다.
어떤 데이터베이스에서 부하가 발생하나요? 데이터베이스 드롭다운 메뉴에서 다른 데이터베이스를 선택하여 부하가 가장 높은 데이터베이스를 찾습니다.
특정 사용자 또는 IP 주소로 인해 부하가 높아지나요? 드롭다운 메뉴에서 다른 사용자와 주소를 선택하여 어떤 것이 부하를 높이는지 비교할 수 있습니다.

데이터베이스 부하 필터링

쿼리 및 태그 섹션을 사용하면 선택한 쿼리 또는 SQL 쿼리 태그의 쿼리 부하를 필터링하거나 정렬할 수 있습니다.

쿼리로 필터링

쿼리 테이블에는 쿼리 부하가 가장 많이 발생하는 쿼리의 개요가 제공됩니다. 테이블은 쿼리 통계 대시보드에서 선택한 기간 및 옵션에 대한 정규화된 모든 쿼리를 보여줍니다.

기본적으로 테이블은 선택한 기간의 총 실행 시간을 기준으로 쿼리를 정렬합니다.

CPU 용량, CPU 및 CPU 대기, IO 대기, 잠금 대기에 대해 선택된 필터가 있는 쿼리 부하가 포함된 데이터베이스 부하 그래프를 보여줍니다.

테이블을 필터링하려면 쿼리 필터링에서 속성을 선택합니다. 표를 정렬하려면 열 제목을 선택합니다. 테이블에는 다음 속성이 표시됩니다.

쿼리 문자열. 정규화된 쿼리 문자열입니다. 쿼리 통계에는 기본적으로 쿼리 문자열에 1,024자까지만 표시됩니다.

UTILITY COMMAND 라벨이 지정된 쿼리에는 일반적으로 BEGIN, COMMIT, EXPLAIN 명령어 또는 래퍼 명령어가 포함됩니다.
데이터베이스. 쿼리가 실행된 데이터베이스입니다.
총 시간별 부하/CPU별 부하/IO 대기별 부하/잠금 대기별 부하. 이러한 옵션을 사용하면 특정 쿼리를 필터링하여 옵션별로 가장 큰 부하를 찾을 수 있습니다.
평균 실행 시간(밀리초) 모든 하위 태스크가 쿼리를 완료하는 데 모든 병렬 작업자에서 걸린 총 시간입니다. 자세한 내용은 평균 실행 시간 및 기간을 참고하세요.
호출 횟수. 애플리케이션에서 쿼리를 호출한 횟수입니다.
가져온 행의 평균 개수. 쿼리로 가져온 행의 평균 개수입니다.

쿼리 통계에는 정규화된 쿼리가 표시됩니다. 즉 $1, $2 등이 리터럴 상수 값을 대체합니다. 예를 들면 다음과 같습니다.

UPDATE
  "demo_customer"
SET
  "customer_id" = $1::uuid,
  "name" = $2,
  "address" = $3,
  "rating" = $4,
  "balance" = $5,
  "current_city" = $6,
  "current_location" = $7
WHERE
  "demo_customer"."id" = $8

쿼리 통계가 유사한 쿼리를 집계하고 상수가 표시될 수 있는 모든 PII 정보를 삭제할 수 있도록 상수의 값이 무시됩니다.

쿼리 태그로 필터링

애플리케이션 문제 해결을 위해서는 먼저 SQL 쿼리에 태그를 추가해야 합니다.

쿼리 통계는 ORM을 사용하여 빌드된 애플리케이션의 성능 문제를 진단하기 위한 애플리케이션 중심 모니터링을 제공합니다.

전체 애플리케이션 스택을 담당하는 경우 쿼리 통계는 애플리케이션 뷰에서 쿼리 모니터링을 제공합니다. 쿼리 태그 지정은 비즈니스 로직, 마이크로서비스, 기타 구성 등의 상위 수준 구성에서 문제를 찾는 데 도움이 됩니다. 결제 로직, 인벤토리, 비즈니스 분석, 배송 태그 등과 같은 비즈니스 로직으로 쿼리를 태그할 수 있습니다. 그런 다음 다양한 유형의 비즈니스 로직이 생성되는 쿼리 부하를 찾을 수 있습니다. 예를 들어 오후 1시에 비즈니스 분석 태그의 급증과 같은 예상치 못한 이벤트가 발생할 수 있습니다. 지난 한 주 동안 결제 서비스의 예기치 않은 증가가 나타날 수 있습니다.

쿼리 부하 태그는 시간 경과에 따라 선택된 태그의 쿼리 부하를 분석합니다.

태그용 데이터베이스 부하를 계산하기 위해 쿼리 통계는 사용자가 선택한 태그를 사용하는 모든 쿼리에 걸린 시간을 사용합니다. 쿼리 통계는 실제 경과 시간을 사용하여 분 경계에서 완료 시간을 계산합니다.

쿼리 통계 대시보드에서 태그를 선택하여 태그 테이블을 확인합니다. 태그 테이블은 부하 시간별 총 부하 기준으로 태그를 정렬합니다.

그림 5는 태그 부하가 있는 쿼리 통계 대시보드를 보여줍니다.
그래프 아래에는 태그 목록이 있습니다.

쿼리 필터링에서 속성을 선택하거나 열 제목을 클릭하여 테이블을 정렬할 수 있습니다. 테이블에는 다음 속성이 표시됩니다.

작업, 컨트롤러, 프레임워크, 경로, 애플리케이션, DB 드라이버 쿼리에 추가한 각 속성이 열로 표시됩니다. 태그로 필터링하려면 이러한 속성을 하나 이상 추가해야 합니다.
총 시간별 부하/CPU별 부하/IO 대기별 부하/잠금 대기별 부하. 이러한 옵션을 사용하면 특정 쿼리를 필터링하여 옵션별로 가장 큰 부하를 찾을 수 있습니다.
평균 실행 시간(밀리초) 모든 하위 태스크가 쿼리를 완료하는 데 모든 병렬 작업자에서 걸린 총 시간입니다. 자세한 내용은 평균 실행 시간 및 기간을 참고하세요.
호출 횟수. 애플리케이션에서 쿼리를 호출한 횟수입니다.
가져온 행의 평균 개수. 쿼리로 가져온 행의 평균 개수입니다.
데이터베이스. 쿼리가 실행된 데이터베이스입니다.

특정 쿼리 또는 태그 검사

쿼리 또는 태그가 문제의 근본 원인인지 확인하려면 각각 쿼리 탭 또는 태그 탭에서 다음을 수행합니다.

총 시간별 부하 헤더를 클릭하여 목록을 내림차순으로 정렬합니다.
부하가 가장 높고 다른 것보다 시간이 오래 걸리는 것으로 보이는 쿼리 또는 태그를 클릭합니다.

선택한 쿼리 또는 태그의 세부정보가 표시된 대시보드가 열립니다.

검색어를 선택하면 선택한 검색어의 개요가 표시됩니다.

태그를 선택한 경우 선택한 태그의 개요가 표시됩니다.

특정 쿼리 또는 태그의 부하 검사

데이터베이스 부하 - 특정 쿼리 그래프는 선택한 정규화된 쿼리가 시간 경과에 따라 선택된 쿼리에서 수행한 작업의 측정값(CPU-초)을 보여줍니다. 부하를 계산하기 위해 실제 경과 시간에 대한 분 경계에서 완료된 정규화된 쿼리가 걸린 총 시간을 사용합니다. 테이블 상단에는 정규화된 쿼리의 처음 1, 024자가 표시됩니다 (집계 및 PII상의 이유로 리터럴이 삭제됨). 총 쿼리 그래프와 마찬가지로 데이터베이스, 사용자, 클라이언트 주소를 기준으로 특정 쿼리의 부하를 필터링할 수 있습니다. 쿼리 부하가 CPU 용량, CPU 및 CPU 대기, IO 대기, 잠금 대기로 분할됩니다.

데이터베이스 부하 - 특정 태그 그래프에 선택한 태그와 일치하는 쿼리가 선택한 데이터베이스에서 일정 시간 동안 수행된 작업의 측정(CPU 초)이 표시됩니다. 총 쿼리 그래프와 마찬가지로 데이터베이스, 사용자, 클라이언트 주소를 기준으로 특정 태그의 부하를 필터링할 수 있습니다.

지연 시간 검사

지연 시간 그래프를 사용하여 쿼리 또는 태그의 지연 시간을 검사합니다. 지연 시간은 정규화된 쿼리에서 실제 경과 시간으로 완료하는 데 걸린 시간입니다. 지연 시간 대시보드에 이상치 동작을 찾기 위해 50번째, 95번째, 99번째 백분위수 지연 시간이 표시됩니다.

CPU 용량, CPU 및 CPU 대기, IO 대기, 잠금 대기에 대해 선택된 필터를 사용하여 특정 쿼리의 쿼리 지연 시간 그래프를 표시합니다.

쿼리의 일부를 실행하는 데 사용되는 여러 코어로 인해 쿼리에 대해 쿼리 부하가 높은 경우에도 병렬 쿼리의 지연 시간은 벽시계 시간으로 측정됩니다.

다음을 확인하여 문제의 범위를 좁혀 보세요.

부하가 높은 원인은 무엇인가요? 옵션을 선택하여 CPU 용량, CPU 및 CPU 대기, 잠금 대기, IO 대기를 확인하세요.
부하는 얼마 동안 높은 상태였나요? 지금 현재만 높나요? 아니면 오랜 기간 동안 높은 상태였나요? 부하 성능이 저하된 날짜와 시간을 찾으려면 기간을 변경합니다.
지연 시간이 급증했나요? 기간을 변경하여 정규화된 쿼리의 이전 지연 시간을 조사할 수 있습니다.

부하가 가장 높은 영역과 시간을 찾으면 더 자세히 살펴볼 수 있습니다.

클러스터 전반의 지연 시간 검사

클러스터 전반에서 동일한 쿼리의 P99 지연 시간 그래프를 사용하여 클러스터의 인스턴스 전반에서 쿼리 또는 태그의 P99 지연 시간을 검사합니다.

샘플링된 쿼리 계획의 작업 검사

쿼리 계획은 쿼리의 샘플을 가져와서 개별 작업으로 나눕니다. 쿼리의 각 작업을 설명하고 분석합니다. 쿼리 계획 샘플 그래프에는 특정 시간에 실행되는 모든 쿼리 계획과 각 계획을 실행하는 데 걸린 시간이 표시됩니다.

그래프 하단 (x축)에서 실행될 때 시간과 오른쪽 (y축)에서 실행된 시간이 있는 샘플 쿼리 계획의 그래프를 보여줍니다.

샘플 쿼리 계획의 세부정보를 보려면 샘플 쿼리 계획 그래프에서 점을 클릭하세요. 전부는 아니지만 대부분의 쿼리에 대한 실행된 샘플 쿼리 계획이 표시됩니다. 세부정보를 펼치면 쿼리 계획의 모든 작업 모델이 표시됩니다. 각 작업에는 지연 시간, 반환된 행, 해당 작업의 비용이 나와 있습니다. 작업을 선택하면 공유 적중 블록, 스키마 유형, 실제 루프, 계획 행 등과 같은 더 많은 세부정보를 확인할 수 있습니다.

쿼리 계획에서는 쿼리의 각 작업을 실행하는 데 따르는 지연 시간과 비용을 표시합니다.

다음 질문을 확인하여 문제의 범위를 좁혀 보세요.

리소스 소비란 무엇인가요?
다른 쿼리와는 어떤 연관이 있나요?
시간이 지나면 소비가 달라지나요?

문제 원인 trace

특정 모델, 뷰, 컨트롤러, 경로, 호스트, 사용자와 같은 문제의 특정 원인을 식별하는 데 도움이 될 수 있도록 쿼리 통계는 특정 요청에 대해 데이터베이스 레이어에서 수행되는 작업을 이해하고 모델, 뷰, 컨트롤러, 경로에 따라 문제가 되는 쿼리 원인을 찾을 수 있도록 컨텍스트 내 엔드 투 엔드 애플리케이션 trace 뷰를 제공합니다. OpenCensus 또는 OpenTelemetry를 사용 설정하면 Opencensus 스팬 정보가 SQL 주석의 태그 정보와 함께 데이터베이스로 전송됩니다. 문제의 원인을 식별하기 위해 애플리케이션에서 Cloud Logging으로 전송되는 모든 trace가 데이터베이스 쿼리 계획 trace와 연결됩니다. 샘플 쿼리 화면에서 엔드 투 엔드 탭을 클릭하여 컨텍스트 내 trace를 볼 수 있습니다.

태그에 대한 구체적인 정보를 보려면 END to END 아래에서 태그를 선택합니다. 요약에는 해당 태그의 각 작업에 대한 RPC 및 총 지속 시간이 밀리초로 표시됩니다.

문제를 일으킨 클라이언트와 사용자를 확인하려면 상위 클라이언트 주소와 상위 사용자 테이블을 사용하여 가장 높은 부하를 찾습니다. 사용자 또는 IP 주소를 필터에 추가하면 특정 사용자 또는 클라이언트 주소를 자세히 분석할 수 있습니다.

이미지에는 상위 클라이언트 주소 및 상위 사용자에 대한 정보가 표시됩니다.

쿼리의 경우 Cloud Trace를 사용하면 쿼리 계획의 단계마다 엔드 투 엔드 추적을 확인할 수 있습니다. 쿼리 통계 대시보드에서 Trace에서 보기 링크를 클릭하여 Cloud Trace 도구를 엽니다.

trace 그래프에는 선택한 기간(이 경우 1시간) 동안 실행된 모든 trace가 표시됩니다. 또한 이 페이지에는 지연 시간, HTTP 메서드, URL, trace가 실행된 시간을 보여주는 표가 있습니다.

Cloud Trace에서 도구를 사용하는 방법은 trace 찾기 및 보기를 참조하세요.

SQL 쿼리에 태그 추가

SQL 쿼리에 태그를 지정하면 애플리케이션 문제 해결이 간소화됩니다. sqlcommenter를 사용해서 객체 관계형 매핑(ORM)을 사용하여 자동으로 또는 수동으로 SQL 쿼리에 태그를 추가할 수 있습니다.

ORM과 함께 sqlcommenter 사용

SQL 쿼리를 직접 작성하는 대신 ORM이 사용되는 경우 성능 문제를 일으키는 애플리케이션 코드를 찾지 못할 수 있습니다. 또한 애플리케이션 코드가 쿼리 성능에 어떤 영향을 미치는지 분석하는 데 문제가 있을 수도 있습니다. 쿼리 통계는 이러한 어려움을 해결하기 위해 ORM 계측 라이브러리인 sqlcommenter라는 오픈소스 라이브러리를 제공합니다. 이 라이브러리는 ORM 및 관리자를 사용하여 성능 문제를 일으키는 애플리케이션 코드를 감지하는 개발자에게 유용합니다.

ORM과 sqlcommenter를 함께 사용하면 애플리케이션에 커스텀 코드를 변경하거나 추가할 필요 없이 태그가 자동으로 생성됩니다.

애플리케이션 서버에 sqlcommenter를 설치할 수 있습니다. 계측 라이브러리를 사용하면 MVC 프레임워크와 관련된 애플리케이션 정보를 쿼리와 함께 SQL 주석으로 데이터베이스에 적용할 수 있습니다. 데이터베이스는 이러한 태그를 선택하고 태그별로 통계를 기록 및 집계하며, 이는 정규화된 쿼리를 통해 집계된 통계와 유사합니다. 쿼리 통계에는 쿼리 로드가 발생하는 애플리케이션을 파악할 수 있도록 태그가 표시됩니다. 이 정보는 성능 문제를 일으키는 애플리케이션 코드를 찾는 데 도움이 됩니다.

SQL 데이터베이스 로그에서 결과를 검사하면 다음과 같이 표시됩니다.

SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/

지원되는 태그에는 컨트롤러 이름, 경로, 프레임워크, 작업이 포함됩니다.

sqlcommenter의 ORM 세트는 다양한 프로그래밍 언어로 지원됩니다.

Python	Django psycopg2 Sqlalchemy Flask
자바	최대 절전 모드 봄
Ruby	Rails
Node.js	Knex.js Sequelize.js Express.js

sqlcommenter 및 ORM 프레임워크에서 sqlcommenter를 사용하는 방법에 대한 자세한 내용은 GitHub에서 sqlcommenter 문서를 참조하세요.

sqlcommenter를 사용하여 수동으로 태그 추가

ORM을 사용하지 않는 경우 SQL 쿼리에 sqlcommenter 태그를 수동으로 추가해야 합니다. 쿼리에서 직렬화된 키-값 쌍이 포함된 주석으로 각 SQL 문을 보강해야 합니다. 다음 키 중 하나 이상을 사용하세요.

action=''
controller=''
framework=''
route=''
application=''
db driver=''

쿼리 통계는 다른 모든 키를 삭제합니다. 올바른 SQL 주석 형식은 sqlcommenter 문서를 참조하세요.

실행 시간 및 기간

쿼리 통계는 평균 실행 시간 (ms) 측정항목을 제공합니다. 이 측정항목은 모든 하위 태스크가 쿼리를 완료하는 데 걸리는 총 시간을 모든 병렬 작업자 간에 보고합니다. 이 측정항목을 사용하면 가장 높은 CPU 오버헤드를 생성하는 쿼리를 찾아 최적화하여 데이터베이스의 집계 리소스 사용률을 최적화할 수 있습니다.

경과 시간을 보려면 psql 클라이언트에서 \timing 명령어를 실행하여 쿼리 시간을 측정하면 됩니다. 쿼리를 수신하고 PostgreSQL 서버가 응답을 전송하는 시점 사이의 경과 시간을 측정합니다. 이 측정항목을 사용하면 특정 쿼리가 너무 오래 걸리는 이유를 분석하고 더 빠르게 실행되도록 최적화할지 결정할 수 있습니다.

단일 작업으로 단일 스레드에서 쿼리가 완료되면 기간과 평균 실행 시간은 동일하게 유지됩니다.