• MySQL매뉴얼
    • MySQL 5.6 매뉴얼
    • MySQL 5.1 매뉴얼
    • MySQL 5.0 매뉴얼
    • MySQL HA 매뉴얼
  • 기술문서
    • Xtrabackup 구성
    • 메모리 사용량 모니터링
  • 라이선스
  • 온라인문의
  • 회사소개
  • → 목 록 (MySQL5.6 한글메뉴얼) [close]
  • 1. MySQL 5.6 새로운 기능
  • 2. MySQL 설치 및 업그레이드
  • 3. MySQL Tutorial
  • 4. MySQL 프로그램
  • 5. MySQL 서버관리
  • 6. 보안
  • 7. 백업 및 복구
  • 8. 최적화
  • 9. Language Structure(언어구조)
  • 10. Character Sets(Globalization)
  • 11. 데이터형(Data Types)
  • 12. 함수와 연산자
  • 13. SQL 문법
  • 14. InnoDB 스토리지 엔진
  • 15. 기타 스토리지 엔진
  • 16. 고가용성 및 확장성
  • 17. 리플리케이션
  • 18. MySQL Cluster
  • 19. 파티셔닝
  • 20. Stored Programs and Views
  • 21. INFORMATION_SCHEMA
  • 22. PERFORMANCE SCHEMA
  • 1. Performance Schema 빠른 시작
    2. Performance Schema 구성
    3. Performance Schema 쿼리
    4. Performance Schema Instrument Naming Conventions
    5. Performance Schema Status Monitoring
    6. Performance Schema Atom and Molecule Events
    7. Performance Schema Statement Digests
    8. Performance Schema의 일반적인 테이블 특성
    9. Performance Schema 테이블 설명
    10. Performance Schema Option and Variable Reference
    11. Performance Schema Command Options
    12. Performance Schema System Variables
    13. Performance Schema Status Variables
    14. Performance Schema and Plugins
    15. 문제를 진단하기위한 Performance Schema 사용
  • 23. 컨넥터 및 API
  • 24. MySQL 확장
  • 25. MySQL Enterprise Edition
  • 26. MySQL Workbench
  • 27. 제약 및 제한
  • 28. MySQL 5.7 새로운 기능

22.15 문제를 진단하기위한 Performance Schema 사용

성능 스키마는 DBA가 "거친 추측 '이 아니라 실제로 측정하여 성능 튜닝을 할 수있는 도구입니다. 이 섹션에서는이 목적으로 성능 스키마를 사용하는 몇 가지 방법에 대해 설명합니다. 여기에서의 설명은 섹션 22.2.3.2 "성능 스키마 이벤트 필터링」 에서 설명하고있는 이벤트 필터링의 사용에 따라 달라집니다.

다음 예제에서는 성능 병목 현상 조사 등 반복되는 문제의 분석에 사용할 수있는 한 가지 방법을 보여줍니다. 시작하려면 성능이 "너무 늦게"로 간주되고 최적화가 필요한 반복 가능한 유스 케이스가 필요하며 모든 계측을 활성화해야합니다 (사전 필터링없이).

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

  2. 성능 스키마 테이블을 사용하여 성능 문제의 원인을 분석합니다. 이 분석은 사후 필터링에 크게 의존합니다.

  3. 제외 문제 영역에 대해서는 해당 instrument를 해제합니다. 예를 들어, 문제가 특정 스토리지 엔진의 파일 I / O 관련하지 않는 것으로 분석으로 표시된 경우 엔진의 파일 I / O instrument를 해제합니다. 그 후 히스토리 및 요약 테이블을 잘라 지금까지 수집 된 이벤트를 제거합니다.

  4. 1 단계의 과정을 반복합니다.

    반복 할 때마다 성능 스키마의 출력 특히 events_waits_history_long 테이블에 저장되는 무의미한 instrument에 의해 발생하는 '노이즈'가 줄어이 테이블이 고정 크기 인 경우, 당면 문제 분석 관련 데이터가 증가합니다.

    반복마다 조사는 문제의 원인에 접근 해가는 것이며, 「시그널 / 노이즈 율 '이 개선되면서 분석이 쉬워집니다.

  5. 성능 병목 현상의 원인을 파악하면 다음과 같은 적절한 수정 조치를 취합니다.

    • 서버 매개 변수 (캐시 크기, 메모리 등)을 조정합니다.

    • 쿼리를 다른 방식으로 써 튜닝합니다.

    • 데이터베이스 스키마 (테이블, 인덱스 등)를 조정합니다.

    • 코드를 조정할 수 있습니다 (이것은 스토리지 엔진 또는 서버 개발자에게만 적용됩니다).

  6. 1 단계에서 다시 시작하여 성능에 변화의 효과를 확인합니다.

mutex_instances.LOCKED_BY_THREAD_ID 및 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 열 성능 병목 현상 또는 교착 상태의 조사에 매우 중요합니다. 이것은 다음과 같은 성능 스키마 계측에 의해 가능하게됩니다.

  1. 스레드 1은 상호 배타적 잠금을 대기하고 막히게합니다.

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

    SELECT * FROM events_waits_current WHERE THREAD_ID = thread_1;
    

    예를 들어, events_waits_current.OBJECT_INSTANCE_BEGIN 에있는 것처럼 스레드가 상호 배타적 잠금 A를 기다리는 것이 쿼리 결과에 표시됩니다.

  3. 상호 배타 락 A를 유지하고있는 thread를 확인할 수 있습니다.

    SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
    

    예를 들어, mutex_instances.LOCKED_BY_THREAD_ID 에있는 것처럼 상호 배타적 잠금 A를 보유하고있는이 스레드 2임을 쿼리 결과에 표시됩니다.

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

    SELECT * FROM events_waits_current WHERE THREAD_ID = thread_2;
    


서울시 강남구 영동대로 602 6층
TEL: 02-6061-0006  /  E: csr@mysqlkorea.com
주식회사 이노클러스터  등록번호 : 727-86-02261
Copyright © innocluster Co. ltd. all rights reserved