dm-writeboostのI/Oを可視化した

Etsukata blog: blktrace で block IO の分布を可視化するで, btraceを使って採取したトレースをbno_plotを使って可視化する方法が紹介されている.

writeboostに対して, 4KB async writeを撃ち込みまくるベンチマークを行うと, 仮想ボリュームへのアクセスはランダムだが, キャッシュ上ではシーケンシャルになるという当たり前の結果が得られるはずであるが, 実際に検証することには意味がある. 実験は, HPのマイクロサーバ上で行った.

やってみようと思ったが, dmデバイスを使うとbttがbno_dumpをうまく行ってくれないという問題が分かった. これについては, http://marc.info/?l=linux-btrace&m=138624557701946&w=2 にて報告した.

この問題を解析すると, bttがIssueイベントを使ってbno_dumpを行っていることが分かった. @EtsukataとTwitterでやりとりして, IssueではなくCompletionを元にしてやることが良いのではないかということになり, 彼が速攻でパッチを書いて送った. http://marc.info/?l=linux-btrace&m=138625564406359&w=2

私はこのパッチを使い, bttを修正し, 以下の可視化を行う.

https://d33wubrfki0l68.cloudfront.net/089b2f3a7c6abd33f57efc95f5d8ff4924c83a23/4b90b/images/1386260284.jpg

図1. 仮想ボリュームへのランダムライト. 8sector(4KB)のライトが満遍なく発行されていることが分かる.

https://d33wubrfki0l68.cloudfront.net/adf0c6ee679b1965849835245db93026072fe6a1/d7fe1/images/1386260291.jpg

図2. キャッシュへのライト. シーケンシャルライトになってるかどうかこの図からは判定しにくいが, それっぽいことは良く分かる. リクエストの大きさも, 1024sectorあたりである. なぜだろうか, 時間軸上で等間隔に見えない. 実験前にTrimするのを怠っているからだろうか.

良い仕事をした.


このエントリーをはてなブックマークに追加

See also