iomemoryとatomic writeによるデータベース高速化

1

2015/10/29

神楽坂Tech Talk～データベース高速化 #1

〜ioMemoryとAtomic Writeによるデータベース高速化〜

株式会社インターネットイニシアティブ

正原竜太

2

自己紹介

• 氏名

– 正原竜太

• 所属

– 株式会社インターネットイニシアティブ

• 職種

– インフラエンジニア？データベースエンジニア？

• 仕事

– IIJでクラウドデータベースサービスの運用・開発をしてます • Oracle, MySQL, SQLServer

元々ネットワークエンジニアの若輩者なので

あまりイジメないで下さいね

3

突然ですが

4

皆様データベースの高速化って

言われると何を思い浮かべますか？

5

ざっくり考えてみた

6

データベースの高速化とは

1. ハードウェアの高速化

– CPU、メモリ、ストレージ

– 最も簡単かつ確実でパフォーマンスは高いがコストも高い

一番簡単だけど、ボトルネックをちゃんと特定しないと

せっかくのハードウェアが効果を発揮できずに

「高いお金を払ってるのにどういうことだ！？」という状況もあるので注意が必要ね

7





2. OSやファイルシステムのチューニング

– リソースの割り当て、スワップ等

– 使用するファイルシステムの選択やオプション

ここからはお金がなくてもできるわね。

地味で直接的な効果が得られるか難しいけど、

逆に言うと皆あまり明確な答えを持っていない

部分じゃないかしら

8








3. データベースの設定

– リソースの割り当て

– 機能の有効化無効化

ここまでのチューニングを頑張っても

台無しにならないようにここもしっかりしておくべきね。

ハードウェアの性能をしっかり出すために

重要なところだと思うわ。

9









– リソースの割り当て


4. SQLのチューニング

– 実行計画

– インデックススキャンかフルスキャンか

高レベルなDBエンジニアになると

「DBの声が聞こえる」そうよ

10

今回は

11



– ストレージ • ioMemory

• ioDrive2

• SSD


– 使用するファイルシステムの選択やオプション • NVMFS

• XFS

• ext4



• アトミックライト

• ダブルライト

• スキップダブルライト

それぞれ比較してみました！

12

目次

• ioMemoryによるデータベースの高速化

– ioMemory自体はどんぐらい速いの？

• アトミックライトと書き込み原子性

– そもそもアトミックライトって何？何が良いの？

• その他の書き込み原子性

– アトミックライトの代わりの方法ってないの？

• ユニットサイズの違いによる性能の違い

– ioMemoryってセクターサイズ変えられるけど性能に影響する？

13

目次





14

ioMemoryって速い速いって噂だけど・・・実際どんだけ速いの？

15

ioDrive2やSSDと比較してみました！

16

検証に用いたサーバー

• CPU

– Intel® Xeon® CPU E5-2620 v2 @ 2.10GHz 6コア12スレッド*2

• メモリ

– 96GB

• ストレージ

– ioMemory: PX600-2600

• 容量: 2600GB

• Read帯域幅: 2.7GB/s

• Write帯域幅: 2.2GB/s

• Random Read IOPS (4K): 350,000

• Random Write IOPS (4K): 385,000

今回はioMemoryシリーズの

パーフォマンス重視型の2.6TB

容量であるPX600-2600を

使いました

(＊) こちらはioMemoryを搭載したサーバーのスペックになります。

ioDrive2やSSDを搭載したサーバーとは残念ながら異なるスペックとなります。

そのため、正確な比較とは言えず、あくまで参考値と形になります。

17

データベース性能比較条件

• RDBMS

– Percona 5.6.22

• 今回の検証は全てPerconaを利用しますが表記上MySQLと多々記述しています

• データベース条件

– バッファプール: 10GB

– バイナリログ: 同期

• ベンチマークツール

– tpcc-mysql

• WareHouse: 1000 (データサイズは約100GB)

• コネクション数: 64

バッファキャッシュにデータが乗らない状態で

キャッシュアウトとキャッシュインによる

IOが発生する状態を想定してのテストを

想定しているそうよ

18

結果

19

各ストレージを用いた際のデータベースの性能差

SSD ioDrive2 ioMemory

TpmC 11190 30942 36768

0

5000

10000

15000

20000

25000

30000

35000

40000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]

20



TpmC 11190 30942 36768

0

5000

10000

15000

20000

25000

30000

35000

40000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]

ioDrive2でも30000[Tpmc]を超えていたが、

相対的にはioMemoryの方が1.2倍ぐらい高かった。

21



TpmC 11190 30942 36768

0

5000

10000

15000

20000

25000

