ネットワーク/ストレージの処理能力をチェックするためのベンチマークツール

サーバー上でさまざまなサービスを構築する前に、そのサーバーの処理能力を把握しておくことは重要だ。特にネットワークの帯域やストレージの速度といったリソースはサービスの品質に大きく関わってくる。そこで、今回はこれらの性能を調査するためのベンチマークツールやその使い方を紹介する。

ネットワークの性能を調査するベンチマークツール

まずはネットワーク関連の性能を調査するベンチマークについて紹介しよう。ネットワークの性能といっても、その指標は次のように複数ある。

スループット（速度、帯域幅）
レイテンシ（遅延）
パケットロス（損失パケット）

まず1つめは、スループット（ネットワークの速度）だ。帯域幅などとも呼ばれるが、ネットワークの性能としてもっとも重視されるのはこれだろう。ネットワークの速度が早ければそれだけ多くの情報をやり取りできるし、またより多くの接続に対して迅速に反応できるようになる。通常スループットは毎秒あたりやり取りできるビット数（bps）もしくはバイト数（B/秒、B/s）で示される。

2つめは、「レイテンシ」「遅延」などと呼ばれるものだ。広義にはネットワークの片端から送信されたパケットがもう片端に到達するまでにかかる時間を意味するが、通常はパケットを送信してからその到達確認パケットを受信するまでの時間（Round Trip Time、RTT）で計測されることが多い。レイテンシが大きい場合、アプリケーションの反応が遅くなったり、ネットワーク帯域を十分に生かせなくなる可能性がある。なお、レイテンシはその通信経路およびその間の機器によって変動することがあり、そのブレは「ジッタ」と呼ばれる。

3つめは、損失パケット（パケットロス）の発生率だ。損失パケットというのは、送信したパケットのうち途中で消失して相手に届かなかったパケットの割合を示すものだ。現在の有線ネットワークでは通常あまり発生しないが、無線ネットワークの場合はそれなりに発生する。

ネットワーク関連の計測ツールはいくつかあるが、ツールによってはこれら指標の一部しか計測できない場合もある。その場合、目的に応じて複数のツールを組み合わせて利用することになる。

nuttcp

　そのうち、サーバーで利用しやすいのはクライアント版だろう。ソースコードはGoogle Codeのndtプロジェクトで公開されているが、バイナリなどは用意されていないので自分でビルドを行う必要がある。その場合、プロジェクトで公開されているtar.gz形式のソースアーカイブには単体ではクライアントのみのビルドができないという不具合が残っているので、以下のようにしてSubversion（svnコマンド）を使ってソースコードリポジトリから最新版をダウンロードする必要がある。

$ svn checkout http://ndt.googlecode.com/svn/trunk/ ndt

これで、ndtディレクトリに最新のソースコードが格納される。ただし、このソースコードには依存するI2utilライブラリが含まれていない。このライブラリはアップストリームでの配布が終了しているようなので、以下のようにしてGoogle Codeで公開されているndtのソースアーカイブ内に含まれているものをコピーして利用する。

$ wget https://ndt.googlecode.com/files/ndt-3.6.5.1.tar.gz
$ tar xvzf ndt-3.6.5.1.tar.gz
$ cd ndt
$ cp -r ../ndt-3.6.5.1/I2util .

そのほか、zlibのヘッダーファイル（「zlib-devel」など）や「automake」、「autoconf」といったパッケージも必要だ。これらも適切にインストールしておこう。必要なライブラリなどがそろったら、次のようにしてビルドを実行できる。

$ ./bootstrap
$ ./configure
$ make

ビルドが完了すると、srcディレクトリ内に「web100clt」という実行ファイルが作成される。これがndtのクライアントとなる。「-help」オプションを付けて実行するとコマンドラインオプション一覧が表示されるので、チェックしておこう。

$ cd src
./web100clt -help

web100cltコマンドでテストを実行するには、「-n」オプションに続けてNDTサーバーを指定する。NDTサーバーはNDTのWebサイトに一覧が掲載されているほか、perfSONARというWebページからも検索できる（図2）。

