[db tech showcase Tokyo 2017] A27: ストレージ視点から見たMariaDB性能チューニング by 東芝メモリ株式会社佐藤修一

ストレージ視点から見た
MariaDB性能チューニング
db tech showcase 2017 Tokyo
2017年9月6日 16:30～17:20
東芝メモリ株式会社
SSD事業部 SSD応用技術部 SSD応用技術担当主幹
佐藤修一

2© 2017 Toshiba Memory Corporation
• はじめに
• NVMeTM SSDの実力
• Linux OSの影響
• MariaDB™ (innodb)性能チューニング
• まとめ
Agenda
・PCIeはPCI-SIG社の商標です。
・NVMeはNVM Express, Inc.の商標です。
・その他本文中に記載されている会社名および製品名は、それぞれ各社が商標または登録商標として使用している場合があります。

• はじめに
• NVMe SSDの実力
• MariaDB(innodb)性能チューニング
• まとめ

幅広いSSDラインナップで、多様なアプリケーションに対応します！
SSD製品の適用分野
ハイエンド
PC
ホームサーバ
データセンタ
監視カメラカムコーダ
航空機内
AVシステム
組み込み用
ストレージ
POSシステム
タブレット
タブレット
PC
エンタープライズ
サーバ/ストレージ
Toshiba SSDTMC NAND Flashメモリ搭載
電子楽器
映像編集機器
医療計測器

東芝メモリSSDラインアップ

Enterprise向けSSDの性能
0
500
1000
1500
2000
2500
3000
3500
4000
0 100 200 300
円形の面積：SSD容量
MB/sシーケンシャルライト
0
500
1000
1500
2000
2500
3000
3500
4000
0 200 400 600 800
HK4
シーケンシャルリード
円形の面積：SSD容量
K IOPSランダムリードK IOPSランダムライト
シーケンシャルライト性能シーケンシャルリード性能
PX04S
PX04S
PX04P
PX04P
HK4
MB/s

• はじめに
• まとめ

• MySQL™をDefault Configurationのまま使用した場合のNVMe SSD のTPC™
TPC-C™性能は、NL HDD(8台 RAID1+0)の1.5～３倍の性能
Default ConfigurationでもNVMe SSDは早いけど・・・
Red Hat Enterprise Linux® 6.6, MySQL 5.6.28, HammerDB 2.1.18
Warehouse:3000
NVMe SSD(PX04PMB080) vs NL HDD(MG05ACA800E )8台 RAID1+0

• MySQLのDefault ConfigurationでNVMe SSDを使用しても、
ConfigurationをチューニングしたNL HDD(8台 RAID1+0)の性能に及ばない
• NVMe SSDでもRDBのConfigurationチューニングは必要！
Default ConfigurationでNVMe SSDを使っても・・・
Red Hat Enterprise Linux 6.6, MySQL 5.6.28, HammerDB 2.1.18
Warehouse:3000

• やっぱりNVMe SSDは、速い！ Max 12MTPM(200KTPS)
• 注：
– NL HDDでもMax 1900KTPM(約31KTPS)
– 現行のNL HDDは、旧世代15Krpm HDD同等以上のTPC-C性能
MySQLの設定をチューニングしたら…
Red Hat Enterprise Linux 6.6, MySQL 5.6.28, HammerDB 2.1.18
Warehouse:3000

• はじめに
• まとめ

• Many Core CPU, RAID Controller同様にSSD内部でRead/Write要求を並列
処理することで性能を上げている。
• SSD性能を使い切るためには、同時に多数のRead/Write要求を発行する必要がある。
• PCIe ® Gen3 X4の帯域を使い切るEnterprise SSDでは、状況によっては
Linux Kernel, File Systemがボトルネックとなって、SSDの性能を生かせない
– Linux Kernel Page CacheのWrite Back
– File Systemの排他制御
NVMe SSDが速くなって・・・