30000

35000

40000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]

一方、SSDも10,000[TpmC]を上回りはしたが、

ioMemoryとSSDは相対的に約3.4倍ほどの差があった。

これならサーバーの集約も可能でクラウド事業者泣かせ？

22

目次





23

これまでのMySQL（ダブルライトバッファ）

• MySQLのページサイズはデフォルトで16KB

• 多くのファイルシステムのブロックサイズはデフォルトで4KB

• ブロックに書き込み中に電源障害等が発生すると・・・

ページ

4KB 4KB 4KB 4KB データ領域

MySQLのデータの最小論理ユニット

ファイルシステムのデータの最小ユニット

4KB 4KB 4KB 4KB

電源障害等

4KB 4KB 4KB 4KB

4KB 4KB 4KB 4KB

データとして不整合かつリカバリ不可

メモリ

ストレージ

これを未然に防ぐアーキテクチャをダブルライトバッファという

以降、ダブルライトをオフにした状態をスキップダブルライトと呼称

24


• ダブルライトバッファによる原子性の保障

– MySQLではこの電源障害等によるデータの不整合をダブルライトバッファを用いた2回書き込みにより回避している。

ページ

4KB 4KB 4KB 4KB ダブルライト

バッファ

4KB 4KB 4KB 4KB 4KB 4KB 4KB 4KB


メモリ

ストレージ

4KB 4KB 4KB 4KB

4KB 4KB 4KB 4KB

通常時

性能を考慮してダブルライトバッファはシーケンシャルライト

25




ページ


バッファ

4KB 4KB 4KB 4KB 電源障害等

4KB 4KB 4KB 4KB


メモリ

ストレージ

ダブルライトバッファへ書き込み中に障害が発生した場合

4KB 4KB 4KB 4KB

4KB 4KB 4KB 4KB

チェックサムで異常を検知して

書き込み途中の不完全なデータを破棄

26




ページ


バッファ

4KB 4KB 4KB 4KB 電源障害等

4KB 4KB 4KB 4KB


メモリ

ストレージ

データ領域へ書き込み中に障害が発生した場合

4KB 4KB 4KB 4KB

4KB 4KB 4KB 4KB

ダブルライトバッファから書き込み予定だった

データを実データ領域へ書き込みリカバリ

27

これからのMySQL（というかアトミックライトの場合）

• アトミックライトによる原子性の保障

– SDKが提供するAPIを利用することにより、カーネルドライバおよびハードウェアにより複数ブロックへの書き込みにおいて「1ブロックも書いていない」 or 「全ブロック書いた」という原子性が保障されるようになった。これがダブルライトの代替となる機能である。

ページ


MySQLのデータの最小ユニット

ファイルシステムのデータの最小ユニット

4KB 4KB 4KB 4KB

4KB 4KB 4KB 4KB

4KB 4KB 4KB 4KB

メモリ

ストレージ

「1ブロックも書いていない」もしくは「全ブロック書いた」

というステートしか存在しない！！！

ダブルライトバッファに書き込まない分

オーバーヘッドが少ない！！！

28

これって凄くないですか？

凄いよね？凄いよね！？

29

実際に使ってみたい！

30

導入も簡単！（デバイスのセットアップ）

• サンディスク様より必要なRPMをダウンロードしインストール

• フォーマットのためデバイスをデタッチ

• アトミックライト有効のオプションを加えてデバイスをフォーマット

[root@dev ~]# rpm -ivh nvmfs-2.6.32-431.el6.x86_64-1.0.56-1.el6.x86_64.rpm

Preparing... ########################################### [100%]

1:nvmfs-2.6.32-431.el6.x8########################################### [100%]

[root@dev ~]# fio-detach /dev/fct0

Detaching: [====================] (100%) |

fioa - detached.

[root@dev ~]# fio-format -APye -b 512 /dev/fct0

/dev/fct0: Creating block device.

Block device of size 2600.00GBytes (2421.44GiBytes).

Using block (sector) size of 512 bytes.

WARNING: Do not interrupt the formatting! If interrupted, the fio-sure-erase utility may

help recover from format errors. Please see documentation or contact support.

Formatting: [====================] (100%) |

/dev/fct0 - format successful.

31

導入も簡単！（ファイルシステムのセットアップ）

• デタッチしたデバイスをアタッチ

• ファイルシステムを作成してマウント

[root@dev ~]# mkfs.nvmfs /dev/fioa

Creating new NVMFS filesystem

mkfs version = 1.0.2

block device = /dev/fioa

control device = /dev/fct0

filesystem media version = 1039

filesystem uuid = aca53509-98bd-4430-a2a0-aebaa29b40a3

