順次アクセスファイルにおけるZFSの性能について その２

およそ一年前にZFSの性能に関して 順次アクセスファイルにおけるZFSの性能について - 日本語 として書いていますが、 今回さらにもう少し性能の良いマシンで試験できましたので報告します。 とはいっても、他部署から譲ってもらった使い古しのマシンで、最新というわけではないです。 前回はx86でしたが、今回はSPARCです。

System : Sun Fire 280R (2 X UltraSPARC-III+) CPU Type : SUNW,UltraSPARC-III+ * 2 CPU MHz : 1200MHz CPU 2nd Cache : 8MB Memory : 8GB OS : SunOS 5.10 Generic_127111-11 Device Size Vendor Model Revision c0t0d0 36.4GB SEAGATE ST336704FSUN36G [1526]　　　内蔵1 c0t1d0 18.1GB SEAGATE ST318304FSUN18G [0726] 内蔵2 c3t5002 253.5GB SUN T300 [0302] T3B c3t5002 253.5GB SUN T300 [0302] T3B c4t1d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c4t2d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c4t3d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c4t4d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c5t17d0 18.1GB SEAGATE ST318304FSUN18G [0726] A5200後側 c5t18d0 18.1GB SEAGATE ST318304FSUN18G [042D] A5200後側 c5t19d0 18.1GB SEAGATE ST318304FSUN18G [042D] A5200後側 c5t20d0 18.1GB SEAGATE ST318304FSUN18G [042D] A5200後側

