MySQL Deep dive with FusionIO

1. 1
송창훈
MariaDB 환경에서 FusionIO Atomic 최적화
Sales Engineering

2. 2
MySQL(MariaDB) + Fusionio 고객

3. 3
FLASH를 사용해야 하는 이유?
 데이터베이스는 FLASH사용으로 완벽하게 성능이 향상됨
 순차/랜덤 I/O , 다양한 block size 가 필요한 환경의 DB 환경은 HDD에서의 운영은 매우 좋지 않음
 오늘날 모든 것이 데이터 베이스로 이루어짐
 FLASH의 독특한 성격은(응답시간/bandwidth) 데이터베이스 기술을 그 다음단계로 인도 하고 있음
 HDD 사용을 고려한 소프트웨어들이 Flash 사용을 고려하여 소프트웨어들을 변경하고 있으며, 높은
application 성능제공함.
 HDD를 이용하는 것 보다, Flash를 사용하는것이 시스템의 내구성 및 높은 성능을 보장 할 수 있음.

4. 4
MySQL 의 특징
 수백 개의 튜닝 방법이 있음
 각각의 MySQL 버전과 storage engine에 따라 parameter 설정이 다름
 사용 환경에 맞는 tuning이 필요함
 제공하는 벤더(Oracle,Maria,Percona)와 각 버전에 따라 성능 차이가 발생함
 특별히 빠르고, 빠르고, 더빠른 스토리지를 계속 하여 요구함
– dev.mysql.com
– percona.com
– mariadb.com

5. 5
Storage Engines
MariaDB
Percona Server
Oracle MySQL
XtraDB
InnoDB
XtraDB와 InnoDB는 상호 호환이 되며,
상호 개발 경쟁(참고) 하고 있음
지난 수년간 Flash를 이용한 storage engine 에
대한 개발을 하고 있음
FLASH 사용에 대한 개발/최적화

6. 6
MySQL 5.1.x (MariaDB 5.1,5.2,5.3)
 5.1.x
– 오래 전에 개발되었으나, 안정적이라고 알려짐..
– 기본 스토리지 엔진은 MyISAM
– Oracle MySQL 5.1.x 은 Flash사용시 상대적으로 느림(MariaDB/Percona)
– Percona/MariaDB 에서 ioMemory 사용을 기반으로 Flash 최적화함
 아직도 많은 고객들이 MySQL 5.1.x 버전을 사용하고 있으나, Flash 스토리지 사용에는 적절하지 않음

7. 7
MySQL 5.5.x (MariaDB 5.5.x)
 InnoDB가 기본 Storage Engine으로 채택됨
 Linux의 Async I/O 사용이 가능해짐
 다양한 Platform 지원(linux, windows, Solaris, AIX)
 고성능 스토리지에(flash) 대한 parameter 제공함
 Fusion-IO의 API 사용이 가능함 (MariaDB 5.5.31+)
 지속적으로 스토리지(FLASH)성능개선에 대한 개발을 하고 있음
 Fusionio고객들은 Percona/MariaDB 를 많이 사용하고 있음

8. 8
MySQL 5.6.x (MariaDB 10.0.x)
 Oracle은 5.6 버전부터 FLASH에 대한 parameter가 제공하고 있음
 Percona/MariaDB 대비하여 성능이 많이 개선됨
 memcached interface를 제공함
 해당 DB 서버에 대한 더 자세한 통계자료가 제공됨
 정합성에 대한 CRC32 checksum이 지원됨
 Binlog group commit에 대해서, replication 수행 시 성능저하 현상에 개선됨(50% 이하)
 2013년 2월 5일 릴리즈됨.
 FLASH device에 대한 API에 대한 추가 개발 (Percona/MariaDB)

9. 9
MySQL 5.7.x (MariaDB 10.1.x)
 Multi-threaded page flushing이 가능해짐
 Fusion-io Atomic write 지원됨 (Oracle, auto detected)
 Fusion-io NVM Compression support (Oracle, innoDB page compression)
 확장성에 대한 개선이 이루어짐