また、それ以外にもNDTサーバーを公開しているところがある。たとえば国内ではAPAN（アジア太平洋先端ネットワーク）の日本支部であるAPAN-JPや、東京大学素粒子物理国際研究センター (ICEPP)などがサーバーを公開している。

たとえば、APAN-JPのNDTサーバーである「nms1.jp.apan.net」を利用してスループットを測定するには、次のようにする。

$ ./web100clt -n nms1.jp.apan.net
Testing network path for configuration and performance problems — Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 73.17 Mb/s
running 10s inbound test (server to client) . . . . . . 72.70 Mb/s
sending meta information to server . . . . . Done
The slowest link in the end-to-end path is a a 622 Mbps OC-12 subnet
Information: Other network traffic is congesting the link
Server ‘nms1.jp.apan.net’ is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]
Information: Network Middlebox is modifying MSS variable (changed to 1414)
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client’s IP address
Server says [***.***.***.**] but Client says [ ***.**.*.**]

この例では、クライアントからサーバーの速度は73.17Mb/秒、サーバーからクライアントの速度は72.70Mb/秒であることが分かる。なお、公開されているNDTサーバーは研究用として提供されているため、サーバーが停止していたり、また廃止される場合などもあるため注意したい。バックボーンネットワークもサーバーによって異なるので、実行する時間帯などによって結果が変動する可能性もある。あくまで参考程度として利用して欲しい。

pingコマンドでレイテンシとパケットロスを測定する

ネットワークの状況を調べるツールとして、もっとも有名と思われるpingコマンドについても簡単に説明しておこう。pingコマンドでは「ICMP（Internet Control Message Protocol）」と呼ばれるプロトコルで定義されている「ECHO Request」パケットを送信し、このパケットを受信した端末が送信元に対し「Echo Reply」パケットを送信する、という動作で送信元から送信先までのネットワークが正しく接続されているかを確認する。このとき、pingコマンドの実行結果にはパケットが相手に到達しているかといった情報だけでなくレイテンシも表示される。

たとえば、以下の例はexample.comに対しpingコマンドを実行した例だ。ここで、「time=」に続いて表示されているのがレイテンシ（RTT）となる。この例の場合、パケットを送信してからその反応が返ってくるまでおおむね113ミリ秒（約0.1秒）程度の時間がかかっていることになる。また、5回パケットを送信して5回ともその返答を受信しており、パケットロスは0％であることが分かる。

$ ping example.com
PING example.com (192.0.2.1) 56(84) bytes of data.
64 bytes from example.com (192.0.2.1): icmp_req=1 ttl=52 time=113 ms
64 bytes from example.com (192.0.2.1): icmp_req=2 ttl=52 time=113 ms
64 bytes from example.com (192.0.2.1): icmp_req=3 ttl=52 time=113 ms
64 bytes from example.com (192.0.2.1): icmp_req=4 ttl=52 time=113 ms
64 bytes from example.com (192.0.2.1): icmp_req=5 ttl=52 time=113 ms
^C
— example.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 113.123/113.342/113.741/0.253 ms

ストレージの性能を調査するベンチマークツール

続いて、ストレージの性能を調査するためのベンチマークツールについて紹介しよう。ストレージ性能の評価基準としては、まず読み書き速度が挙げられる。ただ、ネットワークの場合とは異なり、多くのストレージではアクセスのしかたによってそのパフォーマンスが異なる。一般的にもっともパフォーマンスが高いのが、「シーケンシャルアクセス」という、連続したデータを一気に書き込むようなアクセスだ。いっぽう、小さいデータをさまざまな個所に書き込むような「ランダムアクセス」はシーケンシャルアクセスよりもパフォーマンスが落ちることが多い。ベンチマークツールにはシーケンシャルアクセスのみの性能測定しかできないものもあるので、目的に応じて使用するベンチマークツールを選択する必要がある。

ベンチマークツールとしてよく知られているものとしては、表1が挙げられる。

