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

2015/06/10

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

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

自己紹介

• 氏名 – 正原竜太

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

• 職種 – インフラエンジニア

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

• Oracle, MySQL, SQLServer

元々ネットワークエンジニアの若輩者なのであまりイジメないで下さいね

今回のお話の経緯

• 2013年6月、それまでしょっぱいSSDぐらいにしか縁のなかった新社会人がioDriveなるものを知り、実際に使用してみてその性能に驚く

担当者曰く、「フラッシュメモリの味を占めたら後には引き返せない」そうなの

• 2013年?月、ioDriveについてさらに調べていくにつれ、OpenNVMや

アトミックライトの存在を知ったが、当時の弊社環境では利用できず、ひっそり枕を濡らす

パッケージが足りなかったんですね

• 2013年?月、ioDriveについてさらに調べていくにつれ、OpenNVMや

アトミックライトの存在を知ったが、当時の弊社環境では利用できず、ひっそり枕を濡らす

• 2014年12月、ioMemory3の検証と共に弊社でもアトミックライト等のOpenNVM技術が検証可能に！

早速導入検証してみましょう！

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

MySQLの書き込みにおける原子性

• MySQLのページサイズはデフォルトで16KB • 多くのファイルシステムのブロックサイズはデフォルトで4KB • ブロックに書き込み中に電源障害等が発生すると・・・

ページ

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

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

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

4KB 4KB 4KB 4KB

電源障害等

4KB 4KB 4KB 4KB

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

メモリ

ストレージ

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

• ダブルライトバッファによる原子性の保障 – MySQLではこの電源障害等によるデータの不整合をダブルライトバッファ

を用いた2回書き込みにより回避している。

ページ

4KB 4KB 4KB 4KB ダブルライトバッファ

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

4KB 4KB 4KB 4KB

メモリ

ストレージ

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

4KB 4KB 4KB 4KB

チェックサムで異常を検知して書き込み途中の不完全なデータを破棄

• ダブルライトバッファによる原子性の保障 – MySQLではこの電源障害等によるデータの不整合をダブルライトバッファ

を用いた2回書き込みにより回避している。

ページ

4KB 4KB 4KB 4KB ダブルライトバッファ

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

4KB 4KB 4KB 4KB

メモリ

ストレージ

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

4KB 4KB 4KB 4KB

ダブルライトバッファから書き込み予定だったデータを実データ領域へ書き込みリカバリ

• アトミックライトによる原子性の保障 – SDKが提供するAPIを利用することにより、カーネルドライバおよびハード

ウェアにより複数ブロックへの書き込みにおいて「1ブロックも書いていない」 or 「全ブロック書いた」という原子性が保障されるようになった。これがダブルライトの代替となる機能である。

ページ

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

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

4KB 4KB 4KB 4KB

メモリ

ストレージ

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

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

ダブルライトバッファに書き込まない分オーバーヘッドが少ない！！！

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

検証環境

• サーバ：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

セットアップ（デバイス）

• サンディスク様より必要な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.

セットアップ（ファイルシステム）

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

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

