NFSv3とNFSv4のファイル操作ベンチマーク比較

 2003年4月に公開されたNFSバージョン4(NFSv4)には、クライアント・サーバ間のステートフルな(状態遷移型)インタラクションと“ファイル・デリゲーション(権限委譲)”が導入された。これにより、クライアントはサーバ上のファイルに対して一時的な排他的アクセスが行える。NFSv4では、RPCSEC_GSS、複数操作のサーバへの一括送信、新たなファイル属性、レプリケーション、クライアント側のキャッシュ処理、ファイルロックの改良といったセキュリティ面での改善が施されている。以前のバージョンから進化した部分は数多くあるが、この記事ではその1つであるパフォーマンスに絞って調査を実施した。

 NFSv4への移行に伴う問題の1つが、エクスポートするすべてのファイルシステムを1つのエクスポート用ディレクトリの下に置かなければならないことだ。つまり、「/etc/exports」ファイルを変更したうえ、さらにLinuxのバインドマウントを使って、エクスポートしたいファイルシステムを1つのNFSv4エクスポート用ディレクトリの下にマウントする必要がある。NFSv4におけるこのファイルシステムのエクスポート方法ではシステム設定の大幅な変更が必要なため、NFSv3からのアップグレードを行っていない人も多いだろう。こうした管理上の作業については、の記事で取り上げられている。ここでは、NFSv3とNFSv4のベンチマーク評価を実施し、NFSv4への移行によってネットワークファイルシステムのパフォーマンスが向上するのかどうかを確かめる。

 今回のパフォーマンステストには、8GBのメモリを搭載したIntel Core 2 Quad Q6600ベースのサーバ、それに クライアントとしてメモリ2GBのAMD Athlon X2マシンを利用した。どちらのマシンもIntel製のギガビットPCIeネットワークカードEXPI9300PTを備え、両マシンをつなぐネットワーク上の他のトラフィックはベンチマーク実施中、ほとんどゼロだった。以前の記事で紹介したように、このネットワークカードによってネットワークの遅延はかなり抑えられる。今回のテストでは、パフォーマンスの再現性確認のためにそれぞれのベンチマークを何度か実行した。なお、両マシンのメモリ容量の違いから、Bonnie++の実行ではデフォルトの条件を変更して、サーバ側では16GBのファイルを、クライアント側では4GBのファイルをそれぞれ使用した。両マシンとも、OSは64ビット版のFedora 9である。

 サーバからエクスポートするのは、3基のハードディスクからなるRAID-5上に作成されたext3ファイルシステムで、サイズは60GB。stripe_cache_sizeは16384としたが、これはハードディスク3基のRAIDアレイの場合、RAIDレベルでページのキャッシュに192MBのメモリが使用されることを意味する。また、配信用キャッシュサイズのデフォルト値は同じRAIDアレイで3~4MBの範囲となる。キャッシュの増加はそのままRAIDの書き込みパフォーマンスの向上につながる。さらに、NFSで実現可能な理論上の最大パフォーマンスを把握するために、各ベンチマークはサーバ上でNFSを使わずにローカルでも実行した。

 上記のRAID-5構成は妥当ではないという意見もあるだろう。確かに、こうした動作を行うのにハードディスクが3基だけでは標準的な構成といえない。しかし、今回のねらいはあくまでNFSv3とNFSv4との相対的なパフォーマンス比較にある。ここでハードディスク3基のRAID-5を用いたのは、ベンチマーク向けにファイルシステムの再生成が可能だったからだ。ファイルシステムの再生成により、パフォーマンスに悪影響を及ぼすファイルの断片化といった要因を排除できる。

 まず、NFSv3のテストをasyncオプションありとなしの両方の場合で行った。asyncオプションを有効にすると、NFSサーバはディスクへの書き込みが実際に行われる前に書き込み要求に応答できる。通常、NFSプロトコルでは、ストレージへのデータ書き込みを確認してからでないとサーバはクライアントに応答を返すことができない。ニーズによっては、一部のファイルシステムでパフォーマンス向上のためにasyncオプションを使ったマウントを行っている人もいるだろう。ただし、この非同期オプションがデータの整合性に与える影響、特にNFSサーバがクラッシュした場合には検出不可能なデータ損失が起こりうることを理解しておく必要がある。

 以下の表に、NFSv3とNFSv4でマウントされたさまざまなファイルシステムについてBonnie++ベンチマークによる入出力およびシーク時間、それにサーバ側で実施したベンチマーク結果を示す。予想どおり、読み取りのパフォーマンスはasyncオプションの有無にかかわらずほとんど同じである。asyncオプションを使うと“シーク”回数が5倍以上に跳ね上がっているが、これはおそらく最初のシークが完了しないうちに次のシークが起こるため、サーバによってその一部の実行が回避される場合があるからだろう。残念ながら、NFSv4のブロック単位のシーケンシャル出力にはNFSv3からの改善がまったく見られない。asyncオプションを使わない場合の出力は50Mbpsほどで、ローカルファイルシステムの91Mbpsとは大きな差がある。ただし、asyncオプションを使うことで、シーケンシャルブロック出力の数値はNFSマウント上のローカルディスクの場合にずっと近づく。

