SSDとSATA RAIDのベンチマーク比較Validation Case Study(2/2 ページ)

» 2008年08月07日 00時00分 公開
[Open Tech Press]
SourceForge.JP Magazine
前のページへ 1|2       

パフォーマンス評価

 今回のBonnie++(翻訳記事)を使ったSSDのパフォーマンス測定では、XFSとext3の両方のファイルシステムを利用した。比較対象としては、750GバイトHDDによるシングルドライブ構成と、同じドライブ6台によるパリティ方式のRAID構成の測定結果を用いた。これらのテストは2.2GHzのAMD Athlon X2プロセッサ搭載マシンで実施し、SSDは外付けの筐体に収めてeSATAインタフェースを介してこのマシンに接続した。

 Bonnie++でのテストには、mkfs.ext3にパラメータを追加せず、マウントパラメータも指定しないext3ファイルシステム(ext3default)を利用した。また、ファイルシステムのパラメータはデフォルトのままだがマウント時に「data=writeback,nobh」オプションを指定した条件(ext3wbnobh)も用意した。このwritebackオプションは、電源が突然絶たれた場合のデータ保全を犠牲にしてスループットをわずかに向上させる。データのジャーナリングモードはデフォルトでorderedになっており、このモードではメタデータが更新される前にファイルデータがメインファイルシステムに書き込まれる。writebackモードを使うと、ファイルシステムへのデータの書き込みがメタデータの更新よりも前になったり後になったりするため、クラッシュや電源故障が発生した場合にはメタデータが最新でもファイルのデータは古いままになってしまう可能性がある。orderedとwritebackのどちらのモードでも、内部ファイルシステムの完全性は保証される。

 nobhオプションについては、カーネルに付属するext3.txtファイル内に、バッファの先頭とデータページとの対応付けに関係しているとの説明がある。カーネル側の詳細はさておき、ext3.txtの最後の行には、nobhはwritebackモードでのみサポートされると記されている。よって、今回writebackモードを使用する際には、nobhオプションも併せて指定している。

 XFSファイルシステムでのテストでは、ファイルシステムの作成時に「-l lazy-count=1」というパラメータを使用し、「nobarrier」オプションを指定してマウントを行った。XFSファイルシステムの作成時に「lazy-count」オプションを「1」に設定しておくと、カウンタ情報の一部がスーパーブロックではなくファイルシステム全域に分散して保存される。こうした情報のすべてをスーパーブロック内に置いておくと、スーパーブロック自体のアップデートによってメタデータ操作の速度が低下する可能性がある。

 XFSファイルシステムは、ディスクのバリアを使って、トランザクション終了時にファイルシステムのジャーナルをディスクにフラッシュしようとする。そのため、ファイルの作成や削除など、ジャーナルを使用する操作の実行時には、ファイルシステムのパフォーマンスが大きな影響を受ける場合がある。XFSファイルシステムでnobarrierマウントオプションを指定すると、こうしたディスクへのジャーナルの強制フラッシュが無効になる。予期せぬ電源遮断が発生しない環境でXFSファイルシステムを使うのであれば、このnobarrierオプションを指定することで、ジャーナルの移行が不完全に行われる危険性なしにパフォーマンスを向上させることができる。

ブロック入出力とメタデータ操作の比較 ブロック入出力とメタデータ操作の比較

 試しにバリアを有効にしてベンチマークを実行してみたところ、ファイルのメタデータ操作(作成、削除、statによる情報取得)に関する拡張テストの実行にあまりにも時間がかかるので、途中でベンチマークの実行を中止した。よって、以降ではlazy-countとnobarrierの各オプションを指定したXFS(xfslcnb)でのベンチマーク結果を紹介する。ディスクの動作回数を見るかぎり、XFSでバリアを有効にすると、ファイルのメタデータ操作に関するテストの実行速度は約10分の1になるようだ。


Bonnie++でのシークの評価 Bonnie++でのシークの評価

 右に、ブロック単位での入出力のスループットとファイルのメタデータ操作のグラフを示す。もともとXFSでのメタデータ操作はそのほかのファイルシステムに比べてわずかに遅いので、ファイルの作成や削除といったメタデータ操作のパフォーマンスでXFSがext3におよばないのは当然である。しかし、ブロック出力ではXFSの方がかなり優れている。

 評価したSSDのランダムシーク速度は、ext3で約6200回/秒、XFSで3800回/秒だった。右のグラフには、比較用に750GバイトSATA HDDのシングルドライブ構成と、同じHDDを6台使ったRAID-6構成のシークパフォーマンスも示してある。HDDを1台から6台に増やすことでシークパフォーマンスは大幅に向上するが、それでもSSDにはかなわない。SSDの搭載によってマシンの起動時間がいちじるしく短縮される理由は、シークタイムにおけるSSDのこうした優位性にある。通常、マシンを立ち上げたり複雑なアプリケーションを読み込んだりするには、何千というファイルの読み取りが必要になる。その上、普通はこうしたファイルがディスクプラッタ上に分散して存在するので、シーク回数はさらに増える。そのため、かなり大規模なアプリケーションを読み込む場合には、シークタイムの短さというSSDの利点が何秒もの差となって表れてくる。


Bonnie++でのRAIDのブロック入出力の評価 Bonnie++でのRAIDのブロック入出力の評価

 最後のグラフは、ブロック単位での読み取り、書き込み、再書き込みのパフォーマンスをSSD、750GバイトSATA HDD1台、同じHDD6台によるRAID-6の各システムで比較したものである。ブロック転送のパフォーマンスについては、750GバイトSATAのシングルドライブとSSDとの間に大きな違いはなく、全体的にRAID-6構成のHDDの速さが目立つ結果になっている。

 ブロック転送についての先ほどの比較から、同じ予算で従来のHDDを購入した場合とSSDを購入した場合で、得られるブロック入出力のパフォーマンスがどれほど違うかが分かる。SSDはシークタイムの点では圧倒的に優れているものの、同じコストで得られるストレージ容量は従来のHDDの何十分の1でしかなく、ブロック転送速度についても複数のHDDをRAID化したものにはおよばない。

Ben Martinは10年以上もファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティングサービスを手掛けている。


前のページへ 1|2       

Copyright © 2010 OSDN Corporation, All Rights Reserved.

注目のテーマ