c0に繋がっているディスクにシステム(OS)がはいっています （運用する時には3way mirrorにする予定）。 c3はFCAL switch経由で2台のT3Bストレージアレイに繋がっていて、 今回はtarの試験の時の元データを此処に入れました。 c4/c5が今回の試験の対象となるJBOD(Just a Bunch Of Disks)です。 A5200という古いJBODですが、FCAL接続なのでまあまあです。 ただし、残念ながらc3/c4/c5すべて1GbpsのFCAL HBAで構成しています (A5200はもともと1Gbpsしかサポートしないですけど）。 システムはSolaris 10 8/07 (U4)で、比較的最近のパッチレベルまで当ててあります (Solaris 10 5/08 (U5)がすでに発表されています）。

前回は特に書きませんでしたが、今回ZFS/UFSを作ったコマンドは以下のようになります。

# ZFS ストライプ (RAID 0) zpool create bench c4t2d0 c5t18d0 c4t3d0 c5t19d0 c4t4d0 c5t20d0 # ZFS ミラー(RAID 0+1) zpool create bench mirror c4t2d0 c5t18d0 mirror c4t3d0 c5t19d0 mirror c4t4d0 c5t20d0 # ZFS RAIDZ zpool create bench raidz c4t2d0 c5t18d0 c4t3d0 c5t19d0 c4t4d0 c5t20d0 # ZFS RAIDZ2 zpool create bench raidz2 c4t2d0 c5t18d0 c4t3d0 c5t19d0 c4t4d0 c5t20d0 # SVM ストライプ (RAID 0) metainit d900 1 8 c4t1d0s6 c5t17d0s6 c4t2d0s6 c5t18d0s6 c4t3d0s6 c5t19d0s6 c4t4d0s6 c5t20d0s6 # SVM ミラー (RAID 0+1) metainit d901 1 4 c4t1d0s6 c4t2d0s6 c4t3d0s6 c4t4d0s6 metainit d902 1 4 c5t17d0s6 c5t18d0s6 c5t19d0s6 c5t20d0s6 metainit d900 -m d901 metattach d900 d902 # SVM RAID 5 metainit d900 -r c4t1d0s6 c5t17d0s6 c4t2d0s6 c5t18d0s6 c4t3d0s6 c5t19d0s6 c4t4d0s6 c5t20d0s6

最近はZFSを使うことが多いので、 SVM (Solaris Volume Manager)でミラーとかRAID 5を組んだ時のめんどくささが際だちました。 SVMで組むとどちらも事実上すぐには使えません。 ミラーはmetattachしたあと同期完了を待たないと、ベンチマークになりません。 RAID 5も初期化完了をまたないとつかえませんが、どちらも結構時間がかかります。 この点ZFSは数秒（それもほとんどの時間は指定されたディスクが他の用途に使われていないか 調べている時間です）で終わるので、これになれるとSVMはつらいです。 しかも、この後newfsをしないと使えませんが、ZFSはすぐ使えます。

注意してほしいのは上記の作成方法が二つのコントローラを使った場合の速度的に最適か どうかは私にはわかりません。 過去の経験からなんとなくそうしているだけです。 ミラーなどの場合は安全性からはこれが良いと思ってはいますが。

今回の試験で予想はできたのですが、やっぱりというのが扱うファイルの大きさです。 前回は3.6GBのファイルを使っていたのですが、 今回はメモリが8GBあるマシンだったのでディスクに書き込む時間の計測にはなりませんでした (とくにZFSの場合全部キャッシュされてしまう）。 そこで、同じファイルを三つ足して11GBにして、これをT3B側のZFSにおいて、 複写する時間を計ることにしました。 しかし、やってみてわかったのですが、T3Bからの読み込みがボトルネックになりました。 つまり1Gbps以上の速度で書き込みができるようなのです。 開き直ってファイルを複写するのではなく

dd if=/dev/zero of=file_name bs=1024k count=11037

で単にゼロの内容のファイルを作ることにしました(mkfileでも良かったかもしれません）。 大きさは前記のファイルと同じにしただけで、意味はありません (メインメモリの容量をはっきり超えればよいはず）。 さらに今回はそれぞれ単独のドライブでの試験もやってみました。

• ddコマンドでファイルを作成。 都度消しながら３回やった最も短い結果。
• 同様にddコマンドでファイル作成。 消さないで別名にしながら３回やった最も長い結果。
• およそ23GBのtarでアーカイブされたファイルシステムの内容をtarで T3Bから読み込みながら展開。

結果は:

	cp/rm			cp			tar x
	Real time	User time	Sys time	Real time	User time	Sys time	Real time	User time	Sys time
UFS Single drive	06:22	00:00	00:57
SVM/UFS Stripe	01:34	00:00	01:14	01:42	00:00	01:22	30:44	01:53	12:51
SVM/UFS Mirror	02:47	00:00	01:23	03:01	00:00	01:22	41:00	02:00	13:22
SVM/UFS RAID5	45:59	00:00	01:38
ZFS single drive	05:06	00:00	00:22
ZFS stripe	00:59	00:00	00:22	01:19	00:00	00:22	29:40	01:48	26:47
ZFS Mirror	02:01	00:00	00:30	02:39	00:00	00:23	30:02	01:50	27:03
ZFS RAIDZ	01:24	00:00	00:22	01:49	00:00	00:23	30:48	01:50	27:02
ZFS RAIDZ2	01:57	00:00	00:22	02:44	00:00	00:22	31:22	01:51	27:15

再びStarSuite8でグラフを ちょっと作ってみました：

わかると思いますが、UFS RAID 5の結果はいれてません （確認の意味でやりましたが、やっぱり桁違いに遅いのでこれしか測定していません）。

今回もほぼ前回と同様の傾向が見て取れますが、 さらに差がはっきりしたように思います。 また、細かく見るとZFSのRAIDZ/RAIDZ2ともにMirrorよりはやいというのは意外に思えます。 しかし、これはミラーでも同じ数のディスクしか使っていない、 つまりストライプの幅が半分くらいになっているのでこれが影響しているだけかもしれません。 ミラーが単純ストライプ(RAID 0)の倍くらいの時間という結果も、 ストライブの幅の影響と思えなくはないです。 今回も前回と同じ反省点があります（進歩していない (X X)）。 表を見てもCPUの時間に差がありません。 つまり、SVM/UFS/ZFS/ZPOOLに費やされているCPUの時間が計測されていません (%ですけどtimexコマンドの"-s"で計れそうです）。 tarコマンドの結果に関しては残念です。 ほぼ間違いなくデータの送り側であるT3Bの1GbpsのFCALがボトルネックで、 書き込み側の時間に測定になっていないと思われます。 もし、経過時間に使用したトータルなCPU時間が計測できていれば少しは意味のある データがとれたかもしれませんが、このままでは意味がありません。 UltraSPARCIII+@1.2GHzのシステムで1Gbps FCALの限界をファイルシステムの書き込みで こんなに簡単に超えるとは思っても見ませんでした。

今回の結果をだけを見るとZFSのRAIDZ2をJBODの場合には多用したいと私は思いますね。 速度的にはUFSやZFSのミラーよりも早く、容量的な制限が少なく、 可用性に関しても充分 （もちろんHBA丸まるとかの場合を考えるとミラーしかないですけど） といったところでしょうか。 もちろん用途によりますけど、かなり多くの用途で通用しそうです。