10. 10
10
InnoDB/XtraDB Storage Engine
innodb_buffer_pool_size=75G # DRAM allocated to mysql
innodb_use_native_aio=1 # Use Asynchronous I/O
innodb_log_block_size=4096 # XtraDB only, use 4k block for log file. Can add 25% extra performance.
innodb_use_atomic_writes=1 # Fusion-io only, enable atomic I/O. XtraDB only
innodb_log_files_in_group=2 # 2 log files, 4GB each. Recommended setting
innodb_log_file_size=4G
innodb_thread_concurrency=32 # Number of threads allowed inside storage engine
innodb_flush_method = O_DIRECT # Use direct-io, not buffered
innodb_io_capacity=25000 # Indication of much I/O can be submittet
innodb_max_dirty_pages_pct=90 # When to start flush dirty memory pages more aggressively
innodb_adaptive_flushing=1 # Flush dirty pages adaptively
innodb_adaptive_flushing_method=keep_average # use the keep_average algorithm. XtraDB only
innodb_read_ahead=0 # No need for read-ahead on seek-less storage
innodb_flush_neighbor_pages=0 # No need for sequential flushing on seek-less storage

11. 11
Tuning
충분히 빠른 스토리지(SSD)와의 비교

12. 12
MySQL를 위한 Tuning(VSL, Linux)
• 어떤 database이던지 간에, 모든 내용(log,data)를 Flash에 담으세요.
• On-board DRAM을 사용하는 BBWC(better backuped write cache)를 사용하는 HDD라 하더라도, log를
HDD에 담지 마세요.. Fsync는 매우 비싼 Transaction 입니다.
• HDD의 head 이동에 따라, 불필요한 I/O가 발생하지 않도록 하세요.
• 일반적으로 EXT4와 XFS모두 MySQL에서 좋은 성능을 보여줍니다.
• 최신 VSL(Driver/Firmware)를 사용하세요, 기존의 bug patch 및 성능개선이 제공됩니다.
• 주의: VSL 3.2.5이하 + XFS에서는 반드시 I/O Scheduler를 이용하세요.
• 만약 mySQL이 Fusionio 카드 에서 수행되는 유일한 application이라면, 4K block format을 이용하게되면
대략 5%의 더 좋은 성능을 얻을 수 있음.
• 단, 주의 할 것은 direct-io는 여러 종류의sector size를 요구함(4k, 16k, 512b)
• mySQL에서는 다음의 mount option이 사용됨 ‘-o noatime,discard’ for TRIM support
• TRIM은 MySQL workload에 큰 상관이 없을지 모르지만, DBA/SE들이 종종 file system 위에서 수동으로
copy/move 등의 작업을 수행함

13. 13
Tuning (cont.)
 일반적으로 VSL(virtual storage layer)은 기본 형태로 사용함, 하지만 아래 사항을 고려할 수 있음
– use_workqueue= 의 구문은 Linux의 I/O stack을 hocking 할지 말지를 정할 수 있음
– = 0 (default) I/O scheduler를 bypass 하며, VSL에서 I/O schedule에 대한 처리를 함. Latency와
high-iops를 제공을 받을 수 있음
– =3 (linux I/O stack 사용) 일반적인 block layer로 사용하게 됨. Kernel의 I/O scheduler를 사용하게
되며, 통계정보를 수집할 수 있음
 하나의 서버에 2개 이상의 ioMemory 사용
– 거의 모든 고객들이 Raid0를 사용함
– 기본 512k chunk size를 사용
– 2장을 이용할 경우 한장은 log 다른 한장에는 data를 담게 되는데, 전체 디스크를 사용하여 구성 할
수 있음
– Read에 대한 성능 증가

14. 14
기본적인 MySQL 환경
MySQL master
MySQL slave
MySQL slave
MySQL slave
Writes Reads

15. 15
MySQL Block I/O의 특징
 Queue depth의 길이 제한 (8-32)
 Read/ Write에 대한 I/O 응답 속도가 성능을 좌우함..bandwidth(X)
 Block 단위의 I/O 테스트로는 MySQL 성능 예측이 매우 어려움.
