Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ストレージ視点から見た
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...
3© 2017 Toshiba Memory Corporation
• はじめに
• NVMe SSDの実力
• Linux OSの影響
• MariaDB(innodb)性能チューニング
• まとめ
4© 2017 Toshiba Memory Corporation
幅広いSSDラインナップで、多様なアプリケーションに対応します!
SSD製品の適用分野
ハイエンド
PC
ホームサーバ
データセンタ
監視カメラカムコーダ
航空機内
AVシス...
5© 2017 Toshiba Memory Corporation
東芝メモリSSDラインアップ
6© 2017 Toshiba Memory Corporation
Enterprise向けSSDの性能
0
500
1000
1500
2000
2500
3000
3500
4000
0 100 200 300
円形の面積:SSD容量
M...
7© 2017 Toshiba Memory Corporation
• はじめに
• NVMe SSDの実力
• Linux OSの影響
• MariaDB(innodb)性能チューニング
• まとめ
8© 2017 Toshiba Memory Corporation
• MySQL™をDefault Configurationのまま使用した場合のNVMe SSD のTPC™
TPC-C™性能は、NL HDD(8台 RAID1+0)の1.5...
9© 2017 Toshiba Memory Corporation
• MySQLのDefault ConfigurationでNVMe SSDを使用しても、
ConfigurationをチューニングしたNL HDD(8台 RAID1+0)の...
10© 2017 Toshiba Memory Corporation
• やっぱりNVMe SSDは、速い! Max 12MTPM(200KTPS)
• 注:
– NL HDDでもMax 1900KTPM(約31KTPS)
– 現行のNL H...
11© 2017 Toshiba Memory Corporation
• はじめに
• NVMe SSDの実力
• Linux OSの影響
• MariaDB(innodb)性能チューニング
• まとめ
12© 2017 Toshiba Memory Corporation
• Many Core CPU, RAID Controller同様にSSD内部でRead/Write要求を並列
処理することで性能を上げている。
• SSD性能を使い切る...
13© 2017 Toshiba Memory Corporation
• 以下のPage Cacheの機能から、小サイズのSequential Accessでは、Page Cacheを使用した方がI/O性能
が高い
– アプリケーションが4K...
14© 2017 Toshiba Memory Corporation
• 小サイズのRandom Accessの場合、Page Cacheの優位性がなくなる
– アプリケーションのアクセスサイズでストレージをアクセス
– 先読みの効果が少ない...
15© 2017 Toshiba Memory Corporation
• TraditionalなFile System(ext4, xfs)では、1Fileに対するI/O性能にFile Systemの排他制
御が原因と思われる性能限界がある...
16© 2017 Toshiba Memory Corporation
• 性能を突き詰めていくとPage Cahce, File Systemの影響を受ける
– innodb_flush_method: dsatasync(Default) ...
17© 2017 Toshiba Memory Corporation
• はじめに
• NVMe SSDの実力
• Linux OSの影響
• MariaDB(innodb)性能チューニング
• まとめ
18© 2017 Toshiba Memory Corporation
• 他にも試してみたので紹介させて頂きます
– Innodb_buffer_pool_sizeだけ増やしたら?
– I/O関係の設定だけ変更したら?
– どの設定を変更する...
19© 2017 Toshiba Memory Corporation
Model Name, Version
Server Supermicro 6028U-TNR4T+/3Y
CPU Intel® Xeon® Processor E5-26...
20© 2017 Toshiba Memory Corporation
• 単にinnodb_buffer_pool_sizeだけ増やしても、TPC-C性能は向上
– Fdataaync:1.4~2.1倍
– O_DIRECT:1.3~2.4倍...
21© 2017 Toshiba Memory Corporation
• fdataasyncでinnodb_log_file_size以外の設定を変えた場合に10~15%の性能
向上する
• O_DIRECTでは、差が無い
I/O関係の設定...
22© 2017 Toshiba Memory Corporation
Case 1
Default
Case2
1GiB
Case3
1GiB-I/O
Case4
1GiB-I/O-Log
Case5
32GiB-I/O
Case6
32Gi...
23© 2017 Toshiba Memory Corporation
• Page Cacheを使用するfdataasync, O_DIRECTともに傾向は変わらず
– innodb_buffer_pool_sizeとinnodb_log_f...
24© 2017 Toshiba Memory Corporation
• TPC-C性能を突き詰めていくためには、O_DIRECT!
– 特にVirtual Users数が増えた時の性能差が大きい(40%!)
• 障害時のデータ消失、Page...
25© 2017 Toshiba Memory Corporation
• TPC-Cでは、Write比率が高く、TPC-C性能を向上するためにはWrite性能が大事
• 特にPage Cacheを使用しないO_DIRECTでは、Read要求を...
26© 2017 Toshiba Memory Corporation
• TPC-C性能とWrite量は比例しない。
– innodb_log_file_size,innodb_buffer_pool_sizeを変更して、不要な
Write要...
27© 2017 Toshiba Memory Corporation
• Page Sizeを16KiB(Default)から4KiB, 8KiBに変えると
– Virtual User数150以下では、10~13%の性能向上
– Virtu...
28© 2017 Toshiba Memory Corporation
• はじめに
• NVMe SSDの実力
• Linux OSの影響
• MariaDB(innodb)性能チューニング
• まとめ
29© 2017 Toshiba Memory Corporation
• SSDの性能向上により、使用状況によっては、 Page Cache, File Systemが要因でSSDの性
能を使い切れない。
– MariaDBのTPC-C評価で...
30© 2017 Toshiba Memory Corporation
Upcoming SlideShare
Loading in …5
×

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