filesystem creation time = 2015-05-27 16:20:34.997775163 +0900

device sector size = 512

filesystem block size = 512

inode block size = 512

metadata block size = 4096

physical filesystem blocks = 5078125000 (2421 GiB)

virtual filesystem blocks = 0-281474976710655 (134217728 GiB)

filesystem features = metadata checksums

mkfs done!

[root@dev ~]# mount -t nvmfs -o noatime /dev/fioa /data

[root@dev ~]# mount | grep fioa

/dev/fioa on /data type nvmfs (rw,noatime)

[root@dev ~]# fio-attach /dev/fct0

Attaching: [====================] (100%) ¥

fioa - attached.

32

導入も簡単！（DBのセットアップ）

• ダブルライトまたはスキップダブルライトと同じようにmy.cnfを編集

• mysql_install_dbまたは退避していたデータをリストア

• いつものようにデータベースを起動

• ログファイルからスタートアップメッセージを確認

[mysqld]

#skip-innodb_doublewrite

innodb_doublewrite

[mysqld]

#skip-innodb_doublewrite

#innodb_doublewrite

innodb_use_atomic_writes

[root@dev ~]# mysql_install_db --user=mysql --defaults-file=/etc/my.cnf

[root@dev ~]# /etc/init.d/mysql start

Starting MySQL (Percona Server).. SUCCESS!

2015-05-27 16:47:00 3927 [Note] Plugin 'FEDERATED' is disabled.

2015-05-27 16:47:00 3927 [Note] InnoDB: using atomic writes.

2015-05-27 16:47:00 3927 [Note] InnoDB: switching off doublewrite buffer because of atomic writes.

2015-05-27 16:47:00 3927 [Note] InnoDB: Using atomics to ref count buffer pool pages

2015-05-27 16:47:00 3927 [Note] InnoDB: The InnoDB memory heap is disabled

33

以上！

やったね！

もうバッチリ！

34

アトミックライトのポイント

• アトミックライトにはNVMFSが必要

– むしろMySQL側は特別なことをしていない

– my.cnfの設定するとIOCTLでの確認とダブルライトのオフするだけ

• ちなみに、Percona 5.5.31だとチェックが甘いという罠も・・・

– アトミックライトはRDBMS的にはNVMFS上でのスキップダブルライト

• 書き込みの原子性を保証するレイヤーが異なる

– ダブルライトバッファ • RDBMS (MySQL, Percona, MariaDB)

– アトミックライト • カーネルドライバ

• ハードウェア（ioMemory）

• なぜファイルシステムなのか？

– （恐らく）アプリケーションに修正が不要で使い易いから

ふ～ん、へ～

35

じゃあ性能の方はどうなんよ？

36

ダブルライト・スキップダブルライト・アトミックライトの性能差

double write skip double write atomic write

TpmC 36768 39354 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]

37


TpmC 36768 39354 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

] ダブルライト・スキップダブルライト・アトミックライトの性能差

スキップダブルライトはNVMFS上で使うとアトミックライトと

同じになってしまうためダブルライトおよびスキップダブルライトを

計測する際のファイルシステムはXFSを用いた

38


TpmC 36768 39354 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC


思ったほどダブルライトとスキップダブルライトで大きな差は

見られなかった。相対的には6%ほど性能が違った。

（今回ダブルライト中心にチューニングとかした為？）ちなみに、最初にSSDとの比較で出てきたのはダブルライトの値

39


TpmC 36768 39354 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC


一方、スキップダブルライトとアトミックライトでは思ってた以上に

差が出た。相対的には約17%ほどの性能差が見れた。

RDBMSとしてやってることは同じなハズなのでこの差は

XFSとNVMFSというファイルシステムによる差？

40

目次





41

ここまででもアトミックライト（NVMFS）の

良さが伝わったかと思います

大勝利よ！

もう他のファイルシステムなんていらないわ！（過激）

42

でもちょっと待った！

やっぱり言い過ぎたわ

そんなことないわ

他のファイルシステムも凄いわ

43

書き込み原子性を保証してくれるファイルシステム

• 他にもあるよ！書き込み原子性を保証してくれるファイルシステム

– ZFS

– btrfs

– extX （ジャーナリングストラテジーの journal モード） • mount -o data=journal /dev/fioa /mnt

– …etc…

• 結局のところ、やはりどのレイヤーで保証するか次第

– ハードウェア & カーネルドライバ • NVMFS

– ファイルシステム

• ZFS, btrfs, extX, …etc…

– アプリケーション（RDBMS） • ダブルライト

• ちなみに

– ダブルライトかファイルシステムのどちらが良いかの