表1 ストレージ向けの代表的なベンチマークツール
ツール名	説明
hdparm	本来はSATA/IDEデバイスのパラメータ設定ツールだが、デバイスの読み込み速度を測定するベンチマーク機能がある
Bonnie++	ファイルへのI/O速度と、ファイルの作成/メタデータ取得/削除速度を測定するツール（解説記事）
dbench	ユーザーが定義したI/O処理を実行してその速度を測定するツール
fs_mark	指定したサイズのファイルを指定した数だけ作成し、その速度を測定するツール
tiobench	複数スレッドから同時にファイルシステムにアクセスし、その速度を測定するツール
IOzone	ファイルサイズなどの実行条件を変えながらファイルシステムにアクセスし、その速度を測定するツール（解説記事）
fio	指定した条件でファイルシステムにアクセスし、その速度を測定するツール（解説記事）

今回はこのうち、多くの環境で簡単に利用できるhdparmコマンドと、多機能かつ簡単に実行できるBonnie++、過去にSourceForge.JP Magazineで取り上げていないfs_markおよびtiobenchについてその使い方を紹介する。

なお、ストレージの性能を調査する際に注意が必要なのが、ほぼすべてのファイルシステムでメモリを使ったキャッシュが行われている点だ。Linuxでは、空きメモリを積極的にファイルシステム用のキャッシュとして利用するような仕組み（ページキャッシュ）が使われている。そのため、ファイルシステム上でファイルの読み書きを行うベンチマークツールの場合、キャッシュによってストレージ本来の性能以上の結果が出てしまう可能性がある。キャッシュの影響を小さくするためには、テストに使用するファイルの総サイズを搭載する物理メモリの総量よりも大きくすれば良い。ベンチマークツールによって異なるが、搭載物理メモリの2倍程度が目安と言われている。また、Linuxの場合、起動時のカーネルパラメータで「mem=＜メモリ容量＞」というオプションを指定することで、使用するメモリ量を制限できる。これを利用して、ベンチマークテスト時にはあえて利用できるメモリ容量を少なくする場合もある。たとえば搭載しているメモリのうち256MBのみを使用するには、起動時に以下のようなカーネルオプションを指定すれば良い。

mem=256M

簡易的にベンチマークを実行できるhdparmコマンド

ストレージの読み込み速度を簡易的に調べるには、hdparmコマンドを利用できる。hdparmコマンドは元々はSATA/IDEデバイスの設定パラメータを確認・変更するためのツールなのだが、「-t」および「-T」オプションを利用することで読み込み速度を調査できる簡易的なベンチマークテストを実行できる。「-t」オプションではキャッシュなし読み込み速度を、「-T」オプションではキャッシュ付き読み込み速度の測定が可能だ。どちらの場合も、実行にはroot権限が必要となる。

たとえば、「/dev/sda」のキャッシュなし読み込み速度を測定するには次のようにする。

# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 90 MB in 3.05 seconds = 29.47 MB/sec

この場合、読み込み速度は29.47MB/秒となっている。また、同じデバイスに対しキャッシュ付き読み込みでテストを行った結果が次の例だ。

# hdparm -T /dev/sda

/dev/sda:
Timing cached reads: 18232 MB in 2.00 seconds = 9129.84 MB/sec

この場合、キャッシュの効果によって9129.84MB/秒という非常に高速な結果が得られている。

Bonnie++

表2 bonnie++で実行されるテスト
シーケンシャル書き込み	文字単位での書き込み（Per-Character）	putc()関数を使って1文字づつファイルを書き込む
ブロック単位での書き込み（Block）	writeシステムコールを使ってブロック単位でファイルの書き込みを行う
上書き（Rewrite）	readシステムコールでファイルを読んだのち、writeシステムコールでそこにデータを上書きする
シーケンシャル読み込み	文字単位での書き込み（Per-Character）	putc()関数を使って1文字づつファイルを書き込む
ブロック単位での書き込み（Block）	writeシステムコールを使ってブロック単位でファイルの書き込みを行う
ランダムシーク（Random Seeks）	lseek()関数をランダムな値を指定して連続実行してその処理速度を調査する
シーケンシャルなファイル処理	作成（Create）	7桁の数字からなるファイル名を持つファイルを作成し、番号順にファイルの作成、読み込み、削除を行う
読み込み（Read）
削除（Delete）
ランダムなファイル処理	作成（Create）	ランダムなファイル名を持つファイルを作成し、ランダムにファイルの作成、読み込み、削除を行う
読み込み（Read）
削除（Delete）

