Bonnie++を使ったファイルシステム性能のベンチマーク

 Bonnie++はファイルシステムに関する様々なタスクをベンチマークすることができるツールで、RAIDの構成やファイルシステムの構成やネットワークファイルシステムの設定などを変更する際に大いに役立つ。

 Bonnie++はopenSUSE 10.3(1-クリック・インストール)、Ubuntu Hardy、標準のFedora 9リポジトリなどから入手可能だ。今回は64ビット用Fedora 9リポジトリからインストールした。

 Bonnie++はUbuntu用とFedora用のパッケージでは/usr/sbinにインストールされるのに対してopenSUSEでは/usr/binにインストールされる。ルートユーザとして起動するとエラーが出て実行できないのだが、/usr/binではなく/usr/sbinにインストールしてある場合、通常のユーザとして実行するためにはフルパスを指定する必要がおそらくあるだろう。Bonnie++ではautoconfを使ってMakefileを生成するのだが、install-binターゲットで固定的にBonnie++をsbinにインストールするようになっているので、/usr/binに置きたい場合には、ソースから構築している場合でもインストール後に移動する必要がある。

 Bonnie++では、データの読み書きを行う速度、1秒間に行うことのできるシークの回数、1秒間に行うことのできるファイルのメタデータの操作回数という3つの項目についてのベンチマークが可能だ。メタデータ操作には、ファイルの作成/削除と、ファイルの大きさや所有者などのメタデータ(fstat(2) システムコールの結果)の取得とがある。

 例えば/tmpに使用するファイルシステムを選ぶ場合には、決め手となるベンチマーク項目はメタデータのスループットかもしれない。20MBのtarファイルを展開する場所用のファイルシステムでは、1秒間に作成可能なファイル数の方が書き込みについての性能よりも重要になるだろう。同様に、Squidウェブプロキシの使用や、各メールをそれぞれ別々のファイルに保存するmaildir形式を採用しているメールサーバの使用を検討している場合にもメタデータのベンチマークは重要だ。そのようなアプリケーションでは大量のメタデータ操作が何度も行なわれるが、各ファイルの容量は概してかなり小さいので、大量データの転送速度よりもメタデータの更新速度の方が重要な要素になる。

 メタデータのベンチマークはまた、RAIDデバイス上にファイルシステムを新しく作成する場合にも重要だ。ジャーナリングファイルシステムは、ジャーナル内のメタデータを保護するために書き込みバリアを使用していることがある。RAID機能のためにハードウェアRAIDカードを使用している場合、そのような書き込みバリアの存在によってRAIDカード上の全キャッシュとそのRAIDカード上でRAIDを構成している全ディスクとの同期が取られる可能性があって、その場合には性能が極端に低下してしまう。実例として私が最近試したケースを挙げれば、Adaptec 31205カード(12ポート)上のRAID-6と書き込みバリアを有効にしたXFSを使用したテストでは、1秒間に作成可能なファイル数は100に満たなかった。一方同じファイルシステムをマウントする際にXFSの書き込みバリアを明示的に無効にした場合では、1秒間に作成可能なファイル数は6,000近くにまで増加した。XFSの書き込みバリアを無効にすることを勧めるつもりはないが、このハードウェア構成のケースに限って言えば、バリアを無効にしてもデータが失われるリスクはない

 1秒間に可能なシーク回数については、ハードウェア構成の影響が非常に大きい。1台のディスクとRAIDとを比較してみたところ、RAID上のファイルシステムではディスクの台数を増やせばシーク数の増加が期待できるようだった。例えば1台のディスクと、2台のディスクを使ったRAID-0(ストライピング)構成と、6台のディスクを使ったRAID-0構成とを比べてみたところ、1台のディスクでは1秒間に可能なシーク回数が約200回だったのに対して、2台のストライピングでは約340回、6台のストライピングでは約533回だった。

 データの読み書きのベンチマークとしては、キャラクタ単位の結果とブロック単位の結果とが表示される。キャラクタ単位のベンチマークは、一度に1文字のキャラクタの読み書き操作を行う標準ライブラリの呼び出しを使用して行われる。一方ブロック単位のベンチマークは、より大きなブロックを一度に転送する関数の呼び出しを使用して行われる。

 再書き込みのテストは、既存のデータを変更するアプリケーションを利用する場合に重要になる項目だ。またそのようなアプリケーションを(RAID-5やRAID-6のような)パリティ付きのRAID上で実行する場合には、さらにいっそう重要になる。再書き込みテストでは具体的には、1ブロックのデータを読み取って、少し変更して、再び書き込むという操作が行われる。1ブロックはBUFSIZの大きさになるので、64ビット用Fedora 9をインストールした今回のシステムの場合は8,192バイトだった。