検証はPerconaの公式ページで記事が公開されています

話者は何番煎じでしょうね～

44

代表としてXFSやext4と比較してみる

ext4はmountコマンドで設定できて

楽だからという理由らしいわ。

XFSはそれ以前の検証で使っていたから。

怠慢ね、怠慢。

45

ちょっとその前に、、、ジャーナリングストラテジーって？

• Write Back

– データおよびメタデータの順序関係なくメタデータのみジャーナリング（データ破損可能性あり）

• Ordered

– データを書き込んでからメタデータを書き込むがジャーナリングはメタデータのみ（データ損失可能性あり）

• Journal

– メタデータおよびデータをジャーナリング（データ破損可能性ほぼなし）

Journalモードじゃないとダメなのね。

XFSはWrite Backのみらしいから

書き込み原子性を保証したいのなら

ダブルライトを使うしかないわね。

46

結果

47

書き込み原子性の保証方法の違いによる性能差

XFS ext4-writeback ext4-journal XFS ext4-writeback ext4-journal nvmfs


TpmC 36768 35375.301 16905.199 39354 36768.199 23283.4 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]

48



TpmC 36768 35375.301 16905.199 39354 36768.199 23283.4 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

] 書き込み原子性の保証方法の違いによる性能差

ジャーナリングストラテジーが同じ場合はXFSもext4も大きくは変わらないが

ダブルライトおよびスキップダブルライトのどちらにおいてもXFSの方が

若干高い性能を示した。ライトバックで良いならXFSを使うべき？

49



TpmC 36768 35375.301 16905.199 39354 36768.199 23283.4 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC


同じext4でもストラテジーによって性能は大きく違った。

そもそもダブルライトかつext4をジャーナルモードで使った場合は

異なるレイヤーで2回ずつ、計4回同じデータを書くことになる

50

ちなみに書き込み原子性が保証される

組み合わせだけ残すと・・・

51

書き込み原子性の保証方法の違いによる性能差



TpmC 36768 35375.301 16905.199 39354 36768.199 23283.4 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]

52



TpmC 36768 35375.301 16905.199 39354 36768.199 23283.4 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC


以下のどれかに該当するもの

・ダブルライトを使用

・ ext4でジャーナルモード

・アトミックライトを使用

53



TpmC 36768 35375.301 16905.199 39354 36768.199 23283.4 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC


スキップダブルライトの性能と

ダブルライトの安全性を持つ

アトミックライトが一番でした

54



TpmC 36768 35375.301 16905.199 39354 36768.199 23283.4 45844.5

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC


アトミックライトが使えない場合は

XFS上でのダブルライトが一番高性能でした

55

！！！注意！！！

56

実は・・・

• 今回の検証ではXFS上でダブルライトが一番高性能でしたが、設定や環境によってはext4上でスキップダブルライトの方が良い可能性があります。。。

– 以前の検証で同様の比較を行ったときはext4上でスキップダブルライトの方が良かった

– 前述したPerconaの公式ページにある記事でもext4上でスキップダブルライトの方が良かった

• 大変申し訳ないのですが断言するのは難しいです・・・

– m(_ _)m

はっきりしないわね・・・

57

なら漢は黙ってアトミックライト（NVMFS）だ！

• ただNVMFSはまだまだ開発途中？

– 最低限必要な機能はあるが、一部足りない機能も存在する

• touch /mnt/hoge.txtとかすると・・・

• 新しいファイルシステムゆえ稼働実績が少ない

– やはり実績の少ないファイルシステムの導入にはハードルがある

– 特にデータベースということを考えるとさらにハードルが上がる

– このような場を通じて皆様にもNVMFSの血肉に・・・

他人任せもここまで来ると

むしろ清々しいわ・・・

もちろんこれからのSanDisk様に期待しています！

58

目次





59

ユニットサイズを変更してみる

• 各レイヤーにおけるユニットサイズが変更可能

– ボリュームのセクターサイズ

– ファイルシステムのブロックサイズ

– MySQLのメモリのページサイズ

512B

MySQL

ページサイズ

ファイルシステム

ブロックサイズ

ストレージ


（セクターサイズ）

4KB

16KB

…

…

4KB

4KB

4KB

上から下まで全ユニットサイズを通常左のような構成から

右のような構成にしたら？？？

IOPSが同じであればやっぱ

512Bより4KBの方が効率的では

ないかという淡い期待（希望）を

捨てれませんでした！

60

試してみた！

61

ダブルライトの場合

62

ユニットサイズ毎の性能差（ダブルライト）