• 以下のPage Cacheの機能から、小サイズのSequential Accessでは、Page Cacheを使用した方がI/O性能
が高い
– アプリケーションが4KiBでRead/Writeしてもストレージへのアクセスは、Read: Max 256KiB, Write: Max
512KiB(CentOS 7.3 NVMe SSDの場合)と大サイズでアクセス
– 書き換えられたDirty Pageを4～8Thereadsで書き込み
• 特にReadの先読み効果が大きく、Sequential Accessが多いアプリケーションは、Page Cacheを使用し
た方がSSDの性能を生かせる
Page Cache VS O_DIRECT(Sequential Read/Write)

• 小サイズのRandom Accessの場合、Page Cacheの優位性がなくなる
– アプリケーションのアクセスサイズでストレージをアクセス
– 先読みの効果が少ない
• FIO同様にlibaioを使用するなどし、アプリケーションが同時Read/Write要求数を4以上にで
きれば、O_DIRECTを使用した方がSSD性能を生かせる
Page Cache VS O_DIRECT(Random Read/Write)
1

• TraditionalなFile System(ext4, xfs)では、１Fileに対するI／O性能にFile Systemの排他制
御が原因と思われる性能限界がある
同時にコマンドを発行しすぎても・・・
Job数xI/O Depthが64を超えるとRAW I/Oより性能が低下
Job4:16, Job8:8, Job16:4, Job32:2
I/O Depth:16以上で
性能低下
Fio RAW I/O, _DIRECT I/O Performance(ext4)

• 性能を突き詰めていくとPage Cahce, File Systemの影響を受ける
– innodb_flush_method: dsatasync(Default) からO_DIRECT ⇒ 20～40％の向上
– innodb_file_per_table:OFF(Default)からON ⇒ 4～8％の向上とFile Systemの影
響は少ない。
TPC-C性能に対する影響は？

• はじめに
• まとめ

• 他にも試してみたので紹介させて頂きます
– Innodb_buffer_pool_sizeだけ増やしたら？
– I/O関係の設定だけ変更したら？
– どの設定を変更するのが、一番効果があるの？
MariaDB™(InnoDB)性能チューニング

Model Name, Version
Server Supermicro 6028U-TNR4T+/3Y
CPU Intel® Xeon® Processor E5-2640 v3
(8 cores/16 thread, 20MB cache, 2.6GHz (TB:3.4GHz)) x 2
Memory 64GB(2133MHｚ DDR4 SDRAM)
OS CentOS™ 7.3.1６11(kernel: 3.10.0-514.26.２.el7.x86_64)
SSD PX04PMB080
MariaDB 5.5.52
HarmaerDB 2.23
評価環境
TPC-C
- Warehouse: 3000
- Virtual user: 2, 4, 6, 8, 10, 20, 40, 60, 80, 100, 150, 200, 300, 400, 500
- Rump Time:30分, Run Time:15分

• 単にinnodb_buffer_pool_sizeだけ増やしても、TPC-C性能は向上
– Fdataaync:1.4～2.1倍
– O_DIRECT:1.3～2.4倍
• １～2GiB以上に増やしてもTPC-C性能は向上しない
innodb_buffer_pool_sizeだけ増やしたら？

• fdataasyncでinnodb_log_file_size以外の設定を変えた場合に10～15％の性能
向上する
• O_DIRECTでは、差が無い
I/O関係の設定だけ変えたら?

Case 1
Default
Case2
1GiB
Case3
1GiB-I/O
Case4
1GiB-I/O-Log
Case5
32GiB-I/O
Case6
32GiB-Log
Case7
32GiB-I/O-Log
innodb_buffer_pool_size 128MiB
(Default)
1GiB 1GiB 1GiB 32GiB 32GiB 32GiB
innodb_buffer_pool_instances 1
(Default)
1
(Default)
24 24 24 1
(Default)
24
innodb_read_threads 4
(Default)
4
(Default)
12 12 12 4
(Default)
12
innodb_read_threads 4
(Default)
4
(Default)
12 12 12 4
(Default)
12
read_buffer_size 128KiB
(Default)
128KiB
(Default)
1024KiB 1024KiB 1024KiB 128KiB
(Default)
1024KiB
Read_rnd_buffer_size 256KiB
(Default)
256KiB
(Default)
2048KiB 2048KiB 2048KiB 256KiB
(Default)
2048KiB
inno_db_io_capacity 2000
(Default)
2000
(Default)
100000 100000 100000 2000
(Default)
100000
innodb_flush_neighbor_pages area
(Default)
area
(Default)
None None None area
(Default)
None
innodb_log_file_size 5MiB
(Default)
5MiB
(Default)
5MiB
(Default)
512MiB 5MiB
(Default)
512MiB 512MiB
どれが効果があるの？
• 色々やってみました

