NFSv3とNFSv4のファイル操作ベンチマーク比較
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、各種ファイルシステム、検索ソリューションを中心としたコンサルティングサービスを手がけている。
