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

1
2015/10/29
神楽坂Tech Talk～データベース高速化 #1
〜ioMemoryとAtomic Writeによるデータベース高速化〜
株式会社インターネットイニシアティブ
正原竜太

2
自己紹介
• 氏名
– 正原竜太
• 所属
– 株式会社インターネットイニシアティブ
• 職種
– インフラエンジニア？データベースエンジニア？
• 仕事
– IIJでクラウドデータベースサービスの運用・開発をしてます
• Oracle, MySQL, SQLServer
元々ネットワークエンジニアの若輩者なので
あまりイジメないで下さいね

4
皆様データベースの高速化って
言われると何を思い浮かべますか？

6
データベースの高速化とは
1. ハードウェアの高速化
– CPU、メモリ、ストレージ
– 最も簡単かつ確実でパフォーマンスは高いがコストも高い
一番簡単だけど、ボトルネックをちゃんと特定しないと
せっかくのハードウェアが効果を発揮できずに
「高いお金を払ってるのにどういうことだ！？」
という状況もあるので注意が必要ね

7
2. OSやファイルシステムのチューニング
– リソースの割り当て、スワップ等
– 使用するファイルシステムの選択やオプション
ここからはお金がなくてもできるわね。
地味で直接的な効果が得られるか難しいけど、
逆に言うと皆あまり明確な答えを持っていない
部分じゃないかしら

8
3. データベースの設定
– リソースの割り当て
– 機能の有効化無効化
ここまでのチューニングを頑張っても
台無しにならないようにここもしっかりしておくべきね。
ハードウェアの性能をしっかり出すために
重要なところだと思うわ。

9
– リソースの割り当て
4. SQLのチューニング
– 実行計画
– インデックススキャンかフルスキャンか
高レベルなDBエンジニアになると
「DBの声が聞こえる」そうよ

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が発生する状態を想定してのテストを
想定しているそうよ

19
各ストレージを用いた際のデータベースの性能差
SSD ioDrive2 ioMemory
TpmC 11190 30942 36768
0
5000
10000
15000
20000
25000
30000
35000
40000
TransactionPerMinutes[TpmC]

20
TpmC 11190 30942 36768
0
5000
10000
15000
20000
25000
30000
35000
40000
ioDrive2でも30000[Tpmc]を超えていたが、
相対的にはioMemoryの方が1.2倍ぐらい高かった。

21
TpmC 11190 30942 36768
0
5000
10000
15000
20000
25000
30000
35000
40000
一方、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

37
TpmC 36768 39354 45844.5
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
50000
TransactionPerMinutes[TpmC]ダブルライト・スキップダブルライト・アトミックライトの性能差
スキップダブルライトはNVMFS上で使うとアトミックライトと
同じになってしまうためダブルライトおよびスキップダブルライトを
計測する際のファイルシステムはXFSを用いた

38
TpmC 36768 39354 45844.5
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
50000
思ったほどダブルライトとスキップダブルライトで大きな差は
見られなかった。相対的には6%ほど性能が違った。
（今回ダブルライト中心にチューニングとかした為？）
ちなみに、最初にSSDとの比較で出てきたのはダブルライトの値

39
TpmC 36768 39354 45844.5
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
50000
一方、スキップダブルライトとアトミックライトでは思ってた以上に
差が出た。相対的には約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のみらしいから
書き込み原子性を保証したいのなら
ダブルライトを使うしかないわね。

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

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
TransactionPerMinutes[TpmC]書き込み原子性の保証方法の違いによる性能差
ジャーナリングストラテジーが同じ場合は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
同じ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

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
以下のどれかに該当するもの
・ダブルライトを使用
・ 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
スキップダブルライトの性能と
ダブルライトの安全性を持つ
アトミックライトが一番でした

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
アトミックライトが使えない場合は
XFS上でのダブルライトが一番高性能でした

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の方が効率的では
ないかという淡い期待（希望）を
捨てれませんでした！

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
セクターサイズ
ページサイズ

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
ページサイズ
棒グラフの本数に差異があるのは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
ページサイズ
ページサイズ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
ページサイズ
ページサイズ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
ページサイズ
最も影響のあるユニットサイズはページサイズ！
（青は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
ページサイズ
（当たり前かもしれないけど）ダブルライトと同様に
最も影響のあるユニットサイズはページサイズ！
（青は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
ページサイズ
アトミックライト（NVMFS）においても最も性能に影響を及ぼすのは
セクターサイズ等ではなくDBのページサイズであった

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

72
ユニットサイズの違いに対する性能差の考察
• この検証で最も性能差に影響するのはDBのページサイズであった
– ダブルライト、スキップダブルライト、アトミックライトの全てで4KBが高性能
– やっぱりtpcc-mysqlにおいてはユニットサイズが小さい方が有利？
• ただし・・・
– 以前の検証では16KBの方が良かった
– tpcc-mysql以外でデータがデカいと変わってくるかも？
• 結論として
– 以前の検証と共通して言えることはユニットサイズではDBのページサイズ
が最も性能に影響するということ
• データベースというソフトウェア上の性能の話だから当然かも

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 土/日/祝日除く）
info@iij.ad.jp
http://www.iij.ad.jp/

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

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

Similaire à ioMemoryとAtomic Writeによるデータベース高速化 (20)

Plus de IIJ

Plus de IIJ (20)

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