IOzoneによるファイルシステムのパフォーマンス測定
IOzoneの入手方法だが、openSUSE 10.3ではワンクリックインストールで提供され、Ubuntu Hardyではmultiverseリポジトリにて提供される。また、Fedora 9では標準リポジトリに収録されている。
IOzoneを簡単に起動するには、-aオプションを付けて完全自動モードにするとよい。その際、-gオプションでファイルサイズの上限をシステムのメインメモリサイズの2倍に設定する。
$ time iozone -a -g 4G >|/tmp/iozone-stdout.txt
いずれのオプションでもサイズ値に単位（メガバイトまたはギガバイト）を表す接尾辞のmまたはg（大文字と小文字は区別されない）を付けることができる。標準出力をファイルにリダイレクトすれば、端末のデータをコピーしなくても出力からグラフを生成できる。呼び出しをtimeコマンドでラップして呼び出しの全体にかかった時間を知ることができる。これでIOzoneの実行に相当時間がかかることがわかるので、これ以降の呼び出しについては、関心のある特定の領域だけテストしてすべてのテストが実行されるのを待たなくて済むように呼び出しの方法を調整することになるだろう。6台の750GBのドライブで構成されるハードウェアパリティRAIDに対して上記のコマンドを実行すると数時間かかる。
-nオプションを使用すると、自動モードでのテスト中に使われるファイルサイズの下限を設定できる。通常、テストは64KBのファイルから開始され、そのサイズがテストサイクルごとに倍加されていく。システムバッファのキャッシュに入り切らないような大きなファイルについてだけテストしたいときは、-nオプションでテストの範囲を絞り込むことにより時間を節約できる。また、-gオプションの代わりに-sオプションを使用すると、指定した特定のサイズのファイルについてだけテストが行われる。下記のコマンドでは、テストに4GBのファイルだけが使われ、レコードサイズは4KBから256KBの間で増やされる。
$ time iozone -a -s 4G -q 4 -y 256 >|/tmp/iozone-stdout.txt
IOzoneによるテストでは、読み取り、書き込み、再読み取り、再書き込みなどの単純な測度を初めとして、多くの項目が計測される。読み取りと書き込みについては説明は不要だろう。再読み取りは、最近読み取られたファイルがシステムに適切にキャッシュされるかどうかを表す測度である。再書き込みテストは2種類ある。「単純再書き込み」では既存のファイルが上書きされ、「レコード再書き込み」ではファイル内の特定の場所に何度も書き込みが行われる。
通常の読み取りおよび書き込みテストは、一時ファイルに対してデータをシーケンシャルに読み書きすることで行われる。ランダムな読み取りおよび書き込みテストもあり、その場合は、シーケンシャルな読み書きではなく、一時ファイルの一部分だけが読み書きされる。RAID上に作成されたファイルシステムに対してIOzoneを実行しようと考えておられる方は、ストライド読み取りテスト（-jを参照）に関心があるだろう。ストライド読み取りテストでは、RAIDストライプ境界に整列していないレコードの読み取りでパフォーマンスに不利な条件が生ずるかどうかを知ることができる。たとえば、4台のディスクで構成されるRAID-5では、データはチャンク単位（通常は64KB）に分割されて3台のディスクに書き込まれ、パリティが4台目のディスクに書き込まれる。つまり、ディスク1の先頭はチャンク1、ディスク2の先頭はチャンク2、ディスク3の先頭はチャンク3となり、ディスク4にチャック1～3のパリティが収容される。このチャンク1～3をRAIDストライプと呼ぶ。パリティのチャンクをストライプに含めることもある。チャンクとパリティの順序はストライプごとに変更され、たとえば、2番目のストライプでは、パリティがディスク1に、チャンク4～6がディスク2～4に収容されるようなことになる。ストライプ内のいずれかのチャンクが変更されるとパリティを更新する必要があるので、パリティの保存場所を変化させることは、入出力をRAID内のすべてのディスクに均等化するのに役立つ。通常、アプリケーションは、チャンクまたはストライプ境界にあるレコードを操作しようとする。IOzoneのストライドパラメータを使用すると、RAIDストライプに整列している場合と整列していない場合について読み取り要求のパフォーマンスをテストできる。ストライド読み取りテストでは、指定したストライドオフセットで（つまり指定したバイト数を隔てて）レコードが読み取られるので、ストライドをRAIDチャンクサイズの倍数に設定するとよいだろう。読み取り、書き込み、再書き込み、再読み取りのテストをバッファ付きのfread()およびfwrite()コールで実行するバージョンもある。これらのテストはCライブラリによるパフォーマンス上のボトルネックを調べるのに役立つだろう。
IOzoneにはベンチマークテスト中にデータの読み書きの方法を制御する多くのオプションがあるので、自分のマシンで実際に使おうと考えているアプリケーションに近い方法で入出力要求を生成できる。これらのオプションはIOzone マニュアルにアルファベット順で解説されているが、以下では関係するオプションをそれぞれグループにまとめて説明する。
最初のオプショングループは、IOzoneのベンチマークテストで使用するAPIに関するものである。ところで、メモリマップファイルが好んで使われるのは、ファイルのデータを取得するためにプログラムから明示的にread()関数を実行しなくても、メモリロケーションにアクセスしたときデータが自動的に読み込まれるからである。ただし、メモリマップファイルを使用するプログラマは、大きなメモリマップファイルをランダムな入出力パターンで操作するとき、シーク時間の大きな遅延が生じる可能性があることを承知しておく必要がある。アプリケーションでいつメモリマップファイルを使うべきかについて決まったルールは存在しないし、入出力の基礎となるファイルシステムのパフォーマンス限界がAPIで変化することはない。
-Bオプションは、メモリマップAPIを使用してファイルが操作されるようにする。-Dオプションは、これらのメモリマップファイルについてオペレーティングシステムでデータが非同期に転送されるようにする。-Gオプションは、同期的なメモリマップファイルを使用することを明示的に宣言する。メモリマップ入出力を実行するアプリケーションは、madviseシステムコールを使用して、カーネルにそのアクセスパターンを知らせることができる。これによりオペレーティングシステムのカーネルは、アプリケーションの指定したアクセスパターンに一致するようにキャッシュを調整できる。特別な-+Aオプションは、メモリマップ入出力によるテストの最中にIOzoneからカーネルに対してmadviseをどう実行するかを指定する。-Hおよび-kオプションはベンチマークテストの最中にPOSIXの非同期入出力コールを使うようにするもので、-Hは、さらにオペレーティングシステムの使用したメモリバッファからコピーして非同期入出力要求が処理されるようにする。-Hと-kはどちらも任意の時点で試行される非同期操作の数を引数に取る。-Eオプションは、ベンチマークテストでpread APIが使われるようにする。pread()コールは、read() APIと同様にファイルディスクリプタに作用するが、これにはファイルのどこからデータを読み取るかを示すオフセットがある。
もう1つのオプショングループは、ベンチマークの計測方法に関するものである。-cオプションは、ベンチマークで計測される時間にclose()コールを含める。ディスクへの変更時に遅延が生じるようなファイルシステム（NFSv3など）を使用している場合は、-cオプションを指定した方がファイルシステムのパフォーマンスに関してより公正な評価結果が得られる。-eオプションは、フラッシュコールをベンチマークに含める。データをディスクにフラッシュするために実際に使われるコールは、使用している入出力サブシステムによって異なる。たとえば、ファイルディスクリプタでベンチマークを取るときは、fsyncコールが使われる。ベンチマークテストにおいてフラッシュが意味を持つのは、多くのデータベースシステムでディスクへの書き込みを保証するためにフラッシュが実行されるからである。-oオプションは、ファイルを開くときO_SYNC同期モードを設定してファイルへのすべての書き込みがディスクに直ちにフラッシュされるようにする。
IOzoneは、デフォルトでは現在のディレクトリをベンチマークテストのターゲットのファイルシステムとして使用する。-fまたは-Fオプションで別のロケーションを指定することもできる。-Fは機能的に-fと似ているが、マルチプロセスまたはマルチスレッドのファイルシステムのパフォーマンスをテストするとき、複数のロケーションを指定できる。-Uオプションは、テスト対象のファイルシステムのマウントポイントを指定する。-Uを指定すると、IOzoneは次のテストに移るとき、ファイルシステムのバッファをすべてフラッシュするために、指定されたファイルシステムをいったんマウント解除して再マウントするようになる。
-jオプションは、ストライド読み取りテストで使用されるファイル読み取りのストライドを設定する。ストライド読み取りテストでIOzoneによって読み取られる各レコードは、ストライドのバイト数だけ隔てられる。-qおよび-yオプションは、自動テストモードにおけるレコードサイズの下限と上限を設定する。また、-rオプションを使用すると、-qから-yの範囲でレコードサイズを変化させる代わりに、特定のレコードサイズを指定してテストを行うことができる。-jに渡すパラメータはレコードサイズの倍数なので、RAIDストライプのサイズを渡し、上記のオプションでレコードサイズの範囲を指定すれば、整列した場合と整列しない場合についてのパフォーマンスをテストし、両方の結果を同じグラフに描くことができる。
一連の-iオプションを使用することにより、ベンチマークテスト中に必要なテストを選択的に実行できる。残念ながら、-iオプションが受け付ける引数は数値であり、人間が読めるような可読性の高いオプションを直接渡すことはできない。選択できるテストの多くは、それまでに実行された書き込み（-i 0）テストに依存するので、ファイルはIOzoneによって既に作成され初期化されている。たとえば、読み取り（1）と書き込み（0）のテストだけを実行する場合は、-i 0 -i 1オプションを使用する。各テストの番号は、IOZone –helpの出力に示される。
ベンチマークをマルチプロセスで実行する場合は、-tスループットモードを指定し、作成するスレッドまたはプロセスの数を設定する。-Tオプションは、スループットテストのためのマルチスレッドの作成にPOSIXのpthreadsが使われるようにする。プロセスの代わりにpthreadsを使うことを明示的に宣言できるため、実行しようと考えているアプリケーションのマルチスレッド/マルチプロセスモデルを用いて、IOzoneによる入出力のベンチマークテストを行うことができる。プロセス数の下限を-lオプションで、上限を-uオプションで指定する。
ベンチマークテストのさまざまな段階で遅延を挿入するオプション（-d、-Jbなど）もある。
結果の解釈
IOzoneは、結果をstdout（標準出力）に表形式で出力する。明示的に指定した最小サイズのファイル（自動モードのときはデフォルトで64KBになる）からファイルサイズが大きくなる順に結果が報告される。ファイルサイズごとに、指定したレコードサイズの範囲でレコードサイズが大きくなる順にテストが行われる。
IOzoneパッケージには、gnuplotを用いてIOzoneの表形式の出力からグラフを生成するためのスクリプトが用意されている。これらのgnuplotスクリプトは、Generate_Graphsとgengnuplot.shという名前で呼ばれている。Generate_Graphsは、gengnuplot.shを複数回呼び出して、IOzoneのベンチマークのテストごとにグラフを生成し、それらのグラフをgnuplotで描画すると共にPostScript形式の出力を生成する。Generate_Graphsでは、gnuplotの操作のためにgnu3d.demファイルが使われる。このファイルをカスタマイズすれば、各グラフのPNGビットマップイメージを生成したり、グラフが対話的に表示されないようにしたりできる。gnu3d.demを変更して、PNGファイルが非対話的に表示されるようにするには、次のようにすればよい。
set zlabel "Kbytes/sec"
set data style lines
set dgrid3d 80,80,3
#splot 'write/iozone_gen_out.gnuplot' title "Write performance"
set terminal png
set output "write/write.png"
splot 'write/iozone_gen_out.gnuplot' title "Write performance"
#pause -1 "Hit return to continue"
図1は、ハードウェアパリティRAIDの再書き込みのパフォーマンスを示している。チャンクサイズは256KBで、RAIDは6台の750GBディスクで構成され、64KBから4GBの範囲のファイルに対してテストを行っており、メインメモリのサイズは2GBである。このベンチマークテストでは、前述の最初のiozoneコマンドを使用している。なお、レコードサイズが256KBを超えない間の方がパフォーマンスが高いことに注意されたい。これはRAIDではチャンクサイズよりも小さな変更に対して、読み取り-変更-書き込みが1サイクルで実行されるためと思われる。グラフの手前部分の落ち込みは、-aオプションにより一定以上小さなレコードと大きなファイルでテストが行われないようになっていることが影響している。
図2は、同じハードウェアおよびファイルシステム構成のときの書き込みパフォーマンスを示している。このベンチマークで特に目立つのは、一定以上大きなレコードに対して平面に少し落ち込みが見られることである。これはファイルサイズに関して約16KB、レコードサイズに関して256KBから4MBの範囲の領域で生じている。これはデータ収集中に異常が生じたか、システムのコンポーネントの中に、このファイルおよびレコードサイズにおいて十分なパフォーマンスを発揮しないものがあることを示唆している。これよりも大きなファイルについては、レコードサイズが小くなるとパフォーマンスが向上する。ただし、システムキャッシュと比較してファイルサイズがある程度以上大きくなると（ファイルサイズ軸の4.19と表記されている付近より右の部分）パフォーマンスが落ち込み、レコードサイズによる変化がそれほど見られなくなる。
IOzoneでは、操作の対象となるファイルサイズの範囲と、それらのファイルのテストに使用するレコードサイズの範囲を指定できる。それに加え、テストの入出力を実行するオペレーティングシステムのAPIコールを選択できるため、入出力のパフォーマンスを改善したいと考えているアプリケーションに近いAPIを選択できる。また、読み取り、書き込み、再書き込み、再読み取りなどのパフォーマンス統計を3Dグラフ化することで、システムを全体的に見たときに十分なパフォーマンスが発揮されていない領域を発見することができる。たとえば、RAIDコントローラによっては、レコードサイズが一定の大きさ以下のときに、他のレコードサイズのときよりも高いパフォーマンスを示すことがあり、IOzoneを使用すると、そのパフォーマンスの落ち込みをグラフで確認することができる。
IOzoneでは、Bonnie++のように単に読み取り、書き込み、再書き込みの数値を計測するだけでなく、それ以上の詳細な入出力パフォーマンスの情報を得ることができる。ファイルサイズとレコードサイズ、入出力要求を発行するAPI、その他のさまざまなパラメータを変化させたとき、入出力パフォーマンスがどのように推移するか調べることができる。Bonnie++では、かなり短時間のテストでパフォーマンスのよい標識が得られる。Bonnie++の数値に問題が見られないときIOzoneを実行するとよい。通常、IOzoneで入出力パフォーマンスのより詳細な情報を得るには2時間から4時間ほどかかる。
Ben Martinは、ここ10年以上ファイルシステムに取り組んできた。博士号を取得し、現在はlibferris、各種ファイルシステム、検索ソリューションを中心にコンサルティングサービスを手がけている。
図2 ハードウェアパリティRAIDの書き込みのパフォーマンス
まとめ