MySQL master
Redo Logs
Binary logs
Data
512b buffered sequential sync read/write
512b buffered sequential sync writes
16k direct random a-sync read/write

16. 16
MySQL 벤치마킹
 다음 3개의 벤치마킹 툴이 mysql 환경에서 많이 쓰임
– Sysbench (OLTP, I/O, memory and thread testing)
– tpcc-mysql (TPC-C’ish workload by Percona)
– Linkbench (Facebook social graph benchmark)
 그리고 mysql power group에서 제공하는 script.

17. 17
MySQL 성능 분석
DATA가 Dram에
올라가고 있음
75% active dataset 이
DRAM에 load됨, CPU
사용률과 전체
transaction 성능이
높아 지고 있음
작업이 지속됨에 따라,
만은 데이터가
스토리지에 저장됨,
저장될때의 Dram
기반의 caching 장지의
spike 현상

18. 18
Fusinoio의 application 가속을 위한 노력:
충분히 빠른 장치를 더 빠르게…
 많은 Software vendor들이 계속하여
flash를 DISK로 이용하는 이점을 활용하여
software를 개발하고 있음
 FLASH 사용에 대하여, 데이터의 배치, I/O
Scheduler, Seek-less 알고리즘의 개발,
다중 접속 (I/O)에 대한 개발 등
 더 빠른 I/O stack 만들기 위한 노력
 가장 빠른 file-system를 만들기 위한 노력

19. 19
MySQL 를 위한 NVM(FLASH) 기반요소
PX600 and SX300
NVMFS file system
MySQL
Atomics
NVM
Compression
• Percona Server 5.6
• MariaDB 10.0.10
• Oracle MySQL 5.7.4
Atomics write(Maria 5.5.31+) 와 NVM compression(Mariadb 10.1.x)
은 별도의 기능으로지원됩니다.
NVMFS는 Fusion-io(Sandisk)에서 개발된 File system으로,
2015년내에 Open-source 될 예정
현재: PX / SX 제품만 Atomic write/NVM compression을 지원
향후: ioDrive/ioScale에 대한 지원할 예정임

20. 20
MySQL Atomic write(원자쓰기) Value
기존 MySQL 쓰기작업 MySQL with Atomic Writes
20
Page
CPage
B
Page
A
Buffe
r
DRAM
Buffer
SSD (or HDD) Database
Database
Server
Page
C
Page
B
Page
A
Page
C
Page
B
Page
A
Page
C
Page
B
Page
A
애플리케이션이
A,B,C 에 대한
update 작업을
준비 합니다.
1
MySQL이
업데이트된
페이지를 Memory
Buffer에 copy
합니다.
2
MySQL이 Media에
두번 buffer 쓰기
작업을 수행합니다.
3
3번 작업이
완료되었다는 신호가
오면, MySQL이
업데이트된 내용을 실제
tablespace에
반영합니다.
4
ioMemory Database
Page
C
Page
B
Page
A
DRAM
Buffer
Page
C
Page
B
Page
A
애플리케이션이
A,B,C 에 대한
update 작업을
준비 합니다.
1
MySQL이
업데이트된
페이지를
Memory
Buffer에 copy
합니다.
2
MySQL이 두 번 버퍼 쓰기를
bypass 하고 바로 tablespace에
적용 시킵니다.
지능형 장치에 의해 자동으로 고
write에 대한 정합성을 보장
받습니다.
3
Database
Server
Page
CPage
B
Page
A

21. 21
Atomics write의 가치
 Atomic write(원자쓰기) 방식은 기존 Write 대비 2배~4배 더 낮은 응답시간을 제공합니다.
 더 적은 횟수로 Media에 접근하기 때문에, 2x 이상의 내구성을 가질 수 있습니다.
1 - Double write
3 - Data
read
Dirty pages
MySQL buffer pool
MySQL dataset
2 - Data flush
Double
write
buffer

