テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) ベンチマーク速報

今日中にdm-develに投稿するのは不可能なので, 日本語で結果をまとめておく.

ベンチマークは以下の要領で行う.

  1. SSDをdiscardする(blkdiscardを利用する).
  2. キャッシュありのデバイスを作る. bcacheとwriteboostをやる. bcacheはwritebackモード. writeboostはsegmentサイズを512KB, マイグレーションをオフ(このテストではbcacheもどのみちマイグレーションしてない), wbflusherのmax_activeは1.
  3. 4Kランダムライトを流す. この時, プロセス数とiodepthを(1,4)x(4,32)の4通り試す. ベンチマークは15秒だけ行う.
  4. この時, sarを1秒ごとに取得する.

以下が, 取得したデータ

akira@Kamille:~/src/dm-writeboost$ ls benchmark/
bcache_1_32  bcache_4_32  ssd_rand_4k    writeboost_1_32  writeboost_4_32       writeboost_4_4
bcache_1_4   bcache_4_4   ssd_rand_512k  writeboost_1_4   writeboost_4_32_wbf4

その他,

ベースライン

SSDへの4KBランダムと512KBランダムを測定する. ライトをどんどん送り込むために, プロセス数とiodepthは4x32とした. SSDに512KB単位でどかどかとランダムライトを送ると268MB/sec出る. SSDの限界であろう.

IO長 スループット(MB/sec) CPU使用率(%)
4K 201.1 4.45
512K 268.3 0.35

測定結果

セルの記法は, スループット(CPU使用率)をbcache, writeboostの順で並べる.

#thread/iodepth 4 32
1 71.8(4.6), 253.4(3.9) 77.9(4.9), 253.1(3.6)
4 76.8(7.6), 260.1(1.6) 101.7(5.3), 260.2(1.5)

bcacheのblktraceを調べると, bcacheは, 非同期(WS)な4KBライトをシーケンシャルにアドレスを振ってSSDに投げていく(しかし, 投げる前にまとめるということはしない). そして, おそらくそれらが投げ終わったか何かのタイミングで, WBSMフラグでメタデータを書き出す. コードを見ると, REQ_FUAとREQ_FLUSHの両方が入っているようである. すなわち, この時点でデータは永続化されるという仕組み. この順序制御を担うのがclosureであろうと思う.
データだけ書いてpower faultした時, 古いメタデータが新しく書き込まれたデータを誤って読むことはないのだろうか?たぶんだが, writeboostと同様に, メタデータ部に書かれたchecksumか何かで検証してるのだろうと思う(bch_crc64_updateという関数がある).

並列フラッシュの効果

4x32の時に, wbflusherのmax_activeを1から4にしてスループットの増大を確かめる. 263.4(1.0)

並列フラッシュのおかげで少しは上がったが, もともとSSDスループット限界に近いので顕著な上がりはない. 通常の利用では, 1並列で十分だろうと思う.

まとめ

bcacheもランダムライトに努力していることは認めるが, ライトに特化したwriteboostには劣る. writeboostはCPU負荷も低く, SSDスループットも95%以上使い切ることが出来る. おまけにコードは3.5Kと非常に小さい.
将来的な永続メモリへの対応も明確であり, 設計に組み込まれている.

以上のことをまとめて, ベトナムから帰国後どこかのタイミングでdm-develに投稿しようと思う.