作成日：2012.05.02
UNIX 系 OS のファイルシステムの計測を行うベンチマーク。 x86-64/Linux で動作することを検証している。
更新履歴
(2012.05.02) 作成
プリミティブ計測型のベンチマーク
プリミティブ計測型のベンチマークと呼んでいるものは、ファイルシステムの READ/WRITE 性能を単純に計測するベンチマークである。
IOzone
おそらく一番メジャーなファイルシステムのベンチマーク。 単純なファイルアクセスを行い Excel のグラフが出力できるのが特徴。
現在も開発が進められておりファイルシステムの冗長性除去(dedup)のテスト機能なども持っている。
Flexible IO Tester (fio)
13 種類の I/O エンジンを切り替えることが可能なファイルシステム。
モデル記述言語でジョブを記述しそれを実行することも可能だが、プリセットのジョブは多くない。 また記述能力も低い。 ただしプリセットのジョブに IOmeter File Server Access Pattern がある。 そのため iometer を流す替りにこのベンチマークを流すのは、マイクロベンチマーク以上、アプリケーションワークロード以下の中量級のテストにはなると思われる。
またファイルシステム以外にブロックデバイスの計測も可能としている。
インストール
libaio-devel package が必要。
$ tar xzvf fio-1.50.tar.gz $ cd fio-1.50/ $ make $ su # make install
計測例
実行コマンドは fio で、カレントディレクトリの計測を行う。
単純な read/write の計測を行う場合、以下のように記述する。
fio --filename=/dev/sdb --direct=1 --rw=randwrite --bs=1m --size=5G --numjobs=4 --runtime=10 --group_reporting
- --filename にはファイル名か /dev/sdb や /dev/sdb1 のようなブロックデバイスを指定する。
- --direct=1 は O_DIRECT アクセスでの計測を行う場合に指定する。--direct 以外に --ioengine で I/O 操作の方法を指定する。
- --size は計測に使うファイルのサイズを指定する。これが --numjobs の数だけ生成される。ブロックデバイスを指定した場合には、先頭からどの位置までをアクセスするかの指定として使える。
- --bs は1回のアクセスに使う幅を指定する。
- --rw には read(sequential reads)、write(sequential reads)、randerad(random reads)、randwrite(random writes)、rw(mixed sequential reads and writes)、randrw(mixed random reads and write)が指定できる。
ワークロードを指定した計測を行いたい場合には以下のように指定する。
$ fio (展開ディレクトリ)/fio-1.50/examples/iometer-file-access-server
Bonnie++
Bonnie++ はデータの読み書きを行う速度、1秒間に行うことのできるシークの回数、1秒間に行うことのできるファイルのメタデータの操作回数という3つの項目についてのベンチマークが可能だ。 メタデータ操作には、ファイルの作成/削除と、ファイルの大きさや所有者などのメタデータ（fstat(2) システムコールの結果）の取得とがある。
Bonnie++ もブロックデバイスに対する性能測定を行うことができる。
AIO-Stress
未検証。
Threaded I/O Tester
未検証。
ワークロード計測型のベンチマーク
ワークロード計測型のベンチマークは「Web サーバのアクセスを模す」「メールサーバを模す」等、実際の計算機のワークロードを仮定したベンチマークである。
SPECsfs2008 をのぞくと、オープンソースまたはソース公開がされたベンチマークである。
Filebench
Workload Model Language (WML) という記述言語でワークロードを定義できるベンチマーク。 単純な READ/WRITE 性能を測るのでは
Fedora では filebench という名前でパッケージ化されている。
プリセットのワークロード 以下のようなアプリケーションモデルがプリセットされている。
- varmail (メールサーバを模したエミュレーション。Posmarkベンチを模している)
- fileserver (SPECsfs を模したワークロード)
- oltp (データベースの動作を模したモデル)
- dss (DSS Database を模したモデルだが、開発中らしい)
- webserver (静的コンテンツの Web サーバのモデル。アクセスログを書き出す)
- webproxy (webserver に加えてコンテンツをキャッシュするためにディスクへ書き込む。)
他に特定のファイル操作向けのマイクロベンチマークがある。
- copyfiles (大きな多階層ディレクトリツリーのコピー)
- createfiles (多階層ディレクトにファイルを作成する)
- randomread (単一の巨大ファイルをランダムにブロックリード)
- randomwrite (単一の巨大ファイルをランダムにブロックライト)
- singlestreamread (シーケンシャルリード)
- singlestreamwrite (シーケンシャルライト)
- multistreamread (4個のファイルを同時にシーケンシャルリード)
- multistreamwrite (4個のファイルを同時にシーケンシャルライト)
- makedirs
- listdirs
- removedirs
Workload model language
Workload model language ファイルに対して write、read、openfile、createfile、closefile、makedir、removedir、listdir、fsync、fsyncset (操作中の全てのファイルに対してfsync)、statfile、readwholefile、appendfile、appendfilerand、deletefile、writewholefile の操作をフローとして記述できる。
また制御構文として先行する処理を待ったりウェイトを入れたりすることが可能。 ただし workload model language は条件構造がないようなので、例えば「例えばファイル操作が失敗した場合には〇〇する」ようなワークロードは記述できないと思われる。
計測例
filebench> load varmail 8395: 3.898: Varmail personality successfully loaded 8395: 3.899: Usage: set $dir=<dir> 8395: 3.900: set $filesize=<size> defaults to 16384 8395: 3.900: set $nfiles=<value> defaults to 1000 8395: 3.901: set $dirwidth=<value> defaults to 20 8395: 3.901: set $nthreads=<value> defaults to 1 8395: 3.902: set $meaniosize=<value> defaults to 16384 8395: 3.902: run <runtime> filebench> set $dir=/tmp filebench> run 10
FS-Mark
$ ./fs_mark -d ${DIR1} -d ${DIR2} -s 51200 -n 4096
1000 Files, 1MB Size, No Sync/FSync
$ ./fs_mark -d /tmp/test/ -s 1048576 -n 1000
$ /home/nminoru/tmp/fs_mark-3.3/fs_mark -d . -s 1048576 -n 1000
# /home/nminoru/tmp/fs_mark-3.3/fs_mark -d . -s 1048576 -n 1000
# Version 3.3, 1 thread(s) starting at Wed Mar 23 10:43:12 2011
# Sync method: INBAND FSYNC: fsync() per file in write loop.
# Directories: no subdirectories used
# File names: 40 bytes long, (16 initial bytes of time stamp with 24 random bytes at end of name)
# Files info: size 1048576 bytes, written with an IO size of 16384 bytes per write
# App overhead is time in microseconds spent in the test not doing file writing related system calls.
FSUse% Count Size Files/sec App Overhead
5 1000 1048576 35.7 14485
PostMark
PostMark は NetApp 社が作成した "短命でサイズの小さいファイルを多数扱うプログラム"の性能を評価するために作られたベンチマークで、主にインターネットサーバプログラムの性能を想定。
もともと NetApp のサイトで公開されていたが、現在は該当ページが消失している。 インターネット上にはファイルが残っているものの、管理者が不明なベンチマークになっている。
DBENCH
Samba の性能測定のために用意されたベンチマーク。 ただし CIFS を直接話すのではなく、ローカルディスク上の指定のディレクトリに対してファイルを作成して操作を行う。
操作内容は client.txt に記述されたモデルに従う。 モデルは 1 種類だけで、その処理内容はよく分からない。 ただしモデル記述のフォーマット等が文書化されておらずモデルを書き換えるのは難しい。
誤った操作に対してエラーが返ってくることを期待するテストなどもあり、GlusterFS など完全な POSIX 準拠をしていないファイルシステム上で実行するとエラーで停止することもある。
インストール
$ ./autogen.sh $ ./configure $ make $ su # make install
計測例
クライアント数を指定して実行する(例では 20 クライアントを指定)。 計測完了までに 7 分程度かかる。
$ dbench 20
出力結果の例である。
Operation Count AvgLat MaxLat ---------------------------------------- NTCreateX 4498119 0.017 636.233 Close 3304249 0.001 0.976 Rename 190433 0.209 1162.427 Unlink 908273 0.070 3484.869 Deltree 122 24.244 1863.425 Mkdir 61 0.002 0.004 Qpathinfo 4076942 0.010 3.363 Qfileinfo 714768 0.001 0.940 Qfsinfo 747517 0.133 8.761 Sfileinfo 366253 0.006 1.203 Find 1576307 0.046 3.553 WriteX 2244118 0.480 11318.286 ReadX 7050663 0.003 2.774 LockX 14650 0.002 0.037 UnlockX 14650 0.001 0.267 Flush 315236 33.155 15219.476 Throughput 235.67 MB/sec 20 clients 20 procs max_latency=15219.482 ms
SysBench
未検証。
Flexible Filesystem Benchmark (FFSB)
これもワークロードのモデルを記述するベンチマーク。 調査中だがモデルの記述能力は filebench の方が高いようだ。
Iometer
Intel が作成したファイルベンチマークで実アプリ Dynamo と呼ばれる負荷発生器とそれを操作する GUI部分に分かれており、それぞれを別のマシンに配置することができる。 Dynamo は Windows、Linux、Solaris、MacOS X などに対応している。 GUI 部分は Windows でしか動作しない。
負荷発生器の dynamo は複数のサーバに配置し同時に負荷をかけることができる。 そのため分散ファイルシステムの負荷性能試験にも使える。
商用のストレージシステムなどの評価にも使われるベンチマークで、他のベンチマークが「Iometer ライクなワークロードを生成する」という機能を持つようにかなり権威があったようだ。 現在はあまりメンテナンスされていない。
現在はオープンソースとして公開されている。
SPECsfs2008
計算機の標準ベンチマークを策定している SPEC(Standard Performance Evaluation Corporation) のネットワークファイルシステム向けのベンチマーク。 NFSv3 と CIFS の性能を測定できる。 SPECsfs2008 以前に SPEC SFS93 と SPEC SFS97 もあった。
ベンチマークはソースコードの配布(有償)で配布され、ビルド環境は自前で作成する必要がある。
商用ストレージシステムの評価にも使われる非常に権威のあるベンチマークだが、ソースの入手等が難しいため一般の人が使うのは困難だ。
一般的なテクニック
ディスクキャッシュの開放
ファイルシステムはアクセスをする度にメモリ上にディスク内容のキャッシュを載せてゆく。 そのためベンチマークを繰り返し実行するとキャッシュ分だけ性能が上がってゆくことがある。
これを防ぐにはベンチマークを行う前にファイルシステムをアンマウント→マウントをし直すか、ディスクキャッシュのフラッシュを行う必要がある。
ディスクキャッシュのうち「ページキャッシュ」はファイルの ページキャッシュだけを開放するには以下のように実行する。
echo 1 > /proc/sys/vm/drop_caches
ディスクキャッシュのうち「dentry」、ディレクトリのエントリ情報に関するキャッシュだけを開放するには以下のように実行する。
echo 2 > /proc/sys/vm/drop_caches
ディスクキャッシュのうちページキャッシュと dentry の両方を開放するには以下のように実行する。
echo 3 > /proc/sys/vm/drop_caches
マウントオプション
- NFS のマウントには tcp、noac(client cache off)、actimeo=0 をしてする。
- EXT4 のマウントには rw,relatime,barrier=1 を指定する。また data=journal と data=ordered で動作が変わるので注意。
SSD の初期化
HDD の性能を測定する場合、パーティションのファイルシステムを切り直して初期化をする。 SSD の性能を測定する場合はファイルシステムの切り直しだけではなく、切り直しを行う領域に TRIM を発行する必要がある。
初期化する SSD が /dev/sdc の場合は以下のようにする。 62500000 はディスクの総セクタ数を、40000 は 65535 以下の適当な幅を指定する。
# i=0; while [ $i -lt 62500000 ]; do echo $i:40000; i=$(((i+40000))); done | hdparm --trim-sector-ranges-stdin --please-destroy-my-drive /dev/sdc
CPU のバインド
ファイルシステムに関するベンチマークではそれほど重要ではないが、ベンチマークプロセスが CPU を移動すると性能に影響する場合には CPU のアフィニティをとると有効な場合がある。
既存のプログラムで CPU アフィニティをとるには taskset コマンドを用いる。
taskset -c 1 dd if=/dev/zero of=/dev/fioa bs=4096 count=262144
ベンチマーク自身がマルチスレッドやマルチプロセスの場合、このコマンドを用いると稼動できる CPU が制限されて性能が出ないこともあるので注意。
ファイルベンチマークがまとめられているサイト
- File and Storage System Benchmarking Portal
- Files systems tools tests suites
- OpenBenchmarking.org
- Phoronix Test Suite
- Phoronix | Large HDD/SSD Linux 2.6.38 File-System Comparison: EXT3, EXT4, Btrfs, XFS, JFS, ReiserFS, NILFS2
- Phoronix | Benchmarks Of ZFS-FUSE On Linux Against EXT4, Btrfs
- つれづれ | ベンチマークツールdebenchを使用したディスク性能の評価
TOP