22. 22
MySQL NVM Compression(aka; InnoDB Page compression)
Compressed
Data
16K UNALLOCATED
16K =
(32) 512B Sectors
8K =
(16) 512B Sectors on Flash
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
512B
Uncompressed Data16K
 가장 낮은 레이어로 이동 압축
 메모리에 16KB단위로 AS-IS 형태로 저장됨
 각 업데이트와 함께 테이블이 재 압축됨
 사용되지 않는 공간을 위해 TRIM을 이용함
 NVMFS file system은 Media 사용에 대한 더
작은 공간이요구됨
 사전에 선택된 고정 압축 페이지 사이즈에
대한 제약이 없음.
 매우 간단함

23. 23
NVM Compression 구성
 MySQL 버전에 따라 구성방법이 다름
 Fusionio는 고객이 사용하는 DBMS에 따라, 구성 문서를 제공함
 NVMFS구성 문서도 같이 제공됨
 MariaDB의 예
Innodb_compression_algorithm=2
Innodb_use_mt_flush=1
Innodb_mtflush_threads=16
CREATE TABLE <NAME> (<TABLE ATTRIBUTES>) ENGINE=InnoDB PAGE_COMPRESSED=1
PAGE_COMPRESSION_LEVEL=4;

24. 24
NVM Compression 가치
100%
20%
90%
0%
20%
40%
60%
80%
100%
Uncompressed Row Compression NVM-Compression
Transaction Rate Compression Performance Penalty

25. 25
NVMFS access program (샌디스크 코리아)
 1.0.2 GA 버전 제공
 Atomic Series 사용 고객이라면 OK~!
 Atomic/NVM Compression 고객을 위한 Demo Pool 확보
 MariaDB 10.1(Beta, 3월2일 – innodb page compression / Atomic write 지원)
https://www.youtube.com/watch?v=CS6RrX6VreM
…SX300-1600 io Memory and NVMFS filesystem outran by 2.5 (!) hours
in MySQL replication and Virident is still catching up, I'll know the exact time gap when completed.

26. 26
MySQL resources
 www.percona.com
 www.mariadb.org/
 www.mysql.com/
 www.mysqlperformanceblog.com
 dimitrik.free.fr/blog/
 MySQL welcome kit, best practices guide and case studies:http://www.fusionio.com/solutions/mysql/
 NVMFS Video https://www.youtube.com/watch?v=CS6RrX6VreM ( replication 성능비교)

27. 27
Cost Capacity
AMP
ZetaScale
™
Software
FlashSoft® Software
ioTurbine™ Software
SanDisk ION
Accelerator™
Performance
(Bandwidth, IOPS, Latency)
SanDisk 엔터프라이즈 포트폴리오
SplunkLive 2014
27

28. 28
NVMFS / Atomic write / innodb page compression
Torben Mathiasen 는 현재 Principal Apps Engineer 로
SanDisk(Fusionio 2010~)에서 재직중 이며,MariaDB /MySQL 를
위하여 NVMFS / Atomic Write / innoDB page compression을
개발 하고 있으며
또한, Fusionio 제품에 대한 성능/안정성에 대한 software
stack을 개발 하고 있습니다.
SanDisk(Fusionio 2010~)에 합류하기 전에 HP에서 11년간
BL서버의 architecture 와 firmware 에 대해서 개발 을 하였고,
차세대 embedded software stack에 대한 연구/개발/배포를
하고 있습니다.
Linux Kernel(open)에 관하여 Ethernet, PCI-X, storage controller
drivers / SCSI stack에 대한 기여를 하고 있습니다.
또한 Spotify/Ebay/FB 등 web-scale 고객들과 일를 하고
있습니다.

29. 29
Thank you!
www.sandisk.com | www.fusionio.com
changhoon.song@sandisk.com
© 2014 SanDisk Corporation. All rights reserved. SanDisk is a trademark of SanDisk Corporation, registered in the United States and other countries. ZetaScale is a trademark of SanDisk Enterprise IP LLC.
Other brand names mentioned herein are for identification purposes only and may be the trademarks of their holder(s).