성능 분석 예시

동영상 지침을 따라가려면 여기에서 예제 보고서 열기를 클릭하세요.

성능 보고서 해석 방법

HQbird를 사용하거나, 별도 서비스로 cc.ib-aid.com의 IBSurgeon Performance Analysis를 사용하여 Firebird 추적 로그에서 성능 보고서를 생성할 수 있습니다.

이 보고서는 Firebird 데이터베이스에서 SQL 쿼리 실행에 대한 상세 정보를 제공하는 강력한 진단 도구입니다. 이 가이드는 추적 보고서를 해석하고 사용하여 성능 병목 현상을 체계적으로 식별하고 해결하는 방법을 설명합니다.

1. 성능 보고서 구조

┌─────────────────────────────────────────┐
│         Performance Report              │
├─────────────────────────────────────────┤
│ 1. Performance Summary Graphs           │
│    ┌────────────────────────┐           │
│    │  Top queries	      │           │
│    │     Top summary	      │           │
│    │     Top frequency      │           │
│    │     Durations          │           │
│    │     Fetches  	      │           │
│    │     Reads	      │           │
│    │     Writes	      │           │
│    │  Time Series Chart     │           │
│    │     Durations          │           │
│    │     Count of queries   │           │
│    │     Fetches            │           │
│    │     Reads/Writes       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Top Queries Analysis                 │
│    ┌────────────────────────┐           │
│    │ Query Rankings         │           │
│    │                        │           │
│    │  By Duration───┐       │           │
│    │                │       │           │
│    │  By Time   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Plan   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Frequency ─┤       │           │
│    │                │       │           │
│    │  By Plan    ───┤       │           │
│    │  Frequency     │       │           │
│    │                │       │           │
│    │  By Fetches ───┤       │           │
│    │                │       │           │
│    │  By Reads   ───┤       │           │
│    │                │       │           │
│    │  By Writes  ───┘       │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Process Summary                      │
│    ┌────────────────────────┐           │
│    │ Per Process Stats      │           │
│    │ - Execution counts     │           │
│    │ - Fetches, etc	      │           │
│    │ - Duration metrics     │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Address Summary                      │
│    ┌────────────────────────┐           │
│    │Per Client Address Stats│           │
│    │ - Connection counts    │           │
│    │ - Durations  	      │           │
│    │ - Fetches,etc          │    	  │
│    │ - Process names        │ 	  │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Query Details Structure:
┌────────────────────┐
│ Query Information  │
├────────────────────┤
│ - SQL Text         │
│ - Transaction info │
│ - Execution Plan   │
│ - Duration Stats   │
│ - Resource Stats   │
│   * Fetches        │
│   * Reads          │
│   * Writes         │
│   * Marks          │
│ - Client Info      │
└────────────────────┘

성능 보고서는 데이터베이스 활동의 계층적 보기를 제공합니다:

1. Performance Summary Graphs

• 시간에 따른 주요 지표의 시각적 표현 - 활동/부하의 피크를 쉽게 확인할 수 있습니다. (HQbird의 Advanced Performance Monitoring에서 분 단위 분석 보고서도 제공되며, Portal 도구에서 축약 버전을 사용할 수 있습니다 - 자세한 내용은 이 동영상 참조).

• 패턴과 이상 징후를 식별하는 데 도움: 성능이 좋았던 기간(예: 지난 주/월)의 그래프와 성능 문제가 있는 기간을 비교하면 문제를 식별하는 데 도움이 됩니다.

2. Top Queries Analysis

• 포괄적인 분석을 위한 여러 순위 관점: 가장 오래 걸린 쿼리, 가장 빈번한 쿼리, 가장 시간이 많이 소요된 쿼리(텍스트 또는 플랜별로 그룹화) 등.

• 각 차원은 서로 다른 최적화 기회를 보여줍니다

• 각 쿼리에 대한 상세 통계 포함:

• 기간 지표(최소, 최대, 평균, 중앙값)

• 리소스 소비(fetches, reads, writes)

• 실행 패턴 - 상위 쿼리의 출처 수.

3. Process Summary

