MySQL Performance Tuning (In Korean)

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
MySQL 성능튜닝 여섯가지 팁
Sumi Ryu
MySQL Principal Sales Consultant

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

Agenda
3
MySQL을 위한 Oracle Premier Support
MySQL 성능튜닝 모범사례
여섯가지 팁
결론
Q & A
1
2
3
4
5

MySQL을 위한 Oracle Premier
Support
We’ve Got You Covered

MySQL Enterprise Support
• 최대규모의 MySQL엔지니어와 서포트 조직
• MySQL 개발팀의 후선 지원
• 29개 언어로 세계수준의 지원 서비스
• 핫 픽스 & 유지보수 릴리즈
• 24x7x365
• 횟수 제한없는 지원
• 컨설팅 지원
• 글로벌 규모
Get immediate help for any MySQL
issue, plus expert advice
5

MySQL 컨설팅 지원
• Webex를 이용한 원격 트러블 슈팅
• 복제 리뷰
• 파티셔닝 리뷰
• 스키마 리뷰
• 쿼리 리뷰
• 성능 튜닝
6
Make the Most of your Deployments

7

• “best practices”에 신중해야 함
– 똑 같은 시스템은 없다
– 기존의 옳았던 것도 어쩌면 더 이상 참이 아닐 수 있다.
8

– 똑 같은 시스템은 없다.
• HW 와 SW 밴더는 모두 거짓말쟁이! 그렇지 않습니다.
– 테스트, 벤치마크, 모니터링
– 튜닝을 한번에 하나씩 테스트
– sysbench, mysqlslap, 모니터링 툴을 이용
9

• HW 와 SW 밴더는 모두 거짓말쟁이! 그렇지 않습니다.
– sysbench, mysqlslap 등 모니터링 툴을 이용
• 생각해보세요 – 여러분이 무엇을 작업하고 왜 하는지?
10

– 기존의 환경도 다를수 있다
• HW 와 SW 밴더의 벤치마크테스트
– sysbench, mysqlslap 등 모니터링 툴을 이용
• 생각해보세요 – 여러분이 무엇을 작업하고 왜 하는지?
• 가이드라인이지만, 최적의 설정은 아닐 수 있습니다.
11

• 여러분의 요구사항에 유의
– 어떤 옵션은 성능과 데이터 안전성 중에 선택을 해야함 – 무엇이 더 필요한지?
• 종종 디폴트값이 최적의 값
• 모든 테이블이 PRIMARY KEY를 가지고 있는지 확인
• InnoDB 는 PRIMARY KEY에 의해서 데이터를 관리:
– 실제 row를 찾기위해 PRIMARY KEY가 모든 secondary 인덱스에 포함됨 => 작은
PRIMARY KEY는 작은 secondary 인덱스를 만듬
– 일반적으로 연속적인 PRIMARY KEY 를 추천한다. 왜냐면 기존 row들사이에
새로운 row가 추가되는 걸 피하기 위함.
12

Top 6 Tips
MySQL 성능 튜닝
13

01. 생각
• 생각이 가장 좋은 방어수단
• 성능 문제 분석:
– 무슨 문제인지 정확히 이해한다:
• No: 성능이 너무 느리다.
• Yes:
– 쿼리가 10초간 실행됨, 인터액티브 사용에서는 0.1초이내로 처리되야 함
– 서버는 초당 20만 쿼리를 처리해야 함
– 원인을 파악
• 급히 결론을 내리지 말것
• 전체 스택을 고려
• 원인을 찾았다고 생각하는 이유에 대한 근거제시
14

01. 생각
• 솔루션을 구현
– 생각할 수 있는 모든 솔루션을 나열
• 고정관념을 깨고 생각해야함 – 추측한 사항만 고려하지 않기
– 왜 그 솔루션이 가능한지 설명
– 액션 플랜을 구현:
• 필요한 경우 액션플랜을 테스트하고 수정
• 반드시 테스트 환경과 운영 환경에 동일한 솔루션을 구현해야 함
• 만약 퇴행이 발생한다면, 수행한 각 스텝에 대해 기록을 해야 함
15

