オルタナティブ・ブログ > ニフティクラウド活用Tips >

ユーザーと中の人が語るクラウド活用Tipsを、クラウド女子がお届けします。

【速報】噂の新追加ディスクDisk200の「本当の性能と向き合えますか?」

»

こんにちは、ちなつです。

本日は、9/13に公開されたばかりの新増設ディスクDisk200のベンチマークについて、仲山氏の検証記事を紹介します。

Disk200はI/O性能が従来のDisk100に比べて大幅に向上しているので、ディスクアクセスのレスポンスの違いを実感いただけると思います。
ぜひDisk200を利用してみてください。

(*本記事の最後に仲山氏のプロフィールを掲載しています)

*********************************************************************

こんにちは、株式会社エクストーンの仲山です。
新しい増設ディスクサービス「Disk200」 がリリースされたということで、速報としてユーザサイドで取得したベンチマークを紹介します。

なにはともあれグラフ

Throughput_graph_2

赤い棒グラフがスループットです。
測定結果を見てベンチマークのパラメータを何度も疑ったぐらい、
正直いって今までのDisk100とは何だったのか、というぐらい速く早くなったようです

以下にベンチマークの取り方を書きますので、皆さんも自分でも測定してみてください。

ベンチマーク対象

今回は、以下の3台を測定対象としました。

                                       
サーバサーバ種別追加ディスクOS備考
測定用サーバニフティクラウド
large
Disk40
Disk200A
Disk200B
CentOS 5.6 Plain (64bit) 今回の測定用に新しく作成したサーバです。
Disk100用サーバニフティクラウド
large
Disk100 CentOS 5.3 Plain (64bit) 昨年から利用しているサーバです。
比較用サーバAmazon EC2
m1.large (Large Instance)
EBS Volume Amazon Linux (64bit) EBSブートのサーバを作成し、さらに追加のEBSボリュームを付与しました。

直近でDisk100を利用しているサーバがなかったため、 昨年から継続して使っているサーバを計測に使いました。 また、ストレージということで、比較用にAmazon EC2のEBSを持ってきました。

ベンチマークの方法

ディスクの性能を計測するベンチマークツールはいくつかありますが、 今回はファイルシステムの性能を測りたいので、 Sambaの開発者が作成したdbenchを利用することにします。

ニフティクラウドのOSはCentOSということで、 拡張レポジトリのEPELにもdbenchが含まれるのですが、 残念ながらEPELに含まれるdbenchは最新の4.0ではなく一つ前の3.04でした。 3.04ではレイテンシの測定ができず、さらに4.0と測定方法が異なるのか大幅に異なる結果が出てしまうため、 今回はソースコードからdbenchの4.0を用意します。

% sudo yum install -y autoconf make gcc
% wget http://samba.org/ftp/tridge/dbench/dbench-4.0.tar.gz
% tar fzx dbench-4.0.tar.gz
% cd dbench-4.0
% ./autogen.sh
% ./configure
% make

これで dbench-4.0 ディレクトリ内に実行ファイル dbench が作成されるので、以下のように実行します。

% ./dbench -c client.txt -t 120 -D /mnt/disk200a 4
                       
-c client.txt ベンチマークの内容が書かれたloadfileを指定します。今回はソースコード内に含まれるデフォルトのclient.txtをそのまま利用します。
-t 120 デフォルトでは 10分間と長めにベンチマークを行うため、今回は2分間に縮めています。
-D /mnt/disk200a 測定したいディスクをマウント先のディレクトリで指定します。このディレクトリにファイルを作成するため、書き込み権限を持っている必要があります。

4 ディスクへのアクセスを4クライアントの想定で負荷を掛けます。


測定結果

以上のコマンドを実行すると、以下のような結果が出力されます。

dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 120 seconds with load 'client.txt' and minimum warmup 24 secs
4 of 4 processes prepared for launch   0 sec
releasing clients
   4     13163   345.99 MB/sec  warmup   1 sec  latency 215.583 ms
   4     29342   348.89 MB/sec  warmup   2 sec  latency 27.657 ms
(省略)
   4    348422   343.87 MB/sec  warmup  22 sec  latency 28.963 ms
   4    364375   344.12 MB/sec  warmup  23 sec  latency 27.565 ms
   4    396340   341.22 MB/sec  execute   1 sec  latency 26.252 ms
   4    412489   345.39 MB/sec  execute   2 sec  latency 27.657 ms
(省略)
   4   2169624   328.77 MB/sec  execute 118 sec  latency 20.479 ms
   4   2183217   328.46 MB/sec  execute 119 sec  latency 117.625 ms
   4  cleanup 120 sec
   0  cleanup 120 sec

Operation      Count    AvgLat    MaxLat
----------------------------------------
NTCreateX    1256850     0.007     7.449
Close         923271     0.001     0.626
Rename         53229     0.018     2.786
Unlink        253810     0.024    18.196
Deltree           32     2.391     5.761
Mkdir             16     0.002     0.002
Qpathinfo    1139292     0.004     2.745
Qfileinfo     199682     0.001     0.178
Qfsinfo       208920     0.054     2.763
Sfileinfo     102384     0.009     6.896
Find          440547     0.014     1.675
WriteX        626773     0.021     8.206
ReadX        1970608     0.003     4.011
LockX           4094     0.003     1.334
UnlockX         4094     0.001     0.041
Flush          88102     4.658   130.334

Throughput 328.458 MB/sec  4 clients  4 procs  max_latency=130.337 ms

途中を省略していますが、このように1秒ごとに測定結果が表示されたあと、 最後に測定結果の詳細が表示されます。 先ほどのグラフは、最後の行に含まれる、「Throughput」「max_latency」をプロットしたものです。

測定結果について

特にDisk40については、測定結果に大きなばらつきがあったため、 実際には、どのディスクも同じ条件で数回ベンチマークを実行し、中央値をとっています。 Disk40は公式にもアーカイブ用とうたっていることもあり、価格とのトレードオフですね。

思った以上にDisk100の性能がふるわなかったことについては、 推測になりますが、サーバの作成時期でばらつきがあるのかもしれません。

サイバーエージェントの並河さんが、 サイバーエージェント公式エンジニアブログにてパブリッククラウドサービスAmazon EC2の性能検証レポートを公開されています。 今回は、こちら記事のディスクベンチマークと測定手法を合わせていますので、 ぜひ比べてみてください。m1.largeでの計測結果の傾向が異なっていることも興味深いところです。

今回は速報と言うことで、dbenchでのベンチマークにとどめていますが、 連続アクセスやランダムアクセスでの違いや、キャッシュの扱いなどを細かくみるためには、 bonnie++やiozoneなど細かく測定条件を変更できるベンチマークツールで掘り下げる必要があります。

今後機会があれば、もう少し掘り下げたベンチマークをしてみたいところです。

------------------------------------
プロフィール

Img_writer_nakayama ライターネーム:仲山 昌宏

歌って踊れるインフラエンジニア兼、
PHPもRubyもJavaも書くPerl使い。
物理サーバーの運用に飽きて、フルラックに
格安サーバー詰めて自宅プライベートクラウドを構築中。
今年は個人的には分散処理を攻めていきます。

------------------------------------

Comment(0)