• 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 스토리지 엔진
  • 1. InnoDB 소개
    2. InnoDB의 개념과 아키텍처
    3. InnoDB 구성
    4. InnoDB 관리
    5. InnoDB 테이블 스페이스 관리
    6. InnoDB 테이블 관리
    7. InnoDB 압축 테이블
    1. 테이블 압축의 개요
    2. 테이블 압축 사용
    3. InnoDB 테이블의 압축 조정
    4. 런타임 압축 모니터링
    5. InnoDB 테이블에서의 압축 동작
    6. 워크로드의 압축
    7. 압축 구문 경고 및 오류
    8. InnoDB 파일 형식 관리
    9. InnoDB Row Storage and Row Formats
    10. InnoDB 디스크 I/O 및 파일 영역 관리
    11. InnoDB와 온라인 DDL
    12. InnoDB 부팅 옵션 및 시스템 변수
    13. InnoDB의 성능
    14. InnoDB INFORMATION_SCHEMA 테이블
    15. InnoDB 모니터
    16. InnoDB 백업 및 복구
    17. InnoDB와 MySQL 복제
    18. InnoDB 및 memcached의 통합
    19. InnoDB 문제 해결
  • 15. 기타 스토리지 엔진
  • 16. 고가용성 및 확장성
  • 17. 리플리케이션
  • 18. MySQL Cluster
  • 19. 파티셔닝
  • 20. Stored Programs and Views
  • 21. INFORMATION_SCHEMA
  • 22. PERFORMANCE SCHEMA
  • 23. 컨넥터 및 API
  • 24. MySQL 확장
  • 25. MySQL Enterprise Edition
  • 26. MySQL Workbench
  • 27. 제약 및 제한
  • 28. MySQL 5.7 새로운 기능

14.7.4 런타임 압축 모니터링

전체 응용 프로그램의 성능, CPU와 I / O 사용량 및 디스크 파일의 크기는 응용 프로그램에서의 압축 효율 성을 나타내는 적절한 지표입니다. 이 섹션은 섹션 14.7.3 "InnoDB 테이블의 압축 조정" 에 설명 된 성능 튜닝의 조언에 따라 구성되어 초기 테스트시 발생할 수없는 문제를 찾는 방법을 보여줍니다.

압축 테이블의 성능 고려 사항을 더 깊이 파고는 예 14.10 "압축 정보 스키마 테이블의 사용" 에 기재 한 「정보 스키마 " 테이블을 사용하면 런타임에 압축 성능을 모니터 할 수 있습니다. 이 테이블은 메모리 내부 사용 및 전체적으로 사용되는 압축 비율을 반영하고 있습니다.

INNODB_CMP 테이블은 사용중인 압축 된 페이지 크기 ( KEY_BLOCK_SIZE )마다 압축 활동에 대한 정보를보고합니다. 이 테이블의 정보는 시스템 전체이며, 데이터베이스의 모든 압축 테이블에 걸친 압축 통계를 집계 한 것입니다. 이 데이터를 사용하면 다른 압축 테이블이 액세스하지 않을 때 이러한 테이블을 조사하여 테이블을 압축할지 여부를 결정하는 데 도움이됩니다. 여기에는 서버에서 비교적 작은 오버 헤드로 인해 압축 실패의 전반적인 효율성을 확인하기 위해 프로덕션 서버에서 정기적으로 쿼리를 실행할 수 있습니다.

INNODB_CMP_PER_INDEX 테이블에는 개별 테이블 및 인덱스에 대해 압축 활동에 대한 정보를보고합니다. 이 정보는 압축 효율성을 평가하고, 한 번에 하나의 테이블 또는 인덱스의 성능 문제를 진단하는 데보다 중점을두고 수 더 도움이됩니다. (각 InnoDB 테이블은 클러스터 된 인덱스로 표시되기 때문에이 컨텍스트에서는 MySQL에서 테이블 및 인덱스간에 큰 차이가 발생하지 않습니다.) INNODB_CMP_PER_INDEX 테이블에 대량의 오버 헤드로 인해 다양한 워크 로드 데이터 및 압축 설정의 효과를 분리하여 비교할 수있는 개발 서버에 더 적합합니다. 이 모니터링 오버 헤드가 잘못 부과되는 것을 방지하려면 INNODB_CMP_PER_INDEX 테이블의 쿼리를 실행하기 전에 innodb_cmp_per_index_enabled 구성 옵션을 활성화해야합니다.

고려해야하는 주요 통계는 압축 및 압축 해제 작업의 수 및 실행에 필요한 시간입니다. B 트리 노드가 가득 변경 후 압축 된 데이터를 포함 할 수 없게되면, MySQL에 의해 B 트리 노드가 분할되기 때문에 "정상적인"축소 작업의 수와 같은 전체 작업의 수 를 비교합니다. INNODB_CMP 및 INNODB_CMP_PER_INDEX 테이블의 정보 및 응용 프로그램의 전반적인 성능과 하드웨어 리소스 사용량에 따라 하드웨어 구성 변경을 시도하고 버퍼 풀의 크기를 조정하거나 다른 페이지 크기를 선택하거나 압축 다른 테이블 세트를 선택 할 수 있습니다.

압축 및 압축 해제하는 데 필요한 CPU 시간의 합계가 크면 고속 또는 멀티 코어 CPU로 변경하면 동일한 데이터 애플리케이션 워크로드 및 압축 테이블 세트를 사용하여 성능을 개선하기 위해 도움이 있습니다. 버퍼 풀의 크기를 늘리면 성능 향상에 도움이 될 수 있습니다. 그러면 더 비 압축 페이지를 메모리에 머물 수 있도록하므로 압축 형식으로 만 메모리에 존재하는 페이지를 압축 해제해야 적습니다.

(응용 프로그램에서 INSERT , UPDATE 및 DELETE 작업의 수 및 데이터베이스의 크기와 비교하여) 압축 작업 전체 수가 크면 효율적인 압축은 압축 테이블의 일부가 업데이트되는 빈도 너무 높은 것을 의미 할 수 있습니다. 이 경우 더 큰 페이지 크기를 선택하거나 압축 테이블을 더 신중하게 선택하십시오.

"정상적인"압축 작업의 수 ( COMPRESS_OPS_OK ​​)가 축소 작업의 총 수 ( COMPRESS_OPS )이 높은 비율을 차지하고있는 경우 시스템이 제대로 실행되고있을 가능성이 높습니다. 비율이 낮은 경우, MySQL에 의해 이상보다 자주, B 트리 노드 재구성, 재 압축 및 분할이 이루어집니다. 이 경우 일부 테이블의 압축을 회피하거나 압축 테이블의 일부 KEY_BLOCK_SIZE 확대하십시오. 테이블의 압축을 해제하면 응용 프로그램에서 "압축 실패"의 수가 총 1 % 또는 2 %를 초과 할 수 있습니다. (이러한 실패의 비율은 데이터의로드 등의 임시 작업시에는 허용 범위 내인 경우도 있습니다).

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