ソフトウエア開発環境におけるZFSの性能について - 日本語

話題のZFSすぐ試してみたいと思っていたのですが、 なかなか時間とマシンなどの用意ができなくて 試せなかったのが、やっとできました。 社内の主なサーバで使う前にいろいろ試したかったのですが、 そのうち当然最初にやってみたいのはベンチマークです （なぜかあまり多くのZFS対ufsのベンチマークの結果を見かけません）。 我々は会社においておもにソフトウエアの開発に携わっておりますので、 その作業に関係するものもしくはその中で特に時間がかかっているものを 試してみようと思いました。 また、せっかくですからOpenSolarisに関係することをやってみたいと。

用意できたマシンは現在の基準から言って新しい/早いとかいえるものではありません。 マシンは以下のようなUltra2です：

5.11 snv_45 SUNW,Ultra-2 The sparcv9 processor operates at 296 MHz, The sparcv9 processor operates at 296 MHz, Memory size: 1024 Megabytes Device Size Vendor Model Revision c0t0d0 73.4GB SEAGATE ST373307LSUN72G [0707] c0t1d0 73.4GB SEAGATE ST373307LSUN72G [0707] c1t0d0 18.1GB SEAGATE ST318203LSUN18G [034A] c1t1d0 18.1GB SEAGATE ST318203LSUN18G [034A] c1t2d0 18.1GB SEAGATE ST318203LSUN18G [034A] c2t0d0 18.1GB SEAGATE ST318203LSUN18G [034A] c2t1d0 18.1GB SEAGATE ST318203LSUN18G [034A] c2t2d0 18.1GB SEAGATE ST318203LSUN18G [034A]

今みるとかなり古く遅いマシンといえますが、 最近発表されたSPECのCPU2006では同じ296MHzのCPUを積むUltra2がリファレンスマシンと なっていましたので、まあ、それほど悪くもないかなと思います （もっとも、枯れたマシンだからリファレンスになるんだと思いますが）。 これにNevadaのビルド#45をインストールしていますが、 内蔵している２台の73GBにはSolaris自身と元になる試験用のデータを入れあります。 これらのファイルシステムは以下のようにSolaris VMとufsで構成されています:

ako@scully/2-31 % df -F ufs -h Filesystem Size Used Available Capacity Mounted on /dev/md/dsk/d100 16G 7.0G 8.6G 45% / /dev/md/dsk/d120 50G 5.5G 44G 12% /export/home ako@scully/2-32 % metastat -c d110 m 2.0GB d111 d112 d111 s 2.0GB c0t0d0s1 d112 s 2.0GB c0t1d0s1 d100 m 16GB d101 d102 d101 s 16GB c0t0d0s0 d102 s 16GB c0t1d0s0 d120 m 50GB d121 d122 d121 s 50GB c0t0d0s3 d122 s 50GB c0t1d0s3 ako@scully/2-33 %

それ以外のすべてのディスクは一つのD1000ディスクアレイに入っています （D1000は二つの別々のSCSIバスになるように構成されています）。 D1000はインテリジェントなコントローラーを持っているわけではないので、 すべてのディスクは単に個別の単体のディスクがつながっているように見えます。 試験に使われた元のデータはOpenSolarisのソースコードで、 www.opensolaris.orgからダウンロードしたものです。 このワークスペースで一度OpenSolarisをすべてビルドしましたが、 その後にビルドしたものを消して、いくつか構成を変えて（おもにおおもとのMakefile)、 カーネルだけがビルドされるようにしました。 これはこのマシンですべてをビルドすると（カーネル以外にはライブラリやコマンド）、 なんと19時間以上もかかるからです。 カーネルだけにしてもまだ5時間以上かかりました。

試験のデータであるOpenSolarisのワークスベースはこのとき2GBでした：

ako@scully/2-38 % du -sh . 2.0G . ako@scully/2-39 %

そして試験の内容は：

• 対象のファイルシステムを構成、構築し、その時間を計測。
• ワークスペース丸ごと元のファイルシステムから対象のファイルシステムに複写（1回目の複写）。このときの書き込み側のプロセスの時間(tar -x)を計測。
• 再度ワークスペースを丸ごと複写（２回目の複写）、ただし今度は対象のファイルシステムから同じファイルシステム上の別のディレクトリへ。同じように書き込み側のプロセスの時間を計測。
• 上で行った1回目で複写したワークスベースを削除しその時間を計測。
• OpenSolarisを2回目に複写したワースペースの上でビルド（カーネルのみ）し、 その時間を計測。

  このとき：それぞれの時間の計測にはそれぞれの最後に行った"lockfs -f"の時間を含みます。

結果は:

ZFSのmkfs/mountの結果を見るとかなり驚きです、特にufs/RAID5の結果と比べてみてください。 ZFSファイルシステムを作ために要する時間というのはきわめて短く、 ほとんど一瞬です。 しかし、その他のデータをこのままみるのは見づらいのでStarSuite8でグラフを ちょこっと作ってみました：

ざっとみてみて気になるのは、例えばZFSのstripe/mirrorがufsに比べて 極端に遅いことです。 しかし、ここでsystem timeをみてみると、 CPUがかなりの時間を占めていることがわかります。 そこで、最初にこれを走らせたときZFSの一つの特徴であるチェックサムをとる ことが原因ではないかと思い、 これを使用しないようにしてみました。 残念ながら結果はあまりかわらず、 実は上の結果はチェックサムがすでに使わない状態なのです。 (これはstripeの場合でほかの場合は試していませんが、変わると思えません）。

もしもCPUの速度が問題であると言い切れるとするならば、 私としてはZFSに大きな期待を持ち続けることができます。 RAIDの結果を見てもやはりCPUに依存しているように思えますが、 real timeをみるとufs RAID5とそれほど変わりません （というかZFSの方がわずかに早いです）。 と言うことは早いCPUのマシンを使えばZFSの方が早くなるであろうという ことです。 おそらくstripe/mirrorであっとも早いCPUは良い結果を生むと思われます。

ところで、ZFSの良さはパフォーマンス（速度）だけではなく、 例えば使いやすさです。 この試験においてufs mirrorを作るのに私は以下のスクリプトを使いました：

time metainit d131 1 3 c1t0d0s2 c1t1d0s2 c1t2d0s2 time metainit d132 1 3 c2t0d0s2 c2t1d0s2 c2t2d0s2 time metainit d130 -m d131 d132 time newfs /dev/md/rdsk/d130 < /dev/null time mount /dev/md/dsk/d130 ${MOUNTPOINT}

しかし、ZFSの場合は：

time zpool create -m ${MOUNTPOINT} tmp mirror c1t0d0 c2t0d0 mirror c1t1d0 c2t1d0 mirror c1t2d0 c2t2d0 time zfs set checksum=off tmp しかも2行目は通常いりません。

OpenSolarisのビルドに関してはこれもCPUが問題なっています。 異なったファイルシステムの上でビルドをしてもあまり変化はありません。 こうなるとは予想していましたが、確認をしたかったのです。

総合的にZFSが提供する良さを考えると （使い/管理のしやすさ、スケールすること、信頼性、アベイラビリティなどなど）、 ぜひ私としては実際の作業環境で使ってみたいとも思います。 例えばsnapshotを使うことによってバックアップの時間の短縮 （というかなくなる？）などは楽しみです。 また、実際に早いCPUを使うことによる結果も楽しみです （Sun社内の人へ :-）。