bonnie1_thumb.png
Bonnie++

 再書き込みテストがパリティ付きのRAIDにとって重要である理由を考えるためには、LinuxのソフトウェアRAIDを使ってRAID-5を4台のディスク上に構築した場合を考えてみよう。RAIDのチャンクの大きさはデフォルトでは64KBだ。つまり右の図のように4台のディスクに分散して、64KBのチャンクが3つと、パリティである64KBのチャンクが1つ存在することになる。図ではDisk1~Disk3にデータ、Disk4にパリティが保存されている(なお当然ながらどのディスクにパリティが保存されているのかは、アクセスする領域によって異なる)。再書き込みテストでは8KB(図では赤い四角で示した)のみを変更するのだが、その変更の結果として、64KBのパリティチャンクの再計算と、64KBのパリティチャンクと64KBの元のデータチャンクの書き込みとを行わなければならなくなる。図の場合では、パリティの再計算後、Disk1上の灰色の帯域とDisk4のピンクの帯域との書き込みが必要になる。

 メタデータについてのベンチマーク結果では、毎秒の操作回数の数字の代わりに「+++++」と表示されていることがあるが、これはそのベンチマークがあまりにも短時間で完了したことを示している。ある構成についてのベンチマーク結果がそのようになってしまった場合には、「-n」オプションを使って、メタデータのテストに使用するファイル数を増やすように指定すれば良い。「-n」オプションでは、最大4つのパラメータを指定することができる。最初のパラメータは1つのディレクトリ内に作成するファイル数で、1,024の何倍なのかを指定する。2つめと3つめのパラメータはテストに使用する全ファイルの最大/最小サイズだ。4つめのパラメータは、1つめのパラメータで指定した数のファイルをそれぞれ含むディレクトリを作成する数だ。デフォルトでは、0バイトの大きさのファイルを16,384個含むディレクトリを1つ作成する。つまり「-n 16:0:0:1」というパラメータを指定した場合と同じだ。

 bon_csv2htmlコマンドを使えば、Bonnie++の出力結果の最後にあるCSV形式を処理して、ウェブでの閲覧に適した形式にすることができる。CSV形式のデータ部分以外をすべて標準エラー出力にリダイレクトする「-q」オプションと併用すれば、Bonnie++の標準出力をbon_csv2htmlにパイプ経由で直接渡してHTMLの出力を生成することができる。

 またベンチマークを実行した際にはテストしたマシンの名前もデフォルトで出力されるが、「-m」オプションを使用すれば、マシン名だけでなくファイルシステムの構成自体についての情報も出力できる。

 Bonnie++では各テストが実行される度に、ベンチマーク工程中の具体的にどのテストが行われているのかを示す行が新しく表示される。そして最後にベンチマーク結果がテキストの表とCSV形式のリストとして表示される。以下に示した結果では、メタデータの読み取り結果も表示されるようにするために「-n 256」を指定してメタデータのテストに使用するファイルの数を増加する必要があった。この「-n 256」というパラメータを指定しなかった場合、連続的な作成/読み取り操作とランダム作成/読み取り操作のどちらもがあまりに短時間で終わってしまうため、「+++++」のみが表示されて、結果の数字が得られない。

$ rm -rf /tmp/foo
$ mkdir /tmp/foo
$ /usr/sbin/bonnie++ -d /tmp/foo
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
chunklog         4G 59330  97 269236  64 109173  31 54711  97 290233  38 509.6   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256  3862  96 342257  98 10759  69  3704  94 339523  98  1771  11
chunklog,4G,59330,97,269236,64,109173,31,54711,97,290233,38,509.6,1,256,3862,96,342257,98,10759,69,3704,94,339523,98,1771,11

 大量のIO操作を行うアプリケーションはほとんどの場合、データの読み書きを文字単位で行うことはないので、データ転送の結果としてはブロック単位の読み取り/書き込み/再書き込みについての結果がもっとも重要だろう。%CPの欄は、各テストでIO操作を行なった際のCPU使用率を示している。またメタデータについてのテストの結果は出力結果の2列目にあって、0バイトの大きさのファイルの作成/(stat(2)経由の)読み取り/削除についての結果が表示されている。メタデータの作成/読み取り/削除のテストでは、ファイル名を数値でソートした順の場合と、ランダムな順の場合とでテストが行なわれる。ファイルシステムの中には、アプリケーションが特定の順でファイルの作成/アクセスを行った場合に性能が高いものもあるが、Bonnie++はメタデータについてのテストを2度行うので、ファイル名順にアクセスする場合に最適化されているのかどうかが分かる。

 Bonnie++の出力の最後の行は、表形式で出力した結果と同じ内容をCSV形式で出力したものだ。Bonnie++のディストリビューションにはPerlスクリプトのbon_csv2htmlが含まれている。bon_csv2htmlはBonnie++が出力したCSV形式を入力として受け付けて、その内容を表示するHTMLページを生成する。以下に、上記のテスト結果のCSV形式の行をパイプでbon_csv2htmlに渡して生成した表を示す。

 Bonnie++ベンチマークは、手元のハードウェアから得られるはずの性能を実際に得ることができているのかを知るために非常に役に立つ。また他の人々が同様のハードウェアを使って生成して公開しているBonnie++の結果も探してみれば、とても参考になるだろう。RAIDの構成やファイルシステムの構成を変更する際には、性能が向上すると期待して行う変更によって、実際に顕著に向上するのかどうかを見極めるために非常に参考になるだろう。

 明日は、変更によるプラスの影響がどれほどあるのかを一目瞭然にするために、ベンチマーク間での相対的な変化を示すグラフをBonnie++の複数の実行結果から生成する方法を紹介する。

Ben Martinは10年以上もファイルシステムに携わっている。博士号を取得し、libferris、ファイルシステム、検索ソリューションを中心としたコンサルティングサービスを提供している。

Linux.com 原文