4KB 16KB 4KB 16KB 4KB 16KB 4KB 16KB 4KB 16KB 4KB 16KB 4KB 16KB

512B 4KB 4KB 4KB 4KB 4KB 4KB

512B 4KB 512B 4KB 512B 4KB

XFS ext4-writeback ext4-journal

TpmC 51659 40484 47150 36768 47293 37267 44104 35375 44406 35649 25433 16828 25784 16493

0

10000

20000

30000

40000

50000

60000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]

セクターサイズ



ページサイズ

63




512B 4KB 512B 4KB 512B 4KB


TpmC 51659 40484 47150 36768 47293 37267 44104 35375 44406 35649 25433 16828 25784 16493

0

10000

20000

30000

40000

50000

60000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]




ページサイズ

棒グラフの本数に差異があるのはext4はブロックサイズの指定が

限定的で512Bは選択できなかったため（1KB, 2KB, 4KBのみ指定可能）

64




512B 4KB 512B 4KB 512B 4KB


TpmC 51659 40484 47150 36768 47293 37267 44104 35375 44406 35649 25433 16828 25784 16493

0

10000

20000

30000

40000

50000

60000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]




ページサイズ

ページサイズ4KBのみの場合

ファイルシステムによる違いは見られたが

残念ながらセクターサイズやブロックサイズの

違いによる性能差は見られない

65




512B 4KB 512B 4KB 512B 4KB


TpmC 51659 40484 47150 36768 47293 37267 44104 35375 44406 35649 25433 16828 25784 16493

0

10000

20000

30000

40000

50000

60000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]




ページサイズ

ページサイズ16KBのみの場合

4KBほどではないがやはりセクターサイズや

ブロックサイズよりファイルシステムの違いの

方が性能差が大きい（本当に微々たるレベル）

66




512B 4KB 512B 4KB 512B 4KB


TpmC 51659 40484 47150 36768 47293 37267 44104 35375 44406 35649 25433 16828 25784 16493

0

10000

20000

30000

40000

50000

60000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]




ページサイズ

最も影響のあるユニットサイズはページサイズ！

（青は4KB、赤茶は16KB）

67

スキップダブルライトの場合

68

ユニットサイズ毎の性能差（スキップダブルライト）



512B 4KB 512B 4KB 512B 4KB


TpmC 54728 46910 46731 39354 46997 39386 43633 36768 43892 37616 30357 23283 30943 23492

0

10000

20000

30000

40000

50000

60000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]




ページサイズ

（当たり前かもしれないけど）ダブルライトと同様に

最も影響のあるユニットサイズはページサイズ！

（青は4KB、赤茶は16KB）

69

アトミックライトの場合

70

ユニットサイズ毎の性能差（アトミックライト）

4KB 16KB 4KB 16KB

512KB 4KB

512KB 4KB

NVMFS

TpmC 51767 44505 52408 45844

0

10000

20000

30000

40000

50000

60000

Tran

sact

ion

Pe

r M

inu

tes

[Tp

mC

]




ページサイズ

アトミックライト（NVMFS）においても最も性能に影響を及ぼすのは

セクターサイズ等ではなくDBのページサイズであった

71

ユニットサイズの違いに対する性能差の考察

72

ユニットサイズの違いに対する性能差の考察

• この検証で最も性能差に影響するのはDBのページサイズであった

– ダブルライト、スキップダブルライト、アトミックライトの全てで4KBが高性能

– やっぱりtpcc-mysqlにおいてはユニットサイズが小さい方が有利？

• ただし・・・

– 以前の検証では16KBの方が良かった

– tpcc-mysql以外でデータがデカいと変わってくるかも？

• 結論として

– 以前の検証と共通して言えることはユニットサイズではDBのページサイズが最も性能に影響するということ

• データベースというソフトウェア上の性能の話だから当然かも

73

まとめ

74

データベースの高速化（ioMemoryとアトミックライト）まとめ


– ioMemoryに替えるだけで約370,000[TpmC]

– ioDrive2と比較して1.2倍、SSDと比較して3.4倍の性能


– アトミックライトは書き込みにおいて「全部」か「ゼロ」のどちらかを保証

– 導入も楽々

– スキップダブルライトの性能にダブルライトの安全性


– NVMFSだけでなくext4やZFS、btrfsでも同様のことが可能


– ベンチマークによる性能評価にて最も影響を与えたのはページサイズ

ありがとうございました

75

ご清聴ありがとうございました

お問い合わせ先 IIJインフォメーションセンター

TEL：03-5205-4466 （9：30～17：30 土/日/祝日除く） [email protected]

http://www.iij.ad.jp/

iomemoryとatomic writeによるデータベース高速化

Technology