MySQL Deep dive with FusionIO

1

송창훈

MariaDB 환경에서 FusionIO Atomic 최적화

Sales Engineering

2

MySQL(MariaDB) + Fusionio 고객

3

FLASH를 사용해야 하는 이유?

데이터베이스는 FLASH사용으로 완벽하게 성능이 향상됨

순차/랜덤 I/O , 다양한 block size 가 필요한 환경의 DB 환경은 HDD에서의 운영은 매우 좋지 않음

오늘날 모든 것이 데이터 베이스로 이루어짐

FLASH의 독특한 성격은(응답시간/bandwidth) 데이터베이스 기술을 그 다음단계로 인도 하고 있음

HDD 사용을 고려한 소프트웨어들이 Flash 사용을 고려하여 소프트웨어들을 변경하고 있으며, 높은 application 성능제공함.

HDD를 이용하는 것 보다, Flash를 사용하는것이 시스템의 내구성 및 높은 성능을 보장 할 수 있음.

4

MySQL 의 특징

수백 개의 튜닝 방법이 있음

각각의 MySQL 버전과 storage engine에 따라 parameter 설정이 다름

사용 환경에 맞는 tuning이 필요함

제공하는 벤더(Oracle,Maria,Percona)와 각 버전에 따라 성능 차이가 발생함

특별히 빠르고, 빠르고, 더빠른 스토리지를 계속 하여 요구함

– dev.mysql.com

– percona.com

– mariadb.com

5

Storage Engines

MariaDB

Percona Server

Oracle MySQL

XtraDB

InnoDB

XtraDB와 InnoDB는 상호 호환이 되며, 상호 개발 경쟁(참고) 하고 있음

지난 수년간 Flash를 이용한 storage engine 에 대한 개발을 하고 있음

FLASH 사용에 대한 개발/최적화

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

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


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


Multi-threaded page flushing이 가능해짐

Fusion-io Atomic write 지원됨 (Oracle, auto detected)

Fusion-io NVM Compression support (Oracle, innoDB page compression)

확장성에 대한 개선이 이루어짐

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

Tuning

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

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

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

기본적인 MySQL 환경

MySQL master

MySQL slave

MySQL slave

MySQL slave

Writes Reads

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

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

MySQL 성능 분석

DATA가 Dram에

올라가고 있음

75% active dataset 이

DRAM에 load됨, CPU

사용률과 전체

transaction 성능이

높아 지고 있음

작업이 지속됨에 따라,

만은 데이터가

스토리지에 저장됨,

저장될때의 Dram

기반의 caching 장지의

spike 현상

18

Fusinoio의 application 가속을 위한 노력: 충분히 빠른 장치를 더 빠르게…

많은 Software vendor들이 계속하여 flash를 DISK로 이용하는 이점을 활용하여 software를 개발하고 있음

FLASH 사용에 대하여, 데이터의 배치, I/O Scheduler, Seek-less 알고리즘의 개발, 다중 접속 (I/O)에 대한 개발 등

더 빠른 I/O stack 만들기 위한 노력

가장 빠른 file-system를 만들기 위한 노력

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

MySQL Atomic write(원자쓰기) Value

기존 MySQL 쓰기작업 MySQL with Atomic Writes

20

Page C Page

B

Page A

Buffer

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 C Page

B

Page A

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

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 Data 16K

가장 낮은 레이어로 이동 압축

메모리에 16KB단위로 AS-IS 형태로 저장됨

각 업데이트와 함께 테이블이 재 압축됨

사용되지 않는 공간을 위해 TRIM을 이용함

NVMFS file system은 Media 사용에 대한 더 작은 공간이요구됨

사전에 선택된 고정 압축 페이지 사이즈에 대한 제약이 없음.

매우 간단함

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

NVM Compression 가치

100%

20%

90%

0%

20%

40%

60%

80%

100%

Uncompressed Row Compression NVM-Compression

Transaction Rate Compression Performance Penalty

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.

https://www.youtube.com/watch?v=CS6RrX6VreM


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 성능비교)

https://mariadb.org/

https://mariadb.org/

http://www.mariadb.org/

http://www.mysql.com/

http://www.mysqlperformanceblog.com

http://dimitrik.free.fr/blog/



http://www.fusionio.com/solutions/mysql/





27

Cost Capacity

AMP

ZetaScale™ Software

FlashSoft® Software

ioTurbine™ Software

SanDisk ION Accelerator™

Performance (Bandwidth, IOPS, Latency)

SanDisk 엔터프라이즈 포트폴리오

SplunkLive 2014 27

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

Thank you! www.sandisk.com | www.fusionio.com

[email protected]

© 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).

MySQL Deep dive with FusionIO

Internet

Transcript of MySQL Deep dive with FusionIO