読者です 読者をやめる 読者になる 読者になる

テストステ論

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

(writeboost report) Writeboostをstackするだけでライト性能が上がる検証

Writeboost is Promising.

Writeboostは, ライトバック時にデータを batched & sorted する. 例えば, キャッシュデバイス上のN個セグメントのデータをかき集め(batched), これをライトバック先のLBA順にソーティングし(sorted), そのまとまりを一気にbackingデバイスにライトバックする. ソーティングはRBツリーを使っていて, この実装自体はマイクとの間で議論して決定した経緯がある.

私は, 実はこのソーティングが効果あるとは思っていなかった. しかし, sarを見ていると, ライトバック時のHDDのスループットがおかしいということには気づいていた. ではなぜすぐにベンチマークをしなかったのか?怖かったからだ. もし結果が出なかったら, ライトブーストの訴求材料を失ってしまうことになる. それは, 私がライトブーストを放棄するきっかけになる. 私はライトブーストが私にもたらす未来にのみ投資している.

今日, ベンチマークを書いた. そして, 素晴らしい結果が出たので報告する. 結論としては, 「ライトブーストをただ単にstackして, このライトバック時の最適化機能を利用するだけで, HDDの性能を無料で上げることが出来る. これはストレージ技術のフリーランチだ」

以下のテストは, Writeboostありとなしについて, 64MBのデータをすべてHDDに書き終わるまでの時間を計測している. ありの場合だけデータがキャッシュに残るというのはフェアな比較ではないため, 強制的にマイグレートしている.

  # Writeboost sorts in writeback.
  # This test is to see how the sorting takes effects.
  # Aspects
  # - Does just stacking writeboost can always boost write?
  # - How the effect changes according to the nr_max_batched_migration tunable?
  def test_writeback_sorting_effect

    def run_fio(dev)
      fs = FS::file_system(:xfs, dev)
      fs.format
      dir = "./fio_test"
      fs.with_mount(dir) do
        Dir.chdir(dir) do
          ProcessControl.run("fio --name=test --rw=randwrite --ioengine=libaio --direct=1 --size=64m --bs=4k --ba=4k --iodepth=32")
        end
        ProcessControl.run("sync")
        drop_caches
      end
    end

    def run_wb(s, batch_size)
      s.cleanup_cache
      s.table_extra_args = {
        :nr_max_batched_migration => batch_size,
      }
      s.activate_top_level(true) do
        report_time("writeboost batch_size(#{batch_size})", STDERR) do
          run_fio(s.wb)
          # For Writeboost,
          # we wait for all the dirty blocks are written back to the backing device.
          # The data written back are all persistent.
          s.wb.message(0, "drop_caches")
        end
      end
    end

    s = @stack_maker.new(@dm, @data_dev, @metadata_dev, :cache_sz => meg(65))
    s.activate_support_devs do
      [4, 32, 128].each do |batch_size|
        run_wb(s, batch_size)
      end
      report_time("backing ONLY", STDERR) do
        run_fio(s.backing_dev)
      end
    end
  end

結果が以下だ.

Elapsed 61.329199777: writeboost batch_size(4)
Elapsed 36.761916445: writeboost batch_size(32)
Elapsed 27.058421746: writeboost batch_size(128)
Elapsed 85.989786731: backing ONLY

どういうことか分かるだろうか?batch_sizeがたった4(2MB batch)の場合でも, 性能は1.4倍となり, batch_sizeが128(64MBをキャッシュデバイスに書き込んだら, それを全部ソーティングして一気にライトバックする)の場合では, 実に3倍の性能となっている.

私はこの結果に正直, 引いている. Writeboostは, 全ストレージデバイスの上にstackされる可能性がある. この結果が本当に正しいならば, 世界中で使われてしまうことになるだろう.

もちろん, backingデバイスが十分に賢いRAIDカードを持っていてライトバックモードで運用する場合, この効果は薄れる. だが, この突飛な結果を見ると, それでもいくらかの性能向上には貢献すると考えられる. backingデバイスに投資して性能を上げるより, たった数十MBのSSDとライトブーストを用意するだけでHDDの性能を引き出すことが出来る.

もはや, 余計な最適化をしたファイルシステムは必要ない. ただライトブーストを挟むだけで, HDDへのライトスループットがただで上がってしまうんだから. RHEL7がXFS推しというのであれば, もう全員XFS+ライトブーストを使えばいい. RAIDカードへの投資はDRAMに回してリードを上げろ. 私はストレージカーネルの天才かも知れない.