ZFS を使った感想2009年04月07日 01時49分20秒

ZFS を本格的に評価し始めておよそ一ヵ月が経つ。やはり、記事を読むだけでは分かりづらい細かい部分もある。前評判通りに、高機能だがそれゆえの制約もある。今回は使っていて感じたことを述べてみたい。特に ZFS はシステム資源に大きく依存するので、私の主観は私の環境に大きく依存していることを忘れないで欲しい。

環境は以下の通り。i386 と amd64 の両方で使っている。物理メモリは 1.5 GB。ディスクのスループットは 5 MB/s から 40 MB/s の間の物が混在。kmem_size には 0.5 GB 程割り当てている。

まず第一はよく言われているメモリ喰いと言うこと。この程度のメモリだとほとんどキャッシュが効いていない。噂によると最低 3GB は無いとファイルキャッシュが効いてこないそうだ。FreeBSD での ZFS は UFS などで行なわれているファイルキャッシュを経由していない。ZFS 側もキャッシを実装しているので、二重にキャッシュするのを避けるためだ。その為、少ないメモリだと ZFS がキャッシュにまでメモリを回せないようだ。

第二としては、常にメモリが固定されているわけでは無いこと。ZFS を使い始めると、すぐにカーネルが 0.5 GB 占有し他には増させない等と言ったことは起きない。どの型のメモリが ZFS が使っているのかを表すのか未だに分かっていないが、zfs.ko を読み込んだら自動的に大量のメモリが取られてしまうわけでは無いみたいだ。

第三としては、物理デバイスへのアクセスは UFS に比べて遅い。ベンチマークなどは取っていないが、体感速度は遅くなっている。

第四点は、ZFS は複数のプールが互いに影響し合う。全ての ZFS が待機状態の時に、zfs set や zfs import/export 等のコマンドを行なうと、すぐに処理が終わる。しかし、一つでも ZFS が使われていると引っ張られるように、使われていない ZFS への操作も異常に時間が掛かるようになる。なお、この時の zpool のデバイスは完全に別デバイスでもだ。高負荷活動中に compression などの設定を変えたり、スナップショットを行なうと時間が掛かる。まあ、これは理解できる。しかし、全く活動していないデバイス上の ZFS に対しても、高負荷の ZFS が別に存在すると著しく時間が掛かる。あたかも高負荷のデバイスに対して処理を行なった時のように。

第五番目は、compression を gzip-9 にして高負荷を掛けるとミニハングが起きるようになった。少ないメモリと遅いデバイスへのアクセスも影響していると思われる。数秒くらい panic したかの様に何も画面が更新されなくなる。lzjb アルゴリズムだとこの様な動作は見られなかったので、gzip-9 によるものだ。少ないディスクを無理矢理使っているの大目に見ている。実運用前にしっかりと検証する必要がある。

ZFS は FreeBSD の 7 系 (ZFS version 6) と 8 系 (ZFS version 13) を行き来して使っている。両者の間にただ単に盲目的に使っている上では、大きな差は見られなかった。新たに ZFS を試そうと思っている人の参考にでもなればと思う。

コメント

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://uyota.asablo.jp/blog/2009/04/07/4230510/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。