02. 모니터링
• 여러분에 시작점(base line)을 제공
• 어떤 일이 발생하고 있는지 알려 준다 – 성능이슈를 조사하는데 도움됨
• 잠재적인 문제를 사전 대처할 수 있음
16

02. 모니터링
• 사용가능한 여러 옵션:
– MySQL Enterprise Monitor
– MySQL Workbench
– Slow Query Log
– Oracle Enterprise Monitor의 MySQL 플러그인
– 그 외 다수
• 심각도 수준에 따라 모든 이벤트에 적절하게 대처하도록 알람을 설정!
17

02. 모니터링
• Linux perf는 실시간 모니터링을 위한 훌륭한 도구이며, 일정한 기간
동안 기록할 수 있음
– https://perf.wiki.kernel.org/index.php/Main_Page
– http://www.brendangregg.com/perf.html
• MySQL Enterprise Monitor는 스냅 샷 데이터를 얻을 수 있는 몇가지
보고서를 제공함
• Workbench는 sys 스키마를 기반으로 하는 성능 보고서를 제공함
“실시간” 모니터링
18

02. 모니터링
MySQL Workbench 성능 보고서
19

02. 모니터링
• sys 스키마는 성능 스키마를 보다 간단하게 사용할 수 있도록 만든 뷰,
함수, 프로시저의 모음
• MySQL 5.7.7 이상 버전에서 디폴트로 포함
• MySQL 5.6 버전에서는 https://github.com/mysql/mysql-sys 를 참조
• 이전에는 Mark Leith의 ps_helper로 알려짐
• https://dev.mysql.com/doc/refman/5.7/en/sys-schema.html
sys 스키마란 무엇인가?
20

02. 모니터링
최적화 할 쿼리 찾기 - MySQL Enterprise Monitor Query Analyzer
21

