順次アクセスファイルにおけるZFSの性能について - 日本語

ZFSの評判は未だに衰えないようですが、 私の方でも少しまた性能に関して計ることができたので報告します。 以前 ソフトウエア開発環境におけるZFSの性能について - 日本語 として一度書いていますが、 マシンの性能とか、今となっては古いビルドになっているとか、 ありますので、再度、でも、違う内容で計りました。 これは此処で報告するために計ったと言うよりも、実際に使うためにどうしようかと いう事ではかっているので、にたような環境で使う人がいましたら参考にしてください という感じでしょうか。

さて今回は引っ越しをした時に、 立ち上げを少し時間かけても仕事に大きく影響しないマシンを使って、 より良い環境になるはずだと言うことでやってみた件です。 それは社内にCD/DVDを焼くために用意しているマシンで以前からx86のSolarisマシンで おこなっています (古くはSS2->SS10でした）。 これを以前はSVM(Solaris Volume Manager, metaなんとかコマンドで使うやつ）とufsで 運用していたisoイメージを一時的におくためのファイルシステムをZFSに移行するのに、 どういう構成にしようかな？ということです。 ですから、順次アクセスファイルを早く書き込めることがポイントになります （読みは現状でも十分早く、DVD2台、CD3台同時書き込みでも問題なることはまずありません）。

またしてもだれも使いたがらないような古いマシンから組んでいるので 今回も今の標準では非力なマシンです （といってもこの仕事をさせるのには十分な速度は持っています）。

5.10 Generic_125101-02 i86pc Intel(r) Pentium(r) III : 750MHz : L2 256KB Memory size: 768 Megabytes Device Size Vendor Model Revision c0t0d0 0.0GB HL-DT-ST DVDRAM GSA-4082B [A204] c1t0d0 0.0GB HL-DT-ST DVDRAM GSA-4082B [A204] c2t1d0 18.1GB SEAGATE ST318203LSUN18G [034A] c2t2d0 18.1GB SEAGATE ST318404LSUN18G [4207] c2t3d0 18.1GB SEAGATE ST318404LSUN18G [4207] c2t4d0 18.1GB SEAGATE ST318203LSUN18G [034A] c3t1d0 18.1GB SEAGATE ST318404LSUN18G [4203] c3t2d0 18.1GB SEAGATE ST318404LSUN18G [4207] c3t3d0 18.1GB SEAGATE ST318203LSUN18G [034A] c3t4d0 18.1GB SEAGATE ST318203LSUN18G [034A] c4t1d0 0.0GB GENERIC CRD-BP4 [4.31] c4t2d0 0.0GB GENERIC CRD-BP4 [4.31] c4t3d0 0.0GB GENERIC CRD-BP4 [4.31]

ディスクは2940UW２枚にそれぞれMultiPackに入ったつないだもので、 本体同様結構古い物です。 Solarisは10で、FCSの物からずっとパッチを当て続けて運用しています （3/12/2007の時点で最新）。 もともと以下のようにSVMとufsでファイルシステムは組んでありました。

d9 m 50GB d10 d11 d10 s 50GB c2t2d0s2 c2t3d0s2 c2t4d0s2 d11 s 50GB c3t2d0s2 c3t3d0s2 c3t4d0s2

今回の試験で主に対象としたのは実際に使うDVDのイメージです。

% ls -l nv_iso_nvx_dvd_55b_solarisdvd.iso -rw-r--r-- 1 root 3857448960 Mar 14 16:05 nv_iso_nvx_dvd_55b_solarisdvd.iso %

• 対象のファイルをNFS越しに（結果が安定しませんが、実際にこうやるので）複写。 消しながら３回やった最も短い結果。
• 同様に対象のファイルをNFS越しに（結果が安定しませんが、実際にこうやるので）複写。 消さないで別名にしながら３回やった最も短い結果。
• およそ20GBのufsdumpされたファイルシステムの内容をやはりNFS越しにufsrestore (ufsrestoreという名前ですが、ファイルを戻す時は通常のAPIで書き込むので 書き出されるファイルシステムはZFSでもよい）。

結果は:

前回同様データをこのままみるのは見づらいのでStarSuite8でグラフを ちょこっと作ってみました：

細かいことを抜きにすればだいたい予想通りですが、 Raidz2でもufs mirror(raid1)よりはやいというのは良い結果です。 (new)と(half full)はファイルシステムがいっぱいになってくると 遅くなるというファイルシステムでは無いことの確認です。 ZFSの結果ではストライブとミラーの結果があまり大差はないので、 ミラーのプロテクションが容量を除けばただ同然であることが確認され、 当初の目的としてはZFSのミラーで行くという結論になりました。

今回も気になるのはCPUの時間です。 前回はZFSの性能がかなりCPUの速度に制限されていたように思いますが、 データを見る限り今回はそうは見えません。 しかし、此処では書かれていないデータとしてこの実験をしている間 ずっとiostatでディスクの動きとCPUに動きを見ていましたが、 ZFSの場合は70%位常にCPUが忙しかったのに、 此処出ている(timex コマンドでみています）結果には反映されていません。 なんとなくtimexコマンドではかれるシステムタイムがZFSの場合、 計りたい内容をはかっていないように思われます (ZFSがこのcpコマンドの実行に使っているCPUタイムが全部計測されていない？）。 このことからもしかするとまだCPUの制限を受けている可能性がありますが、 実は今回はネットワークに主に制限を受けています。 単純な計算ですが、3.8GBのデータを100Mbpsのネットワークで移動すると だいたい６分かかることになります。 そうするとNFS/ZFS/ディスクによるオーバヘッドは今回ほとんどない ことになり、かなり良い結果といえます （NFSサーバは8GB積んでおりGigabitEthernetですが、 このクライアントはFast Ethernet/100Mbpsです）。

もう一点、上の表では現れていないのですが、 ZFSの結果はUFSのものよりもふれが大きいです。 何に影響されるのかまではつかめていないのですが、 UFSに比べても結果のふれ具合が大きくなる点が気になります。 最悪の結果を持ってしてもUFSに楽に勝てるのですが、 なぜふれるのか知りたいところです。 もっとも、ZFSは特にパフォーマンスに関しては発展途上でどんどん変わっていく 予定なので、 今わかってもあまり意味をなさないかもしれませんが。

今回も簡単な試験しかできませんでしたが、 ZFSの優位性が証明できたと思います。 此処には書いていませんが、速度以外の利点はそのままに、 速度のメリットも発揮されると言うことで、 機会を見つけるたびにZFSに移行していこうと思います。