29.19 Using the Performance Schema to Diagnose Problems

29.19 Using the Performance Schema to Diagnose Problems

29.19.1 Query Profiling Using Performance Schema 29.19.2 Obtaining Parent Event Information

Performance Schema는 “막연한 추측” 대신 실제 측정값을 사용하여 DBA가 성능 튜닝을 수행하도록 도와주는 도구입니다. 이 절에서는 이러한 목적을 위해 Performance Schema를 사용하는 몇 가지 방법을 보여 줍니다. 여기에서의 논의는 Section 29.4.2, “Performance Schema Event Filtering”에서 설명하는 이벤트 필터링의 사용에 의존합니다.

다음 예제는 성능 병목 조사와 같은, 재현 가능한 문제를 분석하는 데 사용할 수 있는 하나의 방법론을 제시합니다. 먼저, 성능이 “너무 느리다”고 간주되어 최적화가 필요한 재현 가능한 유스 케이스를 가지고 있어야 하며, 모든 인스트루멘테이션을 활성화해야 합니다(사전 필터링 없음).

1. 유스 케이스를 실행합니다.

2. Performance Schema 테이블들을 사용하여 성능 문제의 근본 원인을 분석합니다. 이 분석은 사후 필터링에 크게 의존합니다.

3. 문제가 아닌 것으로 판명된 영역에 대해서는 해당 인스트루먼트를 비활성화합니다. 예를 들어, 분석 결과 문제가 특정 스토리지 엔진의 파일 I/O와 관련이 없는 것으로 나타나면, 해당 엔진에 대한 파일 I/O 인스트루먼트를 비활성화합니다. 그런 다음, 이전에 수집된 이벤트를 제거하기 위해 히스토리 및 요약 테이블을 잘라냅니다(truncate).

4. 1단계로 돌아가 이 과정을 반복합니다.

   반복할수록 Performance Schema 출력, 특히 events_waits_history_long 테이블에는 중요하지 않은 인스트루먼트로 인해 발생하는 “노이즈”가 점점 줄어들고, 이 테이블의 크기는 고정되어 있으므로, 현재 분석 중인 문제와 관련된 데이터가 점점 더 많이 포함되게 됩니다.

   반복할수록 “신호/노이즈” 비율이 개선되면서, 조사가 문제의 근본 원인에 점점 더 가까워지고, 분석이 더 쉬워져야 합니다.

5. 성능 병목의 근본 원인이 식별되면, 다음과 같은 적절한 수정 조치를 취합니다:

   • 서버 파라미터(캐시 크기, 메모리 등)를 튜닝합니다.
   • 쿼리를 다른 방식으로 작성하여 튜닝합니다.
   • 데이터베이스 스키마(테이블, 인덱스 등)를 튜닝합니다.
   • 코드를 튜닝합니다(이는 스토리지 엔진 또는 서버 개발자에게만 해당됩니다).

6. 변경 사항이 성능에 미치는 영향을 확인하기 위해 다시 1단계부터 시작합니다.

mutex_instances.LOCKED_BY_THREAD_ID 및 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 컬럼은 성능 병목이나 교착 상태를 조사하는 데 매우 중요합니다. 이는 다음과 같이 Performance Schema 인스트루멘테이션을 통해 가능해집니다:

1. 스레드 1이 뮤텍스를 기다리느라 멈춰 있다고 가정합니다.

2. 해당 스레드가 무엇을 기다리고 있는지 확인할 수 있습니다:

1SELECT * FROM performance_schema.events_waits_current
2WHERE THREAD_ID = thread_1;

예를 들어, 쿼리 결과 스레드가 `events_waits_current.OBJECT_INSTANCE_BEGIN`에서 발견되는 뮤텍스 A를 기다리고 있는 것으로 확인되었다고 합시다.

3. 뮤텍스 A를 보유하고 있는 스레드가 어느 것인지 확인할 수 있습니다:

1SELECT * FROM performance_schema.mutex_instances
2WHERE OBJECT_INSTANCE_BEGIN = mutex_A;

예를 들어, 쿼리 결과 `mutex_instances.LOCKED_BY_THREAD_ID`에서 알 수 있듯이 뮤텍스 A를 보유하고 있는 것은 스레드 2라고 확인되었다고 합시다.

4. 스레드 2가 무엇을 하고 있는지 확인할 수 있습니다:

1SELECT * FROM performance_schema.events_waits_current
2WHERE THREAD_ID = thread_2;