パフォーマンスに影響する NFS の誤用

アクセスするファイルがコストのかかる通信パスのもう一方の端にあることをユーザーが認識していない場合に、 NFS の誤用が数多く生じます。

以下にその例をいくつか挙げます。

NFS マウントの在庫ファイルの更新をランダムに行っている 1 つのシステムで実行中のアプリケーション。リアルタイムの小売キャッシュ・レジスターのアプリケーションをサポートする。
各システム上のソース・コード・ディレクトリーが、同じ環境内のほかのすべてのシステムに NFS によってマウントされたものである開発環境。その開発者は、任意のシステムにログオンして、編集とコンパイルを行う。これにより、すべてのコンパイルがそのソース・コードをリモート・システムから取得し、その出力をリモート・システムに書き込むことが実際上保証されています。
1 つのシステム上で ld コマンドを実行して、NFS によってマウントされたディレクトリー内の .o ファイルを、同じディレクトリー内の a.out ファイルに変換する。
ページ位置合わせが行われない書き込みを発行するアプリケーション (例えば 10 KB)。サイズが 4 KB より小さい書き込みは、常にページイン を発生させ、NFS の場合は、このページイン がネットワーク上に送られます。

これらは、NFS が提供する透過性の有効な使用法であると主張できるかもしれません。おそらくそうであるかもしれませんが、これらの使用法ではプロセッサー時間と LAN の帯域幅が費やされるので、応答時間は遅くなります。あるシステム構成にオペレーションの標準パターンの一部として NFS アクセスが含まれている場合には、構成の設計者は、結果として生じるコストを、次のような技術的あるいはビジネス上の利点によって正当化できる用意がなければなりません。

すべてのデータまたはソース・コードを個々のワークステーションではなく、サーバーに入れると、ソース・コードの制御が改善され、集中化されたバックアップが単純化されます。
いくつかの異なるシステムが同じデータにアクセスすることによって、クライアントとサーバーの役割を兼備している 1 つ以上のシステムと比べて、専用サーバーをより効率的にします。

NFS ファイルシステム上で実行すべきでないもう 1 つのタイプのアプリケーションは、毎秒数百の lockf() または flock() コールを実行するアプリケーションです。 NFS ファイルシステムでは、すべての lockf() または flock() コール (およびその他のファイル・ロック・コール) が、 rpc.lockd デーモンを介して処理される必要があります。これにより、ロック・デーモンが毎秒数千のロック要求を処理することはできないため、システム・パフォーマンスが大幅に低下することがあります。

クライアントとサーバーのパフォーマンスの能力には無関係に、NFS ファイル・ロックに関連するすべてのオペレーションが、不当に低速になったと思われることがあります。この技術的な理由は幾つかありますが、ファイルがロックされている場合は、そのファイルが読み取りと書き込みの両方の側で同期処理されるように、特別な配慮が必要であることに起因しています。これは、クライアントには、ファイル属性を含むあらゆるファイル・データのキャッシングが存在し得ないということを意味します。すべてのファイル・オペレーションは、キャッシングなしの完全同期モードになります。アプリケーションが NFS 上で作動しており、同じクライアント/サーバーの対上にあるほかのアプリケーションに比べて異常にパフォーマンスが低いときは、そのアプリケーションがネットワーク・ファイル・ロックを実行しているのではないかと疑う必要があります。