使ってみた！ioMemoryで実現する噂のAtomic write！

1
2015/06/10
使ってみた！ioMemoryで実現する噂のAtomic Write！
株式会社インターネットイニシアティブ
正原竜太

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

3
今回のお話の経緯
• 2013年6月、それまでしょっぱいSSDぐらいにしか縁のなかった新社会
人がioDriveなるものを知り、実際に使用してみてその性能に驚く
担当者曰く、「フラッシュメモリの味を占めたら
後には引き返せない」そうなの

4
• 2013年?月、ioDriveについてさらに調べていくにつれ、OpenNVMや
アトミックライトの存在を知ったが、当時の弊社環境では利用できず、
ひっそり枕を濡らす
パッケージが足りなかったんですね

5
• 2013年?月、ioDriveについてさらに調べていくにつれ、OpenNVMや
アトミックライトの存在を知ったが、当時の弊社環境では利用できず、
ひっそり枕を濡らす
• 2014年12月、ioMemory3の検証と共に弊社でもアトミックライト等の
OpenNVM技術が検証可能に！
早速導入検証してみましょう！

6
目次
1. MySQLにおける書き込み原子性とアトミックライト
2. アトミックライトを使ってみる
3. アトミックライトの有無による性能の違い
4. その他の書き込み原子性
5. まとめ

7
MySQLの書き込みにおける原子性
• MySQLのページサイズはデフォルトで16KB
• 多くのファイルシステムのブロックサイズはデフォルトで4KB
• ブロックに書き込み中に電源障害等が発生すると・・・
ページ
4KB 4KB 4KB 4KBデータ領域
MySQLのデータの最小ユニット
ファイルシステムのデータの最小ユニット
4KB 4KB 4KB 4KB
電源障害等
4KB 4KB 4KB 4KB
4KB 4KB 4KB 4KB
データとして不整合かつリカバリ不可
メモリ
ストレージ
これを未然に防ぐアーキテクチャがダブルライトバッファ

8
• ダブルライトバッファによる原子性の保障
– MySQLではこの電源障害等によるデータの不整合をダブルライトバッファ
を用いた2回書き込みにより回避している。
ページ
4KB 4KB 4KB 4KBダブルライト
バッファ
4KB 4KB 4KB 4KB
電源障害等
4KB 4KB 4KB 4KB
メモリ
ストレージ
ダブルライトバッファへ書き込み中に障害が発生した場合
4KB 4KB 4KB 4KB
4KB 4KB 4KB 4KB
チェックサムで異常を検知して
書き込み途中の不完全なデータを破棄

9
• ダブルライトバッファによる原子性の保障
– MySQLではこの電源障害等によるデータの不整合をダブルライトバッファ
を用いた2回書き込みにより回避している。
ページ
4KB 4KB 4KB 4KBダブルライト
バッファ
4KB 4KB 4KB 4KB
電源障害等
4KB 4KB 4KB 4KB
メモリ
ストレージ
データ領域へ書き込み中に障害が発生した場合
4KB 4KB 4KB 4KB
4KB 4KB 4KB 4KB
ダブルライトバッファから書き込み予定だった
データを実データ領域へ書き込みリカバリ

10
• アトミックライトによる原子性の保障
– SDKが提供するAPIを利用することにより、カーネルドライバおよびハード
ウェアにより複数ブロックへの書き込みにおいて「1ブロックも書いていな
い」 or 「全ブロック書いた」という原子性が保障されるようになった。これが
ダブルライトの代替となる機能である。
ページ
MySQLのデータの最小ユニット
ファイルシステムのデータの最小ユニット
4KB 4KB 4KB 4KB
4KB 4KB 4KB 4KB
4KB 4KB 4KB 4KB
メモリ
ストレージ
「1ブロックも書いていない」
もしくは「全ブロック書いた」
というステートしか存在しない！！！
ダブルライトバッファに書き込まない分
オーバーヘッドが少ない！！！

11
理論上、書き込み量が半分になるってこと！？
これを使わない手はない！

12
目次
5. まとめ

13
検証環境
• サーバ：PRIMERGY RX200 S8
– CPU：Intel® Xeon® CPU E5-2620 v2 @ 2.10GHz 6コア12スレッド*2
– メモリ：96GB
– ストレージ：ioMemory PX600
• OS
– Linuxカーネル 2.6.32-431
• ディストリビューション：CentOS 6.5
• RDBMS
– Percona 5.6.22

14
セットアップ（デバイス）
• サンディスク様より必要な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.