構成 シーケンシャル出力 シーケンシャル入力 ランダム
キャラクタ単位 ブロック 書き換え キャラクタ単位 ブロック シーク回数
K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec % CPU
ローカルファイスシステム 62340 94 91939 22 45533 19 43046 69 109356 32 239.2 0
NFSv3 noatime,nfsvers=3 50129 86 47700 6 35942 8 52871 96 107516 11 1704 4
NFSv3 noatime,nfsvers=3,async 59287 96 83729 10 48880 12 52824 95 107582 10 9147 30
NFSv4 noatime 49864 86 49548 5 34046 8 52990 95 108091 10 1649 4
NFSv4 noatime,async 58569 96 85796 10 49146 10 52856 95 108247 11 9135 21

 以下の表は、Bonnie++ベンチマークによるファイルの作成、参照、削除の実行結果である。ファイルの作成と削除にはasyncオプションがかなり影響していることがわかる。

構成 シーケンシャル作成 ランダム作成
作成 参照 削除 作成 参照 削除
/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
NFSv3 noatime,nfsvers=3 186 0 6122 10 182 0 186 0 6604 10 181 0
NFSv3 noatime,nfsvers=3,async 3031 10 8789 11 3078 9 2921 11 11271 13 3069 9
NFSv4 noatime 98 0 6005 13 193 0 93 0 6520 11 192 0
NFSv4 noatime,async 1314 8 7155 13 5350 12 1298 8 7537 12 5060 9

 日常使用におけるパフォーマンスをテストするために、Linuxカーネルソースの非圧縮tarball、linux-2.6.25.4.tarの展開と、展開されたソースの削除を行ってみた。非圧縮のtarballを用いたのは、クライアントのCPUに負荷がかかって展開が遅くならないようにするためである。

構成 展開(分:秒) 削除(分:秒)
ローカルファイスシステム 0:01 0:03
NFSv3 noatime,nfsvers=3 9:44 2:36
NFSv3 noatime,nfsvers=3,async 0:31 0:10
NFSv4 noatime 9:52 2:27
NFSv4 noatime,async 0:40 0:08

まとめ

 以上のテストから、NFSv3からNFSv4に移行してもパフォーマンス面でのメリットはあまりないことがわかる。

 実際のところ、NFSv4はファイル作成ではNFSv3の倍近い時間がかかり、ファイル削除ではNFSv3よりも高速である。圧倒的な速度向上のためにはasyncオプションが有効だが、これを使うとNFSサーバのクラッシュまたはリブート時に問題が生じるおそれがある。

Ben Martinは10年以上もファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティングサービスを手がけている。

Linux.com 原文