使ってみた！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

目次


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

目次


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

Tpm

C (T

rans

actio

n Pe

r Min

ute

C)

27

0

10000

20000

30000

40000

50000

60000

70000

80000


Tpm

C (T

rans

actio

n Pe

r Min

ute

C)


ダブルライトおよびスキップダブルライト間では大きな差は見られなかった

28

0

10000

20000

30000

40000

50000

60000

70000

80000


Tpm

C (T

rans

actio

n Pe

r Min

ute

C)


TpmCとしては5000ぐらい、相対的には約8%ほどの性能差が見られた

29

アトミックライトの有無による性能差

0

2000

4000

6000

8000

10000

12000

14000

10 110 210 310 410 510

Tran

sact

ion

Per 1

0sec

Time (sec)

doublewrite

skip-doublewrite

atomic-write

CPUバウンド時のトランザクション処理傾向

30


0

2000

4000

6000

8000

10000

12000

14000

10 110 210 310 410 510

Tran

sact

ion

Per 1

0sec

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

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

ダブルライト

スキップダブルライト

アトミックライト

ダブルライトおよびスキップダブルライトに変化は見られなかった。一方、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

iow

ait (

%)

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

iow

ait (

%)

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


Tpm

C (T

rans

actio

n Pe

r Min

ute

C)

36

0

5000

10000

15000

20000

25000

30000

35000

40000

45000


Tpm

C (T

rans

actio

n Pe

r Min

ute

C)


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

37

0

5000

10000

15000

20000

25000

30000

35000

40000

45000


Tpm

C (T

rans

actio

n Pe

r Min

ute

C)


スキップダブルライトとアトミックライトに関してはほとんど性能差は見られなかった

38


0

1000

2000

3000

4000

5000

6000

7000

8000

10 110 210 310 410 510

Tran

sact

ion

Per 1

0sec

Time (sec)

doublewrite

skip-doublewrite

atomic-write

IOバウンド時のトランザクション処理傾向

39


0

1000

2000

3000

4000

5000

6000

7000

8000

10 110 210 310 410 510

Tran

sact

ion

Per 1

0sec

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

iow

ait (

%)

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

iow

ait (

%)

Time (sec)

Double Write

Skip Double Write

Atomic Write

IOバウンド時のIO待ち状況

スキップダブルライトおよびアトミックライトは似たような傾向を示した。ただし僅かながらアトミックライトが全体的にiowaitは低い。一方、ダブルライトに関してはiowaitが激しく上下した。

43

目次


44

その他の書き込み原子性

512B

MySQL ページサイズ

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

ストレージブロックサイズ

4KB

16KB

…

…

データベースのダブルライトにより原子性を保障

ファイルシステムのジャーナリング等により原子性を保障

45

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

46

その他の書き込み原子性

512B




4KB

16KB

…

…

データベースのダブルライトにより原子性を保障

ファイルシステムのジャーナリング等により原子性を保障




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 – メタデータおよびデータをジャーナリング（データ破損可能性ほぼなし）

ジャーナリングストラテジーの種類




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

Tpm

C 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



Tpm

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k



54

0

5000

10000

15000

20000

25000

30000

35000

40000

45000



Tpm

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k



アトミックライトが安全かつ最も高性能！ダブルライトの安全性とスキップダブルライトの性能！

55

ちなみに

56

0

5000

10000

15000

20000

25000

30000

35000

40000

45000



Tpm

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k



Perconaの公式の記事にもあったように、今回の条件ではダブルライトよりファイルシステムに任せた方が効率的であった

57

0

5000

10000

15000

20000

25000

30000

35000

40000

45000



Tpm

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k



ファイルシステムのジャーナリングストラテジーが同じ場合同じような傾向を示す？（XFSはwriteback）

58

0

5000

10000

15000

20000

25000

30000

35000

40000

45000



Tpm

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k



スキップダブルライト、アトミックライトにおいて良くも悪くも最も性能に影響するユニットサイズは MySQLページサイズだった（最大約1.5倍）

59

目次


60

まとめ

• アトミックライトは簡単に導入・使用が可能

• アトミックライトおよびスキップダブルライトはダブルライトより少ない書き込み量で済むため、性能および素子の寿命に影響が出る

• アトミックライトはダブルライトの書き込み原子性とスキップダブルライトの性能を持っている – 特にIOバウンドではダブルライトと比較して2倍ほどの性能が出ていた

• 電源断に備えるならアトミックライト、ダブルライトもしくはトランザクショ

ナルファイルシステムを使用する – （tpcc-mysqlにおいて）最も性能に影響が出たデータのユニットサイズは

MySQLのページサイズだった – ファイルシステムのジャーナリングモードによって傾向が異なった

61

最後に

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

にどれだけ迫れるかなど

62

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

お問い合わせ先 IIJインフォメーションセンター TEL：03-5205-4466 （9：30～17：30 土/日/祝日除く） [email protected] http://www.iij.ad.jp/

Technology

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