15
セットアップ（ファイルシステム）
• デタッチしたデバイスをアタッチ
• ファイルシステムを作成してマウント
[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.

16
セットアップ（データベース）
• ダブルライトまたはスキップダブルライトと同じように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

17
以上！
やったね！
もうバッチリ！

18
本当に書き込み量に違いがあるの？試してみた！
• アトミックライトの有無による書き込み量の違い
– アトミックライト
• ファイルシステム：NVMFS
– ダブルライト
• ファイルシステム：XFS
– スキップダブルライト
• ファイルシステム：XFS
• 全く同じクエリを発行したときの書き込み量を検証
– ただし、手早く結果を見るために一部設定のデチューンを行った
[root@dev ~]# for I in `seq 1 1000000`
> do
> mysql –uroot –ppasswd test –e “insert hoge into values($I);”
> done
実装上、アトミックライトはNVMFSを経由することで実現
してしまう。そのため、スキップダブルライトではNVMFS
ではなく、XFSを用いた
NVMFSはカーネルドライバとハードウェアによって
実現されるファイルシステム。アトミックライトを使うために
必要

19
アトミックライトの有無による書き込み量の違い
0
0.5
1
1.5
2
2.5
3
3.5
4
1
15
29
43
57
71
85
99
113
127
141
155
169
183
197
211
225
239
253
267
281
295
309
323
337
351
365
379
393
407
421
435
449
463
477
491
505
519
533
547
561
575
589
603
MB
経過時間
double write
skip double write
atomic write

20
0
0.5
1
1.5
2
2.5
3
3.5
4
1
15
29
43
57
71
85
99
113
127
141
155
169
183
197
211
225
239
253
267
281
295
309
323
337
351
365
379
393
407
421
435
449
463
477
491
505
519
533
547
561
575
589
603
MB
経過時間
double write
skip double write
atomic write
スキップダブルライトとアトミックライトはほぼ同じ書き込み量
むしろわずかながらアトミックライトの方が書き込み量が少ない！？

21
0
0.5
1
1.5
2
2.5
3
3.5
4
1
15
29
43
57
71
85
99
113
127
141
155
169
183
197
211
225
239
253
267
281
295
309
323
337
351
365
379
393
407
421
435
449
463
477
491
505
519
533
547
561
575
589
603
MB
経過時間
double write
skip double write
atomic write簡易的なテストにおいてもダブルライトはスキップダブルライト
およびアトミックライトと比較して約1.5倍書き込んでいた。
今回は違いを見るためだけなのでデチューンしているが、
これはフラッシュメモリの素子の寿命にも影響する可能性がある。

22
0
0.5
1
1.5
2
2.5
3
3.5
4
1
15
29
43
57
71
85
99
113
127
141
155
169
183
197
211
225
239
253
267
281
295
309
323
337
351
365
379
393
407
421
435
449
463
477
491
505
519
533
547
561
575
589
603
MB
経過時間
double write
skip double write
atomic writeInnodb_dblwr_pages_written = 18374
18374 * 16[KB] = 287[MB]

23
目次
5. まとめ

24
ベンチマークでアトミックライト有無による性能差を比較
• ベンチマークツール
– tpcc-mysql
• データベース条件
– バッファプール：10GB
– バイナリログ：同期
• tpcc-mysql条件
– コネクション数：64
– 準備時間：300sec
– 計測時間：600sec
パターン1：データがメモリにのる場合（CPUバウンド）
・ウェアハウス：100
・バッファプール10GBに対してデータサイズが10GB
パターン2：データがメモリにのらない場合（IOバウンド）
・ウェアハウス：1000
・バッファプール10GBに対してデータサイズが100GB

25
データがバッファプールにのる場合（CPUバウンド）

26
アトミックライトの有無による性能差
CPUバウンド時の総トランザクション処理数
0
10000
20000
30000
40000
50000
60000
70000
80000
doublewrite skip-doublewrite atomic-write
TpmC(TransactionPerMinuteC)

27
0
10000
20000
30000
40000
50000
60000
70000
80000
TpmC(TransactionPerMinuteC)アトミックライトの有無による性能差
ダブルライトおよびスキップダブルライト間では大きな差は見られなかった

28
0
10000
20000
30000
40000
50000
60000
70000
80000
TpmCとしては5000ぐらい、
相対的には約8%ほどの
性能差が見られた

29
0
2000
4000
6000
8000
10000
12000
14000
10 110 210 310 410 510
TransactionPer10sec
Time (sec)
doublewrite
skip-doublewrite
atomic-write
CPUバウンド時のトランザクション処理傾向

30
0
2000
4000
6000
8000
10000
12000
14000
10 110 210 310 410 510
TransactionPer10sec
Time (sec)
doublewrite
skip-doublewrite
atomic-write
CPUバウンド時のトランザクション処理傾向
ダブルライトおよびスキップダブルライトに関しては傾向的にも変化は見られなかった
アトミックライトは定常的にこれら2つと比較して僅かながら高い性能を発揮した

31
CPUバウンド時のCPUリソース状況
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1
49
97
145
193
241
289
337
385
433
481
529
577
625
673
721
769
817
865Time (sec)
idle
guest
steal
soft
irq
iowait
sys
nice
usr
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1
49
97
145
193
241
289
337
385
433
481
529
577
625
673
721
769
817
865
Time (sec)
idle
guest
steal
soft
irq
iowait
sys
nice
usr
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1
49
97
145
193
241
289
337
385
433
481
529
577
625
673
721
769
817
865
Time (sec)
idle
guest
steal
soft
irq
iowait
sys
nice
usr
ダブルライト
スキップダブルライト
アトミックライト
ダブルライトおよびスキップダブルライトに
変化は見られなかった。一方、usr + sysが
ダブルライトおよびスキップダブルライトが
90%程度であるのにアトミックライトは95%
ほど使用しており、かつusrにおける息継ぎ
が見られなかった。

32
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
0 100 200 300 400 500 600 700 800 900 1000
iowait(%)
Time (sec)
doublewrite
skip-doublewrite
atomic-write
CPUバウンド時のIO待ち状況

33
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
0 100 200 300 400 500 600 700 800 900 1000
iowait(%)
Time (sec)
doublewrite
skip-doublewrite
atomic-write
CPUバウンド時のIO待ち状況
ダブルライトおよびスキップダブルライトは大体0.2%ほどで
あったのに対して、アトミックライトは定常的に0.1%ほどであった。
また、ダブルライトおよびスキップダブルライトではusrやsysと
同様にアトミックライトには見られない息継ぎが見られた。

34
データがバッファプールに乗らない場合（IOバウンド）

35
IOバウンド時の総トランザクション処理数
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
TpmC(TransactionPerMinuteC)

36
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
スキップダブルライトおよび
アトミックライトはダブルライト
と比較して、TpmCとしては
20000ほど、相対的には
約2倍の性能差が見られた

37
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
スキップダブルライトとアトミックライト
に関してはほとんど性能差は見られなかった

38
0
1000
2000
3000
4000
5000
6000
7000
8000
10 110 210 310 410 510
TransactionPer10sec
Time (sec)
doublewrite
skip-doublewrite
atomic-write
IOバウンド時のトランザクション処理傾向

39
0
1000
2000
3000
4000
5000
6000
7000
8000
10 110 210 310 410 510
TransactionPer10sec
Time (sec)
doublewrite
skip-doublewrite
atomic-write
IOバウンド時のトランザクション処理傾向
スキップダブルライトおよびアトミックライトはほぼ同様の傾向を示した

40
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1
49
97
145
193
241
289
337
385
433
481
529
577
625
673
721
769
817
865
Time (sec)
idle
guest
steal
soft
irq
iowait
sys
nice
usr
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1
49
97
145
193
241
289
337
385
433
481
529
577
625
673
721
769
817
865
Time (sec)
idle
guest
steal
soft
irq
iowait
sys
nice
usr
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1
49
97
145
193
241
289
337
385
433
481
529
577
625
673
721
769
817
865
Time (sec)
idle
guest
steal
soft
irq
iowait
sys
nice
usr
IOバウンド時のCPUリソース状況
ダブルライト
スキップダブルライト
アトミックライト
スキップダブルライトおよびアトミックライトは
最終的にusrが50%ほどに上昇したが、
ダブルライトは大体30%ほどであった。
また、アトミックライトおよびスキップダブル
ライトはsysも非常に高く、10 – 20%ほどを
占めていた。ダブルライトおよびアトミック
ライトに関してはトランザクション処理傾向に
見えた息継ぎのような性能低下が見えた。

41
0
1
2
3
4
5
6
7
8
9
10
0 100 200 300 400 500 600 700 800 900 1000
iowait(%)
Time (sec)
Double Write
Skip Double Write
Atomic Write
IOバウンド時のIO待ち状況

42
0
1
2
3
4
5
6
7
8
9
10
0 100 200 300 400 500 600 700 800 900 1000
iowait(%)
Time (sec)
Double Write
Skip Double Write
Atomic Write
IOバウンド時のIO待ち状況
スキップダブルライトおよびアトミックライトは似たような傾向を示した。
ただし僅かながらアトミックライトが全体的にiowaitは低い。
一方、ダブルライトに関してはiowaitが激しく上下した。

43
目次
5. まとめ

44
その他の書き込み原子性
512B
MySQL
ページサイズ
ファイルシステム
ブロックサイズ
ストレージ
4KB
16KB
…
…
データベースのダブルライトにより
原子性を保障
ファイルシステムのジャーナリング等により
原子性を保障

45
ん、ちょっと待てよ・・・？

46
その他の書き込み原子性
512B
MySQL
ページサイズ
ストレージ
4KB
16KB
…
…
データベースのダブルライトにより
原子性を保障
ファイルシステムのジャーナリング等により
原子性を保障
MySQL
ページサイズ
ストレージ
4KB
4KB 16KB
16KB
・ MySQL(Percona) 5.6ではページサイズの変更が可能
・多くのファイルシステムはフォーマット時にブロックサイズを変更可能
・ ioMemoryではブロックサイズを変更可能
16KB
4KB

47
Q.アトミックライトなんかなくても
ユニットサイズのギャップさえなければ
スキップダブルライトで良いのでは？

48
A.トランザクショナルファイルシステムが必要
ext4（data=journal）、ZFS、BtrFSなどなど

49
• Write Back
– データおよびメタデータの順序関係なくメタデータのみジャーナリング（デー
タ破損可能性あり）
• Ordered
– データを書き込んでからメタデータを書き込むがジャーナリングはメタデータ
のみ（データ損失可能性あり）
• Journal
– メタデータおよびデータをジャーナリング（データ破損可能性ほぼなし）
ジャーナリングストラテジーの種類
MySQL
ページサイズ
ストレージ
4KB
4KB 16KB
16KB
16KB
4KB
ユニットサイズのギャップの前に
ジャーナルモード以外はデータ損失の
可能性がある

50
せっかくなので色々なパターンで計測

51
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
xfs ext4-writeback ext4-journal xfs ext4-writeback ext4-journal nvmfs
DoubleWrite SkipDoubleWrite AtomicWrite
TpmC
512 4k 4k
512 4k 16k
4k 4k 4k
4k 4k 16k
ユニットサイズの組み合わせ
HW Block -
FS Block -
MySQL Page Size
条件は先ほどのパターン2の条件

52
電源断が発生した場合にデータが
破損・欠損する可能性がある組み合わせを除外

53
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
TpmC
512 4k 4k
512 4k 16k
4k 4k 4k
4k 4k 16k
HW Block -
FS Block -
MySQL Page Size

54
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
TpmC
512 4k 4k
512 4k 16k
4k 4k 4k
4k 4k 16k
HW Block -
FS Block -
MySQL Page Size
アトミックライトが安全かつ最も高性能！
ダブルライトの安全性とスキップダブルライトの性能！

56
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
TpmC
512 4k 4k
512 4k 16k
4k 4k 4k
4k 4k 16k
HW Block -
FS Block -
MySQL Page Size
Perconaの公式の記事にもあったように、今回の条件では
ダブルライトよりファイルシステムに任せた方が効率的であった

57
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
TpmC
512 4k 4k
512 4k 16k
4k 4k 4k
4k 4k 16k
HW Block -
FS Block -
MySQL Page Size
ファイルシステムのジャーナリングストラテジーが同じ場合
同じような傾向を示す？（XFSはwriteback）

58
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
TpmC
512 4k 4k
512 4k 16k
4k 4k 4k
4k 4k 16k
HW Block -
FS Block -
MySQL Page Size
スキップダブルライト、アトミックライトにおいて
良くも悪くも最も性能に影響するユニットサイズは
MySQLページサイズだった（最大約1.5倍）

59
目次
5. まとめ

60
まとめ
• アトミックライトは簡単に導入・使用が可能
• アトミックライトおよびスキップダブルライトはダブルライトより少ない書
き込み量で済むため、性能および素子の寿命に影響が出る
• アトミックライトはダブルライトの書き込み原子性とスキップダブルライト
の性能を持っている
– 特にIOバウンドではダブルライトと比較して2倍ほどの性能が出ていた
• 電源断に備えるならアトミックライト、ダブルライトもしくはトランザクショ
ナルファイルシステムを使用する
– （tpcc-mysqlにおいて）最も性能に影響が出たデータのユニットサイズは
MySQLのページサイズだった
– ファイルシステムのジャーナリングモードによって傾向が異なった

61
最後に
• 今回の検証では、他のデータと比較するために一部の設定に満足い
かない点がありました。なので、今後の検証ではその部分（特に
my.cnfの設定等）を改善し、ioMemory3としての性能に注目したいと
思います。
– 特にダブルライトでの最大性能でスキップダブルライトおよびアトミックライト
にどれだけ迫れるかなど

62
ご清聴ありがとうございました
お問い合わせ先 IIJインフォメーションセンター
TEL：03-5205-4466 （9：30～17：30 土/日/祝日除く）
info@iij.ad.jp
http://www.iij.ad.jp/

使ってみた！ioMemoryで実現する噂のAtomic write！

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to 使ってみた！ioMemoryで実現する噂のAtomic write！

Similar to 使ってみた！ioMemoryで実現する噂のAtomic write！ (20)

More from IIJ

More from IIJ (20)

Recently uploaded

Recently uploaded (15)

使ってみた！ioMemoryで実現する噂のAtomic write！