• Page Cacheを使用するfdataasync, O_DIRECTともに傾向は変わらず
– innodb_buffer_pool_sizeとinnodb_log_file_sizeを増やさないとTPC-C性能は向
上しない
• まずは、innodb_buffer_pool_sizeとinnodb_log_file_sizeから
– O_DIRECTの場合、次にinnodb_read_threads, innodb_write_threads,
innodb_io_capacityをチューニング
• どこまで上げられるかは、使用するSSD次第
MariaDB TPC-C性能

• TPC-C性能を突き詰めていくためには、O_DIRECT！
– 特にVirtual Users数が増えた時の性能差が大きい(40％！)
• 障害時のデータ消失、Page CacheとDB内のMemory Poolのデータの2重Copyを避けるために
O_DIRECTを使用しているが、NVMe SSD性能を使い切るためにもO_DIRECT！
fdataasync VS O_DIRECT

• TPC-Cでは、Write比率が高く、TPC-C性能を向上するためにはWrite性能が大事
• 特にPage Cacheを使用しないO_DIRECTでは、Read要求を削減するため、
innodb_memory_pool_sizeを増やす必要がある
TPC-CではWrite性能が大事

• TPC-C性能とWrite量は比例しない。
– innodb_log_file_size，innodb_buffer_pool_sizeを変更して、不要な
Write要求を削減する必要がある。
• 不要なI/Oを削減後、innodb_max_iocapacity, innodb_read_threads,
innodb_write_threadsを変更しないと効果が少ない
Write性能が重要でも…

• Page Sizeを16KiB(Default)から4KiB, 8KiBに変えると
– Virtual User数150以下では、10～13％の性能向上
– Virtual User数200以上では、性能に大きな差は無い
• 4KiB Pageと8KiB Pageで性能差はない
Page Sizeを変えたら？

• はじめに
• まとめ

• SSDの性能向上により、使用状況によっては、 Page Cache, File Systemが要因でSSDの性
能を使い切れない。
– MariaDBのTPC-C評価でもOS要因の性能限界が見え始めている。
– TPC-C性能を向上させるために、以下が有効
• Page Cacheを使用しないO_DIRECTの使用
• NVMe SSDの高速性を生かすためには、やはりMemoryとMariaDBのチューニングが必要
– まずは、innodb_memory_buffer_poolとinnodb_log_file_sizeから
• これだけでも5,400～11,000KTPM(90～180KTPS)!
– TPC-C性能を向上するためには、SSDのWrite性能が大事！
• Random Write性能とSequential Write性能どちらも大事
– I/O量とTPC-C性能は相関しない
• 無駄なI/O削減が重要
• 高速なSSDを使用することで、TPC-C性能は向上
– 高速なSSDを使用しても無駄なI/Oを発行していたら、TPC-C性能は向上しない
• 無駄なI/Oを削減するチューニング、SQL/テーブル設計が大事
– 高速なSSD性能を使い切れるか、皆様の腕の見せ所！
まとめ

[db tech showcase Tokyo 2017] A27: ストレージ視点から見たMariaDB性能チューニング by 東芝メモリ株式会社佐藤修一

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [db tech showcase Tokyo 2017] A27: ストレージ視点から見たMariaDB性能チューニング by 東芝メモリ株式会社佐藤修一

Ähnlich wie [db tech showcase Tokyo 2017] A27: ストレージ視点から見たMariaDB性能チューニング by 東芝メモリ株式会社佐藤修一 (20)

Mehr von Insight Technology, Inc.

Mehr von Insight Technology, Inc. (20)