• 실행 프로세스별 통계 그룹화

• 문제가 있는 애플리케이션 식별에 도움

• 프로세스별 리소스 소비 및 데이터베이스 작업(연결, 쿼리 등)과 지표(fetches, reads 등) 표시

4. Address Summary

• 클라이언트 연결별 통계 그룹화

• 클라이언트 간 부하 분포를 보여줌

• 연결별 특정 문제 식별에 도움

각 섹션은 서로 다른 수준에서 성능 분석을 지원합니다:

• 시스템 전반의 패턴(그래프) - 일반적으로 문제가 발생하는 시기와 위치를 확인합니다.

• 쿼리에서 가장 눈에 띄는 영향(Top Queries) - 먼저 최적화해야 할 쿼리를 식별합니다.

• 애플리케이션 수준 문제(Process Summary) - 성능 문제를 발생시키는 애플리케이션을 식별합니다.

• 클라이언트 수준 문제(Address Summary) - 가장 많은 쿼리 흐름이 있는 IP 주소(워크스테이션, 클라이언트 컴퓨터)를 식별합니다.

2. 시간 요약 및 플랜 요약 분석

성능 상황 분석은 Summary 섹션부터 시작하는 것이 좋습니다. 예제 보고서에서 Plan-Summary 섹션을 열려면 여기를 클릭하세요.

Time Summary는 각 고유 SQL 문 패턴의 총 실행 시간을 집계합니다.

시간이 지남에 따라 어떤 쿼리가 가장 많은 데이터베이스 리소스를 소비하는지 보여주는 “비용 센터” 보고서로 생각하면 됩니다.

쿼리가 매개변수화되지 않은 경우, 즉 SQL 텍스트에 매개변수 자리 표시자(:myparam1) 대신 매개변수 값이 명시적으로 포함된 경우, "Plan-Summary" 섹션을 사용하여 최고 빈도의 쿼리를 식별해야 합니다.

비파라미터화 쿼리의 예: ‘SELECT * FROM COUNTRY WHERE COUNTRYID=2’ 파라미터화 쿼리의 예: ‘SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid’

Summary 섹션의 각 쿼리에는 다음과 같은 주요 부분으로 구성된 헤더가 있습니다:

![](/download/trace/example_3_header.png)

- **Summary**: 전체 시간 비율로, 쿼리가 전체 데이터베이스 시간에서 차지하는 비중을 보여줍니다.

- **Frequency**: 쿼리 패턴이 나타난 횟수

- **Fetch, Read, Write**: 리소스 지표


예를 들어, 다음과 같은 경우

