ファイルシステムの複写をZFSでおこなう - その２

前回は 全部メインメモリに入ってしまう結果でしたが、追加で入りきらないものを計測しました。 一つの結果に対して３回計測しており、全部終わるまでに74時間以上かかりました。 もちろん一発できれいに行かない（私のスクリプトがへくったのも含めて）ために、 今日までかかってしまいました。 マシンの構成は変わっていないのですが、読み込み側のZFSファイルシステムは StorageTek 3510FCというディスクアレイで、RAID5になっています。 計測方法は前回若干変えています。 まずread onlyですが、gtarの結果があまりにもはやいので不思議に思い、 /dev/nullを直接の出力に指定するのではなく、パイプでcatに繋いでから/dev/nullにおくりました。

gtarはもしかすると出力先によっては処理が違うのかな？と思える結果です。 直接/dev/nullで、パラレルgtarの結果は４分台でした。

もう一つは10台のディスクで組んであるRAID5からの読み込みの速度を少しでも上げるために、 tar/gtar/cpioを複数同時に起動するものもやってみました。 これは試験対象ファイルシステムのルートにあるファイルおよびディレクトリに対し一対の スクリプトを同時に実行するという形にしました。 各ディレクトリに含まれるファイルの数や大きさが必ずしも一致しないのですが、 かなり当初の目的は達成できたかなと思います。 今回の対象のファイルシステムは以下の通り158GBでメインメモリのほぼ２倍の容量です。

ファイルシステム サイズ 使用済み 使用可能 容量 マウント先 p1/tst 331G 158G 172G 48% /p1/tst

結果は:

	read only			copy
	Real time	User time	Sys time	Real time	User time	Sys time
tar	2:14:03	0:19:55	0:38:21	5:12:43	0:38:47	5:10:17
gtar	2:01:10	0:03:38	0:41:32	2:05:08	0:06:32	1:27:11
cpio	2:18:22	0:02:45	0:41:55	3:11:58	0:04:13	1:02:37
multi tar	0:56:44	0:23:41	0:47:22	1:50:09	0:45:43	8:45:35
multi gtar	0:53:32	0:05:03	0:55:18	0:54:49	0:07:14	1:40:36
multi cpio	0:57:46	0:04:22	0:57:37	2:02:38	0:08:02	2:02:38
zfs send/recv	1:39:01	0:00:02	0:31:49	1:51:50	0:00:04	1:14:57

なかなか興味深い結果だと思います。 手間をのぞくとzfs send/recvは必ずしも最も早い方法ではないことになります。 zfsはファイルシステムとしてかなり優秀だと思いますが、 zfs send/recvまではマルチスレッドホットになっていないと言うことでしょうね。

「マルチスレッドホット」という言葉最近聞きませんね。 Solaris 2.0開発時によく使っていた言葉で、"multi-thread unsafe", "multi-thread safe"と"multi-thread hot" と確か３種類あって、それぞれ、マルチスレッド環境下で使えない、マルチスレッド環境下で使える、 そして、マルチスレッド環境下でマルチスレッドであることを活かして早くなるということで、 システムの各コンポーネントをどれだけホットにできるかという課題に取り組んでいました。 man pageにMTの属性の説明がありますが、ホットは無いんですね。

但しこれは今回のようにCPUの個数に余裕がある場合ということになります。 実際multi tarの結果は実時間の４倍以上のCPU時間を使っている （４つ以上平行に走っていた）ことになり、 CPUもしくはCPUの個数に余裕が無ければ違う結果になっていたでしょう。 また、gtarとmulti gtarのread onlyとcopyの結果を見ると、実時間であまり差がありません （むしろcopyの方がはやいですが、計測誤差の範囲内でしょう）。 詳しく調べないとわかりませんが、zfsのwrite cache/bufferと、 6140Arrayのwrite cacheと、さらに全体の平行動作との組み合わせがうまく働き合い、 書き込みのオーバーヘッドが無いような結果になったのでしょうか？ さらに、multiがこれほど効果的、特にgtarでの結果出たと言うことは、 zfsは複数のプロセスからの同時アクセスに対して効率よく処理できていると思われます。

ここまでくるとディレクトリを作るのがごとくばんばんファイルシステムを作れるzfsで、 ルートディレクトリ単位にファイルシステムを作って複数のzfs send/recvを走らせてみたくなりました。 が、さすがにそこまでは時間がとれないかなー.... ま、この方法が早かったとしても運用方法が変わってしまうのでそのまま比べられませんね。