fs_mark

fs_markは、ファイルシステム上に多数のファイルを作成して読み取りや削除、メタデータの取得といった操作を行い、その処理にかかった時間を測定するというベンチマークツールだ。bonnie++にも似たようなテスト項目があるが、fs_markは作成するファイルのサイズやファイル数などを簡単に指定できるのが特徴となる。

Debian 7.0（wheezy）以降のDebianでは、「fsmark」という名称でパッケージが提供されている。また、RHELやその互換ディストリビューション向けにはEPELからfs_markという名称のパッケージが提供されている。

manページは用意されていないが、-helpオプションで簡易的なオプション一覧を確認できる。それぞれのオプションの詳細についてはREADME（/usr/share/doc/fs_mark-3.3/以下などにインストールされる）に記載されているが、そのうち必須なのはテストに使用するディレクトリを指定する-dオプションだ。そのほか、よく使われるパラメータとしては、作成するファイルの数を指定する-nオプションと、作成する1ファイル当たりのサイズを指定する-sオプションがある。たとえば次の例は、カレントディレクトリで1MB（1024×1024＝1048576B）のファイルを1024個作成するテストを実行するものだ。

$ fs_mark -d . -n 1024 -s 1048576

# fs_mark -d . -n 1024 -s 1048576
# Version 3.3, 1 thread(s) starting at Thu Aug 29 18:27:19 2013
# 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
10 1024 1048576 9.4 19055

この例では、1秒あたり9.4ファイルの書き込みが実行できたことになる。1ファイルのサイズは1MBなので、スループットとしては9.4MB/秒程度となる。

また、vオプションを付けるとより詳細な実行結果が表示される。

$ fs_mark -d . -n 1024 -s 1048576 -v

# fs_mark -d . -n 1024 -s 1048576 -v
# Version 3.3, 1 thread(s) starting at Thu Aug 29 18:31:49 2013
# 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.
# All system call times are reported in microseconds.

FSUse% Count Size Files/sec App Overhead CREAT (Min/Avg/Max) WRITE (Min/Avg/Max) FSYNC (Min/Avg/Max) SYNC (Min/Avg/Max) CLOSE (Min/Avg/Max) UNLINK (Min/Avg/Max)
10 1024 1048576 9.3 19144 28 55 2706 7 14 118 90939 106042 178190 0 0 0 4 6 27 151 160 338

-vオプションを付けた場合、ファイルの作成（CREAT）およびデータの書き込み（WRITE）、メモリバッファからストレージへの書き出し（FSYNC）、キャッシュのストレージへの書き込み（SYNC）、ファイルのクローズ（CLOSE）それぞれにかかった最小（Min）/平均（Avg）/最大（Max）の時間がミリ秒単位で表示される。この例の場合、メモリバッファからストレージへの書き出しを行うFSYNC処理中でもっとも時間がかかっていることが分かる。

tiobench

tiobenchは、複数のスレッドから同時にファイルシステムにアクセスしてその場合のスループットを測定するベンチマークツールだ。tiotestとtiobenchという2つのベンチマークコマンドが用意されており、tiotestコマンドがベンチマークツール本体で、tiobenchはパラメータを変えながらtiotestを呼び出すラッパープログラムとなっている。

Debianでは、「tiobench」という名称でパッケージが提供されている。RHELやその互換ディストリビューション向けには、EPELからtiobenchという名称のパッケージが提供されている。