```none hljs
Summary: 19.08% (3920272 of 20541791 ms)

이 쿼리 패턴이 전체 데이터베이스 시간의 거의 20%를 소비하고 있음을 알 수 있습니다. 이는 즉각적인 주의가 필요한 상당한 비중입니다.

아래 헤더의 Plan-Summary 섹션에서는 쿼리를 그룹화하는 데 사용된 SQL 실행 계획을 볼 수 있고, Time-Summary에서는 쿼리 자체의 텍스트가 표시됩니다.

쿼리 패턴은 둘 이상의 특정 쿼리를 나타내므로, 연결에 대한 특정 정보는 패턴에 해당하는 첫 번째 쿼리에서 가져옵니다:

위 스크린샷에서 패턴에 대한 예제 문의 헤더를 볼 수 있습니다. 이 SQL을 시작한 애플리케이션 이름, 연결 ID, 트랜잭션 ID, IP 주소 및 트랜잭션 세부 정보로 구성됩니다.

아래에는 계획(Time-Summary의 경우, Plan-Summary의 경우 이미 시작 부분에 표시되었으므로 생략됨), 파라미터 값(나타난 순서대로), 테이블별 통계가 표시됩니다:

기억하세요, Plan-Summary에서는 실행 계획을 사용하여 SQL을 그룹화합니다. 즉, 패턴에 대해 지속적인 것은 계획뿐이며, Time-Summary에서는 SQL 문 텍스트를 사용하여 그룹화하고 다른 것들(파라미터 값, 실행 시간 등)은 다를 수 있습니다. 이 정보를 실행 패턴의 예로 사용하십시오(99%의 경우 문제를 재현하기에 충분합니다).

아래에는 이 특정 쿼리의 실행에 대한 개별 그래프가 있습니다. 보시다시피, 이 쿼리는 개요 그래프에서 확인한 높은 부하 기간에 시작되었습니다.

마지막으로, 패턴에 해당하는 모든 쿼리에 대한 매우 중요한 통계 모음과 출처 주소 목록이 있습니다:

이 통계에서 최소, 최대, 평균 및 중앙값 실행 시간, 그리고 fetch, read, write, marks(캐시 플러시 작업)에 대한 동일한 통계를 볼 수 있습니다.

2.1. Time Summary 사용 방법:

• 먼저 불균형적으로 많은 시간을 소비하는 쿼리를 식별합니다(이 섹션의 상위 3개 - #1, 2, 3)

• 시간 소비를 빈도와 비교합니다

• 쿼리 섹션 하단에서 평균 실행 시간(총 시간 / 빈도)을 확인합니다(아래 참조)

• 다음과 같은 패턴을 찾습니다:

  • 높은 시간 + 낮은 빈도 = 비효율적인 개별 쿼리

  • 높은 시간 + 높은 빈도 = 잠재적으로 비효율적이지만 많이 사용되는 쿼리

3. 빈도 분석: Frequency 및 Plan-Frequency

빈도 분석을 사용하여 쿼리가 얼마나 자주 실행되는지 이해합니다. 마치 러시아워에 특정 도로가 얼마나 자주 사용되는지 세는 것과 같습니다.

쿼리가 파라미터화되지 않은 경우, 즉 SQL 텍스트에 파라미터 플레이스홀더(:myparam1) 대신 파라미터 값이 명시적으로 포함된 경우, "Plan-Summary" 섹션을 사용하여 최고 빈도의 쿼리를 식별해야 합니다.
비파라미터화 쿼리의 예: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
파라미터화 쿼리의 예: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. 빈도 영향 이해

Frequency 쿼리 패턴의 표현은 Plan/Time Summary와 매우 유사합니다:

고빈도 쿼리는 혼잡한 교차로와 같습니다. 각 차량(쿼리)이 빠르게 이동하더라도, 그 많은 양이 정체를 유발할 수 있습니다. 이는 다음에 영향을 미칩니다:

• 데이터베이스 연결(주차 공간과 같음 - 수가 제한적)

• 네트워크 대역폭(도로 용량과 같음)

• CPU 사용량(교통 통제관이 압도당하는 것과 같음)

• 캐시 효율성(동일한 정보에 반복적으로 접근해야 하는 것과 같음)

고빈도 쿼리의 영향을 추정하려면 parameter threshold = 0으로 트레이스를 수집하십시오.

3.2. 빈도 영향 범주

3.3. 예제 분석

트레이스 보고서의 실제 사례를 살펴보겠습니다:

Frequency: 4,428 executions (24.43% of total)
Impact: Critical - high volume of SALES table queries
Root Cause: Repetitive customer balance checks
Optimization Priority: High

Explanation: This query is running thousands of times, similar to a
busy intersection. Even though each execution might be quick, the
cumulative impact is significant. The application might be checking
balances more often than necessary.

4. xx-Summary 및 Frequency 섹션의 상위 쿼리 통계 분석

Firebird 트레이스 보고서를 분석할 때, 각 쿼리 그룹에는 성능 패턴에 대한 중요한 통찰력을 제공하는 상세한 집계 통계가 포함되어 있습니다. 각 지표를 분석하고 데이터베이스 최적화에 대한 중요성을 이해해 보겠습니다.

4.1. 집계 통계 분석

다음 예제 통계 세트를 살펴보겠습니다:

Total: 4428 items:
Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);
Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);
Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);
Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
From 1 unique addresses: TCPv6:::1 (4428)

4.2. 실행 횟수 분석

4.2.1. 총 항목 수

Total: 4428 items

이는 트레이스 기간 동안 이 특정 쿼리 패턴이 실행된 횟수를 나타냅니다.

이 숫자를 이해하면 다음을 수행하는 데 도움이 됩니다:

• 실행당 리소스 사용량 계산

• 쿼리 캐싱이 유용한지 여부 결정(또는 단순히 덜 자주 실행)

높은 실행 횟수는 다음 기회를 나타낼 수 있습니다:

• 준비된 문(및 파라미터화) 구현 - 동일한 쿼리를 동일한 빈도로 파라미터화하고 반복 실행을 위해 준비하면 더 적은 리소스가 필요합니다

• 결과 캐싱 추가 - 긴 작업 동안 또는 더 오래, 사용자 세션 동안 사용할 결과 값을 캐싱하면 쿼리를 자주 실행할 필요성을 줄일 수 있습니다

• 일괄 처리 - 한 번에 많은 레코드를 반환하거나 처리하기 위해 쿼리를 실행하는 것을 고려하면 쿼리 실행에 대한 오버헤드(준비, 네트워크 전송 등)를 제거할 수 있습니다.

4.3. 기간 지표

4.3.1. 기간 구성 요소 예

Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);

4.3.2. 기간 분석

• 중앙값과 평균이 근접함(457.70ms 대 455.00ms)은 일관된 성능을 시사합니다

• 최대/최소 비율(~11배)은 일부 변동성이 있음을 나타냅니다

• 전체 시간의 20.29%는 상당한 비중입니다 - 이 쿼리가 Frequency 또는 Plan-Frequency 섹션의 상위 3위 안에 있습니까? (네, 그렇습니다.)

4.4. 리소스 사용량 지표

4.4.1. Fetch 작업

Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);

Fetch는 행 검색을 나타냅니다:

• 일관된 fetch 수(min/max 차이가 33에 불과)는 안정적인 결과 집합을 시사합니다

• 상대적으로 높은 fetch 수(실행당 7000회 이상)는 다음을 나타낼 수 있습니다:

• 반환되는 레코드가 많은 경우 결과 집합 제한 및/또는 페이지네이션의 필요성

• 쿼리 최적화 가능성 - 특히 쿼리가 Frequency/Plan-Frequency의 상위 3위 안에 있다면 더욱 의미가 있습니다.

4.5. 읽기 작업

Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);

물리적 읽기는 디스크 접근을 나타냅니다:

• 중앙값이 0이면서 최대값이 0이 아닌 경우는 간헐적인 캐시 미스를 시사합니다

• 전체 읽기의 8.22%는 중간 수준의 I/O 영향을 나타냅니다

• 최소값(0)과 최대값(6995) 사이의 큰 차이는 가변적인 캐시 효율성을 시사합니다.

4.6. 쓰기 작업

Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);

쿼리가 쓰기를 수행하지 않는다면, 일반적으로 읽기 전용 작업입니다.

4.7. Mark 작업

Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);

Mark 작업은 데이터 페이지 캐시 관리와 관련이 있습니다:

• Mark가 0이면 플러시를 위해 표시된 데이터 페이지가 없음을 나타내며, 단순 SELECT 쿼리에서 일반적입니다

• 0이 아닌 mark 작업은 캐시와 관련이 있습니다

4.8. 클라이언트 연결 분석

From 1 unique addresses: TCPv6:::1 (4428)

이는 쿼리 소스 분포를 보여줍니다:

• 단일 클라이언트 주소는 애플리케이션 특정 쿼리를 시사합니다

• 로컬 연결(::1은 IPv6 localhost)

• 모든 4428회 실행이 동일한 소스에서 발생

4.9. 최적화를 위한 이러한 지표 활용

4.9.1. 성능 패턴 분석

실행 일관성

• 최소/최대 기간 비교

• 리소스 사용량의 이상치 확인

• 변동성 확인을 위한 중앙값과 평균 비교

리소스 사용 패턴

• 높은 fetch → 결과 집합 크기 검토

• 높은 읽기 → 인덱스 커버리지 확인

• 높은 mark → 잠금 경합 검토

클라이언트 영향 분석

• 다중 클라이언트 → 연결 풀 크기 조정

• 단일 클라이언트 → 애플리케이션 최적화

4.9.2. 최적화 우선순위

이러한 지표를 기반으로 다음을 우선순위로 삼으십시오:

• 결과 집합 크기

• 실행당 7000회의 fetch

• LIMIT/OFFSET 추가 고려

• SELECT 컬럼 목록 검토

캐싱 전략

• 빈번한 실행(4428회)

• 일관된 결과 크기

• 쓰기 작업 없음

아마도 이 쿼리는 덜 빈번하게 실행될 수 있습니다.

인덱스 사용

• 가변적인 읽기 수

• 중앙값 읽기는 0이지만 최대값은 높음

• 인덱스 커버리지 검토

5. 실제 적용

이 특정 예제의 경우:

단기 개선 사항:

• 결과 캐싱 구현(높은 실행 횟수, 일관된 fetch)

• 결과 집합 크기 검토(실행당 7000회 이상의 fetch)

중기 최적화:

• 인덱스 사용 패턴 분석

• 준비된 문(Prepared Statement) 사용 고려

• 실행 빈도에 대한 애플리케이션 로직 검토

장기 고려 사항:

• 시간에 따른 실행 패턴 모니터링

• 인덱스 유지 관리 전략 계획

• 데이터 접근 패턴 변경 고려

6. 기간 분석

기간 분석은 개별 쿼리가 실행되는 데 걸리는 시간을 조사합니다. 기간을 각 쿼리의 시간을 재는 스톱워치로 생각해 보십시오 - 쿼리가 오래 걸릴수록 성능 문제를 일으킬 가능성이 높아집니다.

6.1. 기간 지표 이해

기간 지표는 사용자 경험에 직접적인 영향을 미치기 때문에 중요합니다. 즉, 사용자가 “시스템이 느리다"고 말합니다. 고객이 긴 줄에서 기다리는 것에 좌절하듯이, 사용자는 쿼리가 완료되는 데 너무 오래 걸릴 때 좌절합니다. 오래 실행되는 쿼리는 다음을 유발합니다:

• 화면 로딩이 너무 오래 걸릴 때의 열악한 사용자 경험

• 장기간 묶여 있는 시스템 리소스

• 느린 쿼리 뒤에서 대기하는 다른 쿼리들

• 애플리케이션의 잠재적 타임아웃 문제

6.2. 영향 범주

6.3. 예제 분석

Duration: 77,793ms
Impact: Critical - single query consuming 77.7 seconds
Root Cause: Complex aggregation in PRC_COLLECT_RANKCATEGORY
Optimization Priority: Immediate

Explanation: This query is taking over a minute to execute, which is like
a complete traffic stoppage. The stored procedure is likely processing
too much data or using inefficient algorithms.

7. 구현 전략

최적화를 교통 시스템 개선으로 생각해 보십시오 - 문제를 식별하고, 솔루션을 계획하고, 변경 사항을 신중하게 구현해야 합니다.

7.1. 우선순위 매트릭스

이 매트릭스는 도시의 교통 문제를 분류하는 것처럼 무엇을 먼저 처리해야 하는지 결정하는 데 도움이 됩니다:

7.2. 단계별 최적화 프로세스

1. 중요 쿼리 식별

• 가장 큰 교통 정체(느린 쿼리) 찾기

• 가장 혼잡한 교차로(고빈도 쿼리) 찾기

• 비효율적인 경로(높은 리소스 사용) 발견

2. 실행 계획 분석

• 현재 경로(인덱스 사용) 연구

• 교통 패턴(조인 방법) 검토

• 병목 지점(정렬 작업) 확인

3. 최적화 구현

• 새 도로 건설(인덱스)

• 경로 재설계(쿼리 재구성)

• 지름길 추가(캐싱)

4. 개선 사항 검증

• 새 교통 흐름 측정(새 추적 보고서)

• 전후 지표 비교

• 효과가 있었던 것 문서화

질문이 있으시면 IBSurgeon에 문의하십시오

질문이 있으시면 언제든지 문의해 주십시오: [email protected].