02. 모니터링
최적화 할 쿼리 찾기 – 성능 스키마 Digest 서머리
mysql> SELECT LEFT(DIGEST_TEXT, 64) AS DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT, MAX_TIMER_WAIT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY MAX_TIMER_WAIT DESC
LIMIT 10;
+------------------------------------------------------------------+------------+-----------------+----------------+
| DIGEST_TEXT | COUNT_STAR | SUM_TIMER_WAIT | MAX_TIMER_WAIT |
+------------------------------------------------------------------+------------+-----------------+----------------+
| INSERT INTO `salaries` VALUES (...) /* , ... */ | 342 | 159811231808000 | 4156961573000 |
| INSERT INTO `dept_emp` VALUES (...) /* , ... */ | 42 | 31561264335000 | 2458392698000 |
| INSERT INTO `titles` VALUES (...) /* , ... */ | 63 | 35738435708000 | 1735350241000 |
| INSERT INTO èmployees` VALUES (...) /* , ... */ | 51 | 18004605187000 | 1679817477000 |
| INSERT INTO `sbtest` ( `k` , `c` , `pad` ) VALUES (...) /* , ... | 10 | 5241286782000 | 1247361451000 |
| COMMIT | 342 | 31984662051000 | 992714081000 |
| DROP SCHEMA IF EXISTS èmployees` | 6 | 1252459420000 | 848771265000 |
| CREATE TABLE `sbtest` ( ìd` INTEGER UNSIGNED NOT NULL AUTO_INCR | 1 | 565468324000 | 565468324000 |
| CREATE TABLE `dept_manager` ( `dept_no` CHARACTER (?) NOT NULL , | 3 | 355874700000 | 220491035000 |
| SELECT COUNT (?) AS `cnt` , `round` ( ( `performance_schema` . ` | 6 | 386062170000 | 217206520000 |
+------------------------------------------------------------------+------------+-----------------+----------------+
10 rows in set (0.00 sec)
22

02. 모니터링
최적화 할 쿼리 찾기 – sys 스키마 95th percentile
23

03. 초기 설정 파일
1. 빈 설정 파일로 시작
2. path, port, 등만 설정
3. 추가적인 모니터링 기능 활성화
4. 용량 설정 사용
5. 더 이상 하지 않기!
24

• 별도의 디스크 시스템을 지정하는 경로를 설정하는 것이 유리함
– 경합을 줄임
– 종종 I/O 가 병목이 됨
– 자주 쓰는 파일을 빠른 디스크로
• 예를 들면, innodb_flush_log_at_trx_commit = 1 및 높은 트랜잭션 커밋 율을 사용하면 높은
플러시 속도를 지원하기 위해 SSD에 InnoDB redo 로그를 배치해야 할 수 있습니다.
• 주: File-per-table테이블 스페이스와 일반 테이블 스페이스는 생성할때
datadir 외부에 위치
경로(Paths)설정
25

• InnoDB를 사용하는 경우, 모든 INNODB_METRICS counters를 활성화:
– innodb_monitor_enable = ‘%’
• 오버 헤드가 작아서 추가 세부정보 수집하는데 가치가 있음
• Performance Schema 활성화 확인
– 오버 헤드가 있지만, 성능 튜닝에 매우 유용한 정보를 제공
– 필요에 따라 추가 consumer 및 instrument 를 활성화 (예를 들면 MySQL 5.7의
트랜잭션)
– 런타임에 성능 스키마를 동적으로 설정가능
추가적인 모니터링 기능 활성화
26

• MySQL 사용자 메뉴얼 (innodb_buffer_pool_size에 관해서):
“전용 데이터베이스 서버에서, 버퍼 풀 크기를 시스템의 실제 메모리
크기의 80%정도로 설정할 수 있다.”
– 1TB의 메모리가 있다면 어떨가요? 여전히 20%만 남겨 다른 용도에 사용하고
싶습니까?
• 대신에:
– 호스트의 메모리 용량은 얼마인가?
– OS와 기타 프로세스에 필요한 메모리 빼기
– InnoDB 버퍼 풀 이외의 MySQL이 필요한 메모리 빼기
– 남은 메모리와 “작업 데이터 셋”의 크기중에서 작은 값을 선택
용량 설정 - innodb_buffer_pool_size
27

• 두가지 옵션에 의해 결정된 총 redo 로그 사이즈:
– innodb_log_file_size
– innodb_log_files_in_group
• 총 사이즈 = innodb_log_file_size * innodb_log_files_in_group
– 지원하는 총 redo 로그 사이즈의 최고치:
• MySQL 5.5 및 이전 버전: 단 4G이하
• MySQL 5.6 및 이상 버전: 단 512G 이하
• “과도한” 체크포인트를 피할 수 있을 만큼 충분히 커야 함
• 큰 redo 로그, 잠재적으로 느린 shutdown이 예상됨
용량 설정 – InnoDB redo 로그
28

• 현재 로그 시퀀스 번호(LSN) 및 마지막 체크포인트 확인:
– SHOW ENGINE INNODB STATUS:
– INNODB_METRICS:
용량 설정 – InnoDB redo 로그 – 충분히 큰가?
---
LOG
---
Log sequence number 602763740
Log flushed up to 602763740
Pages flushed up to 584668961
Last checkpoint at 555157885
mysql> SELECT NAME, COUNT
FROM information_schema.INNODB_METRICS
WHERE NAME IN ('log_lsn_current', 'log_lsn_last_checkpoint');
+-------------------------+-----------+
| NAME | COUNT |
+-------------------------+-----------+
| log_lsn_last_checkpoint | 555157885 |
| log_lsn_current | 602763740 |
+-------------------------+-----------+
29

• 사용된 redo 로그 크기를 계산:
– Used log = log_lsn_current – log_lsn_last_checkpoint
= 602763740 - 555157885
= 47605855 (bytes)
• 총 크기와 비교:
– Used % = (Used log / Total log) * 100
= (47605855 / (innodb_log_file_size * innodb_log_files_in_group)) * 100
= (47605855 / 100663296) * 100
= 47.29 %
30

• 사용율이 75%에 도달하면 비동기 플러시가 발생
– I/O 에 집중되어 다른 업무가 중단 될 수 있음
– 메인 InnoDB 스레드는 flushing buffer pool pages 상태로 될 수 있음
• 피크 부하를 처리할 수 있는 충분한 헤드 룸이 있는지 확인
– 예를 들면 redo 로그의 최대 60% 에서 70% 사용을 목표로 함
• 모니터링 솔루션이 redo 로그 사용율을 모니터링해야 함
• 최신 MySQL 버전에는 향상된 플러시 알고리즘 및 I/O를 제어하는
새로운 옵션이 추가됨
31

• innodb_undo_tablespaces 는 datadir을 초기화 하기 전에만 설정!
• 시스템 테이블스페이스(ibdata1)외부에 undo 로그 테이블스페이스를
만드는 장점:
– 시스템 테이블스페이스를 더 작게 유지
– Undo 로그를 더 빠른 디스크에 보관할 수 있음
– MySQL 5.7 에서 undo 로그 테이블스페이는 삭제 가능
• 각 undo 테이블 스페이스 파일은 최초에 10M
• MySQL 5.7 에서는 최대 95개 undo 테이블스페이스 지원
InnoDB Undo 로그
32

• max_connections – 각 커넥션은 메모리가 필요하기 때문에 너무 크게
설정시 주의해야 함
• table_definition_cache – 모든 테이블이 캐시될 수 있어야함. 테이블이
4000개가 예상된다면 , table_definition_cache > 4000 로 세팅해야 함
• table_open_cache – 각테이블이 한번 이상 오픈될 수 있음
• table_open_cache_instances –일반적으로 16이 적합한 값
기타 용량 옵션
33

04. 버퍼와 캐시
• 캐시를 활성화하는 것이 확실히 더 좋다?
• 캐시와 버퍼는 크면 클수록 확실히 더 좋다 ?
여러 버퍼와 캐시 사용 가능
34

• 캐시를 활성화하는 것이 확실히 더 좋다?
• 캐시와 버퍼는 크면 클수록 확실히 더 좋다 ?
• No!
여러 버퍼와 캐시 사용 가능
35

• 쿼리 캐시를 사용는 것이 좋은 경우는 매우 드물다.
– 단일 뮤텍스로 동작
• 대부분 워크로드는 쿼리 캐시를 사용하지 않는 것이 좋다.
– query_cache_type = 0/have_query_cache =YES
• 쿼리 캐시가 워크로드에 도움이 된다고 생각하면, 테스트 해봐야 함
– Writes가 많을 수록 유리하지 않음
– 버퍼 풀에 데이터가 많을수록 유리하지 않음
– 복잡한 쿼리가 많을 수록, 큰 스캔일 수록, 유리함
• 일반적으로 다른 캐싱 솔루션이 더 좋은 선택임
Query Cache
36

• MySQL 5.5 이전 버전: 단순 인덱스 스캔, range 인덱스 스캔, 그리고
인덱스를 사용하지 않은 조인에만 사용
– 각 매칭 row 크기보다 클 이유가 없음
• MySQL 5.6 이상 버전: Batched Key Access (BKA)경우에도 사용
– 쿼리가 BKA를 사용시 조인 버퍼는 클수록 좋다
• 최소값으로 시작!
• 일반적으로 작은 글로벌 값으로 설정 (컨넥션마다 할당): 32k-256k
• 세션별로 필요할 경우 증가시킴
join_buffer_size
37

• join_buffer_size 와 마찬가지로 작은 글로벌 값으로 설정: 32k-256k
• 글로벌 변수 Sort_merge_passes로 모니터링 가능:
•
• 사용량이 많은 서버에서 Sort_merge_passes값을 작게 하는게 목표임
• 세션별로 필요할 경우 증가시킴
sort_buffer_size
mysql> SHOW GLOBAL STATUS LIKE 'Sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.00 sec)
38

• 일부 버퍼는 사용할 때마다 전체를 할당
• 하나의 쿼리가 여러 버퍼를 사용할 수 있으므로 큰 버퍼로 인해 상당한
메모리 사용이 발생할 수 있음
• 메모리 할당은 상대적으로 비싸다
• 예를 들면 Linux glibc malloc은 임계치를 넘어갈때 메모리 할당하는
알고리즘을 변경(일반적으로 256k 혹은 512k).
– 큰 메모리를 할당하기 위한 알고리즘은 작게 할당하는 것 보다 40배 더 느릴수
있음
작은 글로벌 값이 중요한 이유는 무엇인가?
39

05. 데이터 일관성 대비 성능
• 데이터 안전성을 위해 설정 가능한 값:
– 1: 이론적으로 가장 느리지만, 빠른 SSD를 사용하면 2와 0만큼 빠름
– 2: 매 초마다 플러시함 (5.6+에서 innodb_flush_log_at_timeout)
• OS가 크래시되는 경우 트랜잭션 로스가 발생
– 0: MySQL은 fsyncs 전혀 하지않음
• OS가 크래시되는 경우 트랜잭션 로스가 발생
• 디폴트값은 1 – 매번 커밋하는 시점에 redo 로그를 플러시
– ACID중에 D의 요구사항
– 이런 이유로 이 값을 사용하는 것을 권장
innodb_flush_log_at_trx_commit
40

• 만약 innodb_flush_log_at_trx_commit = 1 인 경우 너무 느리고 동시에
ACID의 D가 요구된다면 ?
– Redo 로그를 별도의 디스크에 위치하게 해야함
• 개별 redo 로그를 서로 다른 디스크에 보관하지 않음
– 특히 커밋 비율이 높으면 SSD를 고려
– 배터리 지원 디스크 캐시 또한 플러시 비용 절감함
innodb_flush_log_at_trx_commit
41

• 바이너리 로그의 두 플러시 사이의 트랜잭션 수 지정
– 0: 바이너리 로그를 rotating하거나 OS가 결정
– 1: 매번 트랜잭션 커밋시 – 가장 안전함
– N: 매 N개의 커밋이 발생시
• 디폴트 값:
– MySQL 5.6 및 이전버전: 0
– MySQL 5.7 및 이상버전: 1
• MySQL 5.6 및 이상은 sync_binlog = 1의 오버헤드를 줄이는 InnoDB에
대한 그룹 커밋을 지원
sync_binlog
42

• sync_binlog != 1 인 경우 마스터가 죽으면 슬레이브가 재구축 되여야
함을 의미
• 그러면 sync_binlog = 0 인 경우라면 성능이 가장 좋은가?
sync_binlog
43

• sync_binlog != 1 인 경우 마스터가 죽으면 슬레이브가 재구축 되여야
함을 의미
• 그러면 sync_binlog = 0 인 경우라면 성능이 가장 좋은가?
– 디폴트: max_binlog_size = 1G
– 현재 1G 메모리는 큰 사이즈가 아님
– 그래서 OS는 전체 바이너리 로그를 버퍼링 할 수 있음
– 바이너리 로그가 rotating 할때, 1G가 디스크로 플러시
• 바이너리 로그 rotaiton이 완료 될때 까지 모든 커밋을 중지
• 즉: sync_binlog = 0은 최상의 처리량을 제공하지만 sync_binlog = 1은
가장 예측가능한 성능을 제공할 수 있다.
sync_binlog
44

06. 전체 스택 고려
• 이슈는 전체 스택의 어느 부분에서나 발생 가능, e.g.:
– 애플리케이션
– 애플리케이션 호스트/하드웨어
– 애플리케이션과 MySQL 호스트 사이의 네트워크
– MySQL 호스트/하드웨어
– MySQL
• 이것을 모니터링 할 때 고려해야 함
• OS/하드웨어 세팅을 고려해야 함
45

• 충분한 RAM이 있는지 확인
– 액티브한 데이터는 버퍼풀에 맞아야 함
– MySQL 컨넥션과 캐시는 메모리를 사용
– 그외
• FS 캐시
• 모니터링
• RAM 디스크 (tmpfs)
하드웨어 고려 사항
46

• 싱글 스레드의 성능을 위해서 빠른 CPU 필요
• 최근 서버는 32 ~ 80 개의 코어를 지원.
• 하이퍼 스레딩 활성화
• MySQL 5.7에서는 72 코어 이상으로 확장 가능
• 더 적은 수의 소켓에서 동일한 코어 수가 더 좋음
• 느린 코어보다 빠른 코어가 좋음
하드웨어 고려 사항
47

• IO 바운드 작업에는 빠르고 안정적인 스토리지가 적합
• 순차적 읽기및 쓰기에는 HDD 적합
• 랜덤 읽기와 쓰기를 위해서는 Bus-attached SSD
• 로그 파일 용으로는 Big sata 혹은 기타 디스크
• 여러개의 디스크!
• Life time을 고려해야 함
하드웨어 고려 사항 - 스토리지
48

• LAMP의 L
• Solaris에서 좋음
• 오라클은 Windows 환경에 대해 투자하고 있음
• 좋은 성능을 위해서는 Linux 선호
Operating System
49

• I/O 스케줄러
– 여러 Linux 배포판은 기본적으로 CFQ 스케줄러를 사용
• 읽기에 좋으나
• 쓰기에는 직렬화!
– NOOP와 deadline은 일반적으로 MySQL 워크로드에 더 좋음
• Deadline은 Oracle Linux의 기본 I/O스케줄러임
OS에서의 I/O 세팅
50

• I/O 스케줄러
– 현재 스케줄러 확인:
– 동적으로 스케줄러 변경:
– 부팅시 설정하려면, “elevator=deadline” 옵션을 사용.
OS에서의 I/O 세팅
shell# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
shell# echo deadline > /sys/block/sda/queue/scheduler
shell# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
51

• Linux glibc malloc은 성능 병목이 될 수 있음
• 다른 malloc 라이브러리를 사용하는 것이 더 좋음:
– tcmalloc
– jemalloc
메모리 할당 라이브러리
52

• 다른 malloc 라이브러리 설정:
– mysqld_safe
– systemd distributions:
• /etc/sysconfig/mysql에 LD_PRELOAD를 설정
메모리 할당 라이브러리
[mysqld_safe]
malloc-lib = /usr/lib64/libjemalloc.so.1
53

결론
Wrapping it all up
54

결론
• MySQL 성능 튜닝은 다른 모든 성능 튜닝과 유사:
– 미숙한 성능 튜닝은 좋은 결과를 얻지 못한다.
– 한번에 한 가지만 변경하고 너무 많이 변경하지 말자.
– 전체적인 관점에서 관리하자.
– 한가지 변경이 모든 것에 맞지 않을 수 있다.
– 테스트 결과에 근거하여 결정을 내리자.
– 옵션을 변경하기 전에 옵션의 기능을 이해하자.
– 여러분의 시스템(데이터)에 대해 이해하자.
– 여러분이 무엇을 원하는지 확인하자.
– 전반전인 스택을 고려하자.
55

감사합니다!
Q&A
56

MySQL Performance Tuning (In Korean)

MySQL Performance Tuning (In Korean)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MySQL Performance Tuning (In Korean)

Similar to MySQL Performance Tuning (In Korean) (20)

More from OracleMySQL

More from OracleMySQL (11)

MySQL Performance Tuning (In Korean)