314 views

Published on

SSDは、年々高性能化と大容量化が進んでいる。特にNVMe SSDの登場により、使用条件によってはコンピュータシステムのボトルネックがストレージからOSやアプリケーションへ移行の動き。
本セクションでは、弊社NVMe SSDとMariaDBを用いて、高性能NVMe SSDの性能を有効活用するためのMariaDBのチューニングをストレージ視点で紹介する。

Published in: Technology
  • Be the first to comment

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

  1. 1. ストレージ視点から見た MariaDB性能チューニング db tech showcase 2017 Tokyo 2017年9月6日 16:30~17:20 東芝メモリ株式会社 SSD事業部 SSD応用技術部 SSD応用技術担当 主幹 佐藤 修一
  2. 2. 2© 2017 Toshiba Memory Corporation • はじめに • NVMeTM SSDの実力 • Linux OSの影響 • MariaDB™ (innodb)性能チューニング • まとめ Agenda ・PCIeはPCI-SIG社の商標です。 ・NVMeはNVM Express, Inc.の商標です。 ・その他本文中に記載されている会社名および製品名は、それぞれ各社が商標または登録商標として使用している場合があります。
  3. 3. 3© 2017 Toshiba Memory Corporation • はじめに • NVMe SSDの実力 • Linux OSの影響 • MariaDB(innodb)性能チューニング • まとめ
  4. 4. 4© 2017 Toshiba Memory Corporation 幅広いSSDラインナップで、多様なアプリケーションに対応します! SSD製品の適用分野 ハイエンド PC ホームサーバ データセンタ 監視カメラカムコーダ 航空機内 AVシステム 組み込み用 ストレージ POSシステム タブレット タブレット PC エンタープライズ サーバ/ストレージ Toshiba SSDTMC NAND Flashメモリ搭載 電子楽器 映像編集機器 医療計測器
  5. 5. 5© 2017 Toshiba Memory Corporation 東芝メモリSSDラインアップ
  6. 6. 6© 2017 Toshiba Memory Corporation 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
  7. 7. 7© 2017 Toshiba Memory Corporation • はじめに • NVMe SSDの実力 • Linux OSの影響 • MariaDB(innodb)性能チューニング • まとめ
  8. 8. 8© 2017 Toshiba Memory Corporation • MySQL™をDefault Configurationのまま使用した場合のNVMe SSD のTPC™ TPC-C™性能は、NL HDD(8台 RAID1+0)の1.5~3倍の性能 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
  9. 9. 9© 2017 Toshiba Memory Corporation • 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(PX04PMB080) vs NL HDD(MG05ACA800E )8台 RAID1+0
  10. 10. 10© 2017 Toshiba Memory Corporation • やっぱり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 NVMe SSD(PX04PMB080) vs NL HDD(MG05ACA800E )8台 RAID1+0
  11. 11. 11© 2017 Toshiba Memory Corporation • はじめに • NVMe SSDの実力 • Linux OSの影響 • MariaDB(innodb)性能チューニング • まとめ
  12. 12. 12© 2017 Toshiba Memory Corporation • 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が速くなって・・・
  13. 13. 13© 2017 Toshiba Memory Corporation • 以下の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)
  14. 14. 14© 2017 Toshiba Memory Corporation • 小サイズのRandom Accessの場合、Page Cacheの優位性がなくなる – アプリケーションのアクセスサイズでストレージをアクセス – 先読みの効果が少ない • FIO同様にlibaioを使用するなどし、アプリケーションが同時Read/Write要求数を4以上にで きれば、O_DIRECTを使用した方がSSD性能を生かせる Page Cache VS O_DIRECT(Random Read/Write) 1
  15. 15. 15© 2017 Toshiba Memory Corporation • TraditionalなFile System(ext4, xfs)では、1Fileに対する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)
  16. 16. 16© 2017 Toshiba Memory Corporation • 性能を突き詰めていくと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性能に対する影響は?
  17. 17. 17© 2017 Toshiba Memory Corporation • はじめに • NVMe SSDの実力 • Linux OSの影響 • MariaDB(innodb)性能チューニング • まとめ
  18. 18. 18© 2017 Toshiba Memory Corporation • 他にも試してみたので紹介させて頂きます – Innodb_buffer_pool_sizeだけ増やしたら? – I/O関係の設定だけ変更したら? – どの設定を変更するのが、一番効果があるの? MariaDB™(InnoDB)性能チューニング
  19. 19. 19© 2017 Toshiba Memory Corporation 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(2133MHz DDR4 SDRAM) OS CentOS™ 7.3.1611(kernel: 3.10.0-514.26.2.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分
  20. 20. 20© 2017 Toshiba Memory Corporation • 単にinnodb_buffer_pool_sizeだけ増やしても、TPC-C性能は向上 – Fdataaync:1.4~2.1倍 – O_DIRECT:1.3~2.4倍 • 1~2GiB以上に増やしてもTPC-C性能は向上しない innodb_buffer_pool_sizeだけ増やしたら?
  21. 21. 21© 2017 Toshiba Memory Corporation • fdataasyncでinnodb_log_file_size以外の設定を変えた場合に10~15%の性能 向上する • O_DIRECTでは、差が無い I/O関係の設定だけ変えたら?
  22. 22. 22© 2017 Toshiba Memory Corporation 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 どれが効果があるの? • 色々やってみました
  23. 23. 23© 2017 Toshiba Memory Corporation • 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性能
  24. 24. 24© 2017 Toshiba Memory Corporation • TPC-C性能を突き詰めていくためには、O_DIRECT! – 特にVirtual Users数が増えた時の性能差が大きい(40%!) • 障害時のデータ消失、Page CacheとDB内のMemory Poolのデータの2重Copyを避けるために O_DIRECTを使用しているが、NVMe SSD性能を使い切るためにもO_DIRECT! fdataasync VS O_DIRECT
  25. 25. 25© 2017 Toshiba Memory Corporation • TPC-Cでは、Write比率が高く、TPC-C性能を向上するためにはWrite性能が大事 • 特にPage Cacheを使用しないO_DIRECTでは、Read要求を削減するため、 innodb_memory_pool_sizeを増やす必要がある TPC-CではWrite性能が大事
  26. 26. 26© 2017 Toshiba Memory Corporation • TPC-C性能とWrite量は比例しない。 – innodb_log_file_size,innodb_buffer_pool_sizeを変更して、不要な Write要求を削減する必要がある。 • 不要なI/Oを削減後、innodb_max_iocapacity, innodb_read_threads, innodb_write_threadsを変更しないと効果が少ない Write性能が重要でも…
  27. 27. 27© 2017 Toshiba Memory Corporation • Page Sizeを16KiB(Default)から4KiB, 8KiBに変えると – Virtual User数150以下では、10~13%の性能向上 – Virtual User数200以上では、性能に大きな差は無い • 4KiB Pageと8KiB Pageで性能差はない Page Sizeを変えたら?
  28. 28. 28© 2017 Toshiba Memory Corporation • はじめに • NVMe SSDの実力 • Linux OSの影響 • MariaDB(innodb)性能チューニング • まとめ
  29. 29. 29© 2017 Toshiba Memory Corporation • 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性能を使い切れるか、皆様の腕の見せ所! まとめ
  30. 30. 30© 2017 Toshiba Memory Corporation

×