tiotestを引数無しで実行すると、シーケンシャルリードおよびシーケンシャルライトでは各スレッドごとに10MBのファイルを読み書きして測定し、またランダムリードおよびランダムライトでは各スレッドごとに4096Bのデータを1000回読み書きして測定を行う。デフォルトでは4スレッドを使用するよう設定されているので、シーケンシャルリード/ライトでは計40MB（10MB×4）、ランダムリード/ライトでは計16MB（4096B×1000×4）分の読み書きが行われることになる。実行結果は次のように表形式で出力され、スループット（Rate）およびレイテンシが表示される。

$ tiotest
Tiotest results for 4 concurrent io threads:
,———————————————————————-.
| Item | Time | Rate | Usr CPU | Sys CPU |
+———————-+———-+————-+———-+———+
| Write 40 MBs | 1.7 s | 23.613 MB/s | 4.8 % | 13.5 % |
| Random Write 16 MBs | 5.9 s | 2.663 MB/s | 1.2 % | 1.6 % |
| Read 40 MBs | 0.0 s | 10124.019 MB/s | 0.0 % | 1619.6 % |
| Random Read 16 MBs | 0.0 s | 11306.078 MB/s | 0.0 % | 2025.8 % |
`———————————————————————-’
Tiotest latency results:
,————————————————————————-.
| Item | Average latency | Maximum latency | % >2 sec | % >10 sec |
+————-+—————-+—————-+———-+———-+
| Write | 0.003 ms | 0.014 ms | 0.00000 | 0.00000 |
| Random Write | 0.002 ms | 0.015 ms | 0.00000 | 0.00000 |
| Read | 0.001 ms | 0.019 ms | 0.00000 | 0.00000 |
| Random Read | 0.001 ms | 0.010 ms | 0.00000 | 0.00000 |
|————-+—————-+—————-+———-+———-|
| Total | 0.002 ms | 0.019 ms | 0.00000 | 0.00000 |
`————-+—————-+—————-+———-+———-’

シーケンシャルライト/リードのテストで使用するファイルファイズは、-fオプションで変更できる。たとえば1スレッドあたり25MB（4スレッドで100MB）にしたい場合、「-f 25」と指定すればよい。また、スレッド数は-tオプションで指定可能だ（デフォルトは4）。ランダムライト/ランダムリードのテストで使用するファイルサイズは-bオプション（1回のアクセスで実行するバイト数）および-rオプション（実行するアクセス回数）と-tオプション（スレッド数）の値の積で決定され、デフォルトではそれぞれ4KB（4096）、1000、4が使われる（総サイズは4096B×1000×4で16MBとなる）。たとえば総サイズを40MBにしたい場合、アクセス回数を2.5倍に指定すればよいので「-r 2500」と指定すればよい。

ベンチマークテストを実行する際はその結果の「ブレ」にも注意

ここまで複数のベンチマークテスト用ツールを紹介してきたが、これらを利用する際に注意してほしいのが「結果のブレ」だ。PCやサーバー上では複数のプログラムが同時に稼働しているため、ベンチマーク結果は状況によって変動する。また、ネットワークの速度は外的要因によっても大きく変化する。そのため、ベンチマークテストを行う際はテストを複数回実施して結果を比較したうえで評価することをおすすめする。ベンチマークツールによっては複数回のテストを実行する機能を持っているものもあるので、うまく利用すると良いだろう。

ネットワーク/ストレージの処理能力をチェックするためのベンチマークツール

ネットワークの性能を調査するベンチマークツール

nuttcp

Network Diagnostic Tool（NDT）

pingコマンドでレイテンシとパケットロスを測定する

ストレージの性能を調査するベンチマークツール

簡易的にベンチマークを実行できるhdparmコマンド

Bonnie++

fs_mark

tiobench

ベンチマークテストを実行する際はその結果の「ブレ」にも注意

この記事の筆者

松島浩道

バックナンバー

この記事を読んだ人は、こんな記事も読んでいます

この記事についてコメントする

サービス情報

サポート情報

企業情報

その他