[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.

セットアップ（データベース）

• ダブルライトまたはスキップダブルライトと同じように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

以上！やったね！

もうバッチリ！

本当に書き込み量に違いがあるの？試してみた！

• アトミックライトの有無による書き込み量の違い – アトミックライト

• ファイルシステム：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はカーネルドライバとハードウェアによって実現されるファイルシステム。アトミックライトを使うために必要

アトミックライトの有無による書き込み量の違い

1 15 29 43 57 71 85 99 113

経過時間

double write

skip double write

atomic write

1 15 29 43 57 71 85 99 113

経過時間

double write

skip double write

atomic write

スキップダブルライトとアトミックライトはほぼ同じ書き込み量むしろわずかながらアトミックライトの方が書き込み量が少ない！？

1 15 29 43 57 71 85 99 113

経過時間

double write

skip double write

atomic write簡易的なテストにおいてもダブルライトはスキップダブルライトおよびアトミックライトと比較して約1.5倍書き込んでいた。今回は違いを見るためだけなのでデチューンしているが、これはフラッシュメモリの素子の寿命にも影響する可能性がある。

1 15 29 43 57 71 85 99 113

経過時間

double write

skip double write

atomic writeInnodb_dblwr_pages_written = 18374 18374 * 16[KB] = 287[MB]

ベンチマークでアトミックライト有無による性能差を比較

• ベンチマークツール – tpcc-mysql

• データベース条件 – バッファプール：10GB – バイナリログ：同期

• tpcc-mysql条件 – コネクション数：64 – 準備時間：300sec – 計測時間：600sec

パターン1：データがメモリにのる場合（CPUバウンド）・ウェアハウス：100 ・バッファプール10GBに対してデータサイズが10GB

パターン2：データがメモリにのらない場合（IOバウンド）・ウェアハウス：1000 ・バッファプール10GBに対してデータサイズが100GB

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

アトミックライトの有無による性能差 CPUバウンド時の総トランザクション処理数

doublewrite skip-doublewrite atomic-write

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

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

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

10 110 210 310 410 510

Time (sec)

doublewrite

skip-doublewrite

atomic-write

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

10 110 210 310 410 510

Time (sec)

doublewrite

skip-doublewrite

atomic-write

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

ダブルライトおよびスキップダブルライトに関しては傾向的にも変化は見られなかったアトミックライトは定常的にこれら2つと比較して僅かながら高い性能を発揮した

CPUバウンド時のCPUリソース状況

0%10%20%30%40%50%60%70%80%90%

1 49 97 145

Time (sec)

iowait

0%10%20%30%40%50%60%70%80%90%

1 49 97 145

Time (sec)

iowait

0%10%20%30%40%50%60%70%80%90%

1 49 97 145

Time (sec)

iowait

ダブルライト

スキップダブルライト

アトミックライト

ダブルライトおよびスキップダブルライトに変化は見られなかった。一方、usr + sysがダブルライトおよびスキップダブルライトが 90%程度であるのにアトミックライトは95% ほど使用しており、かつusrにおける息継ぎが見られなかった。

0 100 200 300 400 500 600 700 800 900 1000

Time (sec)

doublewrite

skip-doublewrite

atomic-write

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

0 100 200 300 400 500 600 700 800 900 1000

Time (sec)

doublewrite

skip-doublewrite

atomic-write

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

ダブルライトおよびスキップダブルライトは大体0.2%ほどであったのに対して、アトミックライトは定常的に0.1%ほどであった。また、ダブルライトおよびスキップダブルライトではusrやsysと同様にアトミックライトには見られない息継ぎが見られた。

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

アトミックライトの有無による性能差 IOバウンド時の総トランザクション処理数

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

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

10 110 210 310 410 510

Time (sec)

doublewrite

skip-doublewrite

atomic-write

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

10 110 210 310 410 510

Time (sec)

doublewrite

skip-doublewrite

atomic-write

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

スキップダブルライトおよびアトミックライトはほぼ同様の傾向を示した

0%10%20%30%40%50%60%70%80%90%

1 49 97 145

Time (sec)

iowait

0%10%20%30%40%50%60%70%80%90%

1 49 97 145

Time (sec)

iowait

0%10%20%30%40%50%60%70%80%90%

1 49 97 145

Time (sec)

iowait

IOバウンド時のCPUリソース状況

ダブルライト

スキップダブルライト

アトミックライト

スキップダブルライトおよびアトミックライトは最終的にusrが50%ほどに上昇したが、ダブルライトは大体30%ほどであった。また、アトミックライトおよびスキップダブルライトはsysも非常に高く、10 – 20%ほどを占めていた。ダブルライトおよびアトミックライトに関してはトランザクション処理傾向に見えた息継ぎのような性能低下が見えた。

0 100 200 300 400 500 600 700 800 900 1000

Time (sec)

Double Write

Skip Double Write

Atomic Write

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

0 100 200 300 400 500 600 700 800 900 1000

Time (sec)

Double Write

Skip Double Write

Atomic Write

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

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

その他の書き込み原子性

MySQL ページサイズ

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

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

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

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

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

その他の書き込み原子性

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

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

4KB 16KB

・ MySQL(Percona) 5.6ではページサイズの変更が可能・多くのファイルシステムはフォーマット時にブロックサイズを変更可能・ ioMemoryではブロックサイズを変更可能

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

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

• Write Back – データおよびメタデータの順序関係なくメタデータのみジャーナリング（デー

タ破損可能性あり） • Ordered

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

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

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

4KB 16KB

ユニットサイズのギャップの前にジャーナルモード以外はデータ損失の可能性がある

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

xfs ext4-writeback ext4-journal xfs ext4-writeback ext4-journal nvmfs

DoubleWrite SkipDoubleWrite AtomicWrite

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k

ユニットサイズの組み合わせ

HW Block - FS Block - MySQL Page Size

条件は先ほどのパターン2の条件

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

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k

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

ちなみに

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k

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

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k

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

C 512 4k 4k

512 4k 16k

4k 4k 4k

4k 4k 16k

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

まとめ

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

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

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

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

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

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

最後に

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

にどれだけ迫れるかなど

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

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

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

Technology

Atomic Absorbtion Spectroscopy

Atomic Structure and Atomic Spectra

Technology Atomic

Atomic Use

2011 Atomic

Atomic structure - sc.sci.rmutp.ac.th · PDF fileRMUTP Atomic structure โครงสร้างอะตอม โครงแบบอิเล็กตรอนของอะตอม

Atomic Absorption Spektrophotometry

Derm Atomic Ose

Atomic Structure Bird

3 atomic chefs

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

Atomic Structure

Atomic Absorpsi Spectrophotometer

Modelul Atomic Bohr

Windows と Linux のセキュリティ : 噂の真相

Atomic structure - University of Arizonaatlas.physics.arizona.edu/.../handout_9_atomic_struct.pdfChapter 9 Atomic structure Previously, we have seen that the quantum mechanics of atomic

Atomic Structure

Atomic Structure1st

Atomic Orbitals

1 Atomic Structure