5    ネットワーク・ファイル・システムのチューニング

ネットワーク・ファイル・システム (NFS) を使用すると,ネットワークを通じて透過的にファイルにアクセスできます。 NFS は,小規模で単純なネットワークから,大規模で複雑なネットワークまで,各種のネットワーク・トポロジをサポートします。 NFS は,ユニファイド・バッファ・キャッシュ (UBC) を,仮想メモリ・サブシステムおよびローカル・ファイル・サブシステムと共有します。

NFS は,ネットワークに過度の負荷をかけることがあります。 NFS の性能が良くない場合は大半が,ネットワーク・インフラストラクチャの問題です。 NFS クライアントの再送メッセージの数が多くないか,ネットワークの入出力エラーがないか,負荷に耐えられないルータがないかを調べてください。 ネットワーク上でパケットの紛失があると,NFS の性能が大幅に低下します。 パケットの紛失は,サーバの輻輳,送信中のパケットの破損 (電気的接続の問題や,ノイズの多い環境,ノイズの多いイーサネット・インタフェースが原因),転送処理の放棄が早過ぎるルータが原因で発生します。

NFS の性能を評価する場合,NFS ファイル上でファイル・ロック・メカニズムが使用されているときは NFS の性能が良くないことを考慮してください。 ロックを行うとファイルがクライアント側にキャッシュされなくなるからです。

NFS のサービスだけを行っているシステムで性能を改善する方法は,汎用タイムシェアリング用に使用しているシステムのチューニングとは異なります。 というのは,NFS サーバは少数の小規模なユーザ・レベル・プログラムだけを実行しており,システム・リソースはほとんど使用しないからです。 ページングやスワッピングも最低限しか発生しないので,メモリ・リソースは,ファイル・システムのデータのキャッシングに重点を置いて割り当てる必要があります。

NFS 要求の処理で CPU 時間と実時間の大部分が消費されるため,NFS ではファイル・システムのチューニングが重要です。 理想的には,UBC ヒット率が高くなければなりません。 UBC のヒット率を高くするには,メモリを増やしたり,他のファイル・システムのキャッシュのサイズを小さくする必要があります (11.1.3 項を参照)。 一般的には,ファイル・システムのチューニングを行うと,入出力多用型のユーザ・アプリケーションの性能が改善されます。 また,ファイル・データを保存するには,vnode が必要です。 AdvFS を使用している場合は,ファイル・データを保存するために,アクセス構造体も必要です。 ファイル・システムについての詳細は,第 11 章を参照してください。

この章では,NFS の性能を改善する方法を説明します。 以下のトピックを含め,各種の構成ガイドラインを紹介し,いくつかのモニタリング・ツールについて説明します。

5.1    NFS 統計情報のモニタリング

この節では,NFS 性能情報を収集するのに使用するユーティリティの参照先を紹介します。 統計情報はさまざまな条件のもとで収集することが重要です。 データ・セットを比較すると,性能問題を診断するのに役に立ちます。

表 5-1は,NFS 性能の低下を検出するのに使用するツールを説明しています。

表 5-1:  NFS の性能低下を検出するツール

ツール 説明 参照先
nfsstat ネットワーク・ファイル・システムの統計情報の表示 2.4.3 項
tcpdump ネットワーク・インタフェース上のパケット・ヘッダのモニタリングと表示 2.4.4 項
netstat ネットワーク統計情報の表示 2.4.5 項
ps axlm システム上のアイドル入出力スレッドの表示 サーバ側は2.4.6 項,クライアント側は2.4.7 項
nfswatch NFS ファイル・サーバの受信ネットワーク・トラフィックのモニタリングとそのカテゴリ分類 2.4.8 項
dbx print nfs_sv_active_hist アクティブな NFS サーバ・スレッドのヒストグラムの表示 3.1 節
dbx print nchstats namei キャッシュのヒット率の調査 2.6 節
dbx print bio_stats メタデータ・バッファ・キャッシュのヒット率の調査 3.1 節

5.2    NFS 性能低下の検出

表 5-2は,NFS の性能低下の問題とその解決策をいくつか示しています。

表 5-2:  発生しうる NFS の問題と解決策

問題 解決策
NFS サーバのスレッドがビジー。 サーバを再構成して,実行するスレッドの数を多くする。 2.4.6 項を参照。
ファイル・システムのキャッシュに重点を置いてメモリ・リソースが割り当てられていない。

UBC に割り当てるメモリの量を増やす。 11.1.3 項を参照。

AdvFS を使用している場合は,AdvFS アクセス構造体用に予約するメモリを増やす。 11.1.5 項を参照。

システム・リソース割り当てが十分ではない。

maxusers 属性の値に 1 秒あたりに発生するサーバ NFS 動作の数を設定する。 8.1 節を参照。

UFS メタデータ・バッファ・キャッシュのヒット率が低い。

メタデータ・バッファ・キャッシュのサイズを増やす。 11.1.4 項を参照。

namei キャッシュのサイズを増やす。 11.1.2 項を参照。

CPU アイドル時間が少ない。 AdvFS の代わりに,UFS を使う。 11.3 節を参照。

5.3    性能上の利点と欠点

表 5-3 は,NFS の構成ガイドラインとそれぞれの性能上の利点と欠点を示します。

表 5-3:  NFS のチューニング・ガイドライン

利点 ガイドライン 欠点
入出力のブロック動作が効率的になる

NFS サーバ上に適切な数のスレッドを構成する (5.4.1 項)

なし
入出力のブロック動作が効率的になる

クライアント・システム上に適切な数のスレッドを構成する (2.4.7 項)

なし
遅いネットワーク,または輻輳したネットワークの性能が改善される

クライアント・システムのネットワーク・タイムアウトを減らす (5.4.3 項)

理論上性能は低下
読み取り専用のファイル・システムのネットワーク性能を改善し,クライアントが変更を迅速に検出できるようになる

クライアント・システム上のキャッシュのタイムアウト限界値を変更する (5.4.3 項)

サーバへのネットワーク・トラフィックが増加する

以降の節で,これらのガイドラインを詳細に説明します。

5.4    NFS の構成

この節では,NFS (ネットワーク・ファイル・システム) 構成の特定の領域について説明します。 ネットワーク構成の詳細は,『ネットワーク管理ガイド:接続編』を参照してください。

5.4.1    サーバ・スレッドの構成

nfsd デーモンは NFS サーバ上で実行され,クライアント・システムからの NFS 要求を処理します。 このデーモンは,クライアント・システムからの NFS 要求を処理する多数のサーバ・スレッドを生成します。 サーバとして動作するには,少なくとも 1 つのサーバ・スレッドがマシン上で実行されていなければなりません。 スレッドの数により,並列動作の数が決まります。 この数は,8 の倍数でなければなりません。

頻繁に使用される NFS サーバの性能を改善するには,16 個または 32 個のスレッドを構成します。 この構成では,入出力動作のブロックが最も効率的になります。 UDP スレッドと TCP スレッド用に合計で 16〜128 のスレッドを構成します。

次のコマンドを実行して,UDP スレッドと TCP スレッドの数をモニタリングします。

# ps axlm | grep -v grep | grep -c nfs_udp

# ps axlm | grep -v grep | grep -c nfs_tcp

上記のコマンドを実行すると,スリープ状態のスレッドとアイドル状態のスレッドの数が表示されます。 この数が繰り返し 0 になるようなら,nfsd スレッドを追加する必要があります。 詳細は,2.4.7 項または nfsd(8) を参照してください。

5.4.2    クライアント・スレッドの構成

クライアント・システムは nfsiod デーモンを使用して,バッファ・キャッシュの先読みや書き込み動作の遅延などの,非同期入出力動作を処理します。 nfsiod デーモンは,複数の入出力スレッドを生成して,サーバへの非同期入出力要求を処理します。 入出力スレッドは,NFS の読み取りと書き込みの両方の性能を改善します。

最適な入出力スレッド数は,多数の要因 (クライアントの書き込み頻度,同時にアクセスされるファイルの数,NFS サーバの動作など) によって決まります。 スレッドの数は,8 の倍数から 1 を引いた数でなければなりません (たとえば,7,15,31 などが最適です)。

NFS サーバは,書き込みを完全な UFS クラスタとして集積してから,入出力を開始します。 スレッド数に 1 を加えた値は,クライアントが同時に保持できる未処理の書き込みの数です。 スレッドがちょうど 7 個または 15 個ある場合は,入出力動作のブロックが最も効率的になります。 書き込みの集積が有効でクライアントにスレッドがない場合は,性能が低下することがあります。 書き込みの集積を無効にするには,dbx patch コマンドを使用して,nfs_write_gather カーネル変数に 0 を設定します。 dbx コマンドについての詳細は,3.2 節を参照してください。

クライアント上のアイドル状態の入出力スレッドを表示するには,次のコマンドを実行します。

# ps axlm | grep -v grep | grep -c nfsiod

スリープ状態のスレッドがほとんどない場合,スレッドの数を増やすと NFS の性能が改善される可能性があります。 詳細は,2.4.6 項または nfsiod(8) を参照してください。

5.4.3    キャッシュ・タイムアウトの限界値の変更

読み取り専用のファイル・システムと低速のネットワーク・リンクでは,NFS クライアント・システム上のキャッシュ・タイムアウトの限界値を変更すると,性能を改善できる可能性があります。 このタイムアウトは,他のホストが変更したファイルまたはディレクトリの変更内容が反映される早さに影響します。 サーバ・システムなどの他のホスト上のユーザとファイルを共有していない場合は,タイムアウト値を大きくすると性能が少し改善され,生成するネットワーク・トラフィックの量が少なくなります。

詳細は, mount(8) と,acregminacregmaxacdirminacdirmaxactimeo オプションに関する説明を参照してください。

5.5    NFS の再送

過度の再送があると,クライアントは要求を再送する前にサーバからの応答を待つ必要があるので,性能が低下する原因になります。 過度の再送の原因は,以下のとおりです。

クライアント・コンピュータ上の NFS 再送率を測定するには,nfsstat -c コマンドを使用します。 それにより,ネットワークの再送率がわかります。 詳細は, nfsstat(8) を参照してください。

メディアの負荷が低いか中間程度の場合,クライアント要求に対する NFS の平均応答時間は 15 ミリ秒程度です。 大部分のクライアントは,およそ 1 秒後に要求を再送します。 性能が 10% 悪くなっても良ければ,応答時間を 1.5 ミリ秒増加できます。 こうすると,NFS の再送率は 0.15% になって,許容範囲に収まります。 計算は,次のとおりです。

   .0015 秒/要求
 -----------------  =  0.0015 再送/要求
    1.0 秒/再送

最悪の場合の NFS 要求 (イーサネット上の 8 KB の読み取り,または書き込み) には 7 パケット (1 つの要求と 6 つの断片化した応答) が必要なので,ネットワークのエラー率は,0.02%以下です。 計算は,次のとおりです。

  0.15 %
 --------- = 0.02 %
    7

ネットワークのエラー率を測定するには,netstat -i コマンドを使用します。 この率が許容できないほど高い場合は,個々のコンピュータが過度のエラーを起こしていないか調べます。 問題が広範囲に及んでいる場合は,採用しているケーブルを調べます。 たとえば,ノイズの多い非標準の同軸ケーブルに問題があるのなら,ツイスト・ペアのイーサネットに変更します。 詳細は, netstat(1) を参照してください。

5.5.1    ネットワークのタイムアウトを減らす

低速のネットワーク・リンク,輻輳しているネットワーク,ワイド・エリア・ネットワーク (WAN) では,NFS の性能は良くありません。 特に,クライアント・システムでのネットワーク・タイムアウトで,NFS の性能が大幅に低下することがあります。 このような状況が発生しているかどうかは,nfsstat コマンドを使用し,呼び出しのタイムアウト率を調べることで判断できます。 タイムアウトが呼び出し総数の 1 パーセントを超えると,NFS の性能が大幅に低下することがあります。 タイムアウトおよび呼び出しの統計情報の nfsstat 出力の例は,2.4.3 項 を参照してください。

また,netstat -s コマンドを使用して,タイムアウトの問題があるか調べることもできます。 netstat で出力された ip セクションの fragments dropped after timeout フィールドが 0 以外の値の場合は,問題が発生している可能性があります。 netstat コマンドの出力例は,2.4.5 項を参照してください。

フラグメントのドロップがクライアント・システムで問題になっている場合は,-rsize=1024 オプションと -wsize=1024 オプションを指定して mount コマンドを実行し,NFS の読み書きバッファのサイズを 1 KB にします。

5.6    NFS サーバのチューニング

Tru64 UNIX はメモリ内のバッファ・キャッシュを使用して,できる限り,ディスク操作を行わないようにしています。 このメモリは,比較的低速なディスク入出力に対して,クライアントの待ち時間を減らすのに効果的です。 ディスク操作のステージングやスケジューリングを行えば,ディスク入出力がさらに効率的になります。

ディスク・デバイス・ドライバが,ディスクのアーム位置に応じて,複数の要求を一度に処理するようにスケジュールできれば,性能が改善できます。 繰り返される要求をキャッシュで処理すれば,ディスク入出力の総数は減ります。 NFS の読み込み操作が多くある場合,サーバにメモリを追加すれば,サーバの性能は向上します。 バッファ・キャッシュは,メモリ・サイズに比例して確保されるからです。

サーバに性能の問題があると,リモート書き込み要求があった場合に,システムのバッファ・キャッシュの効率が悪くなります。 NFS は単純な,状態のない (stateless) プロトコルを使っているので,各クライアントの要求は完結していて自己完備型である必要があります。 サーバは各要求を完全に処理してから,クライアントに肯定応答を送信します。 サーバがクラッシュしたり,肯定応答が紛失すると,クライアントは要求の再送を行います。 そのため,以下の状況が発生します。

NFS バージョン 2 では,書き込み操作は同期型になりました。 すなわち,サーバは,書き込み要求を受信すると,データおよびそれを後で検索するために必要な情報を書き込んでから,応答します。 Tru64 UNIX では,書き込みの集積 (write gathering) と呼ばれる方法を使って,この入出力負荷を減らしていますが,それでも性能への影響は大きく残っています。

NFS バージョン 3 では,書き込み要求は通常非同期型になり,書き込み操作の性能へ与える影響は最小になりました。 サーバは書き込み要求を受け取ると,データ受信の肯定応答を行います。 後でクライアントが,キャッシュに残っているデータの書き込みを要求するコミット要求を送信すると,サーバは,すべてのデータを安定したストレージに格納した段階で応答を行います。 このプロトコルには,書き込み確認が含まれるので,クライアントは書き込み操作とコミット操作の間にサーバがクラッシュしてリブートした場合は確認できます。 サーバがクラッシュしてリブートしていた場合には,クライアントはコミットされなかった書き込み要求を再送し,サーバに正しいデータが保存されていることが保証できます。

システム・バッファ・キャッシュは,データを変更する NFS 要求の性能を改善するためには使えません。 サーバが変更されたデータを揮発性メモリに書き込むだけだと,サーバがクラッシュした場合には,データの完全性が危険にさらされます。 クライアントには安全に格納されたことになっていても,データが揮発性メモリにしか格納されていなかった場合,クラッシュが発生して,そのデータは失われる可能性があるからです。 多くのクライアントのデータを 1 台のサーバに格納しているので,多くのクライアントに影響を及ぼします。 しかし,変更結果を常に同期をとってディスクへ書き込んでおけば,データが失われることなく,サーバのクラッシュから回復できます。

NFS の操作はディスクに同期型でコミットするので,データの完全性が保証されることになり,サーバはシステム障害が発生しても復旧できます。 しかし,この操作はディスクの速度に依存し,キャッシュ操作の場合のメモリ速度では実行できないので,性能は低下します。 また,この操作はシリアルに行われるので,ディスクのアーム位置のスケジュールによる最適化も行えません。 キャッシュの変更もディスクに同期をとって書き込まれるため,ディスクへの書き込みのトラフィックも最適化できません。

NFS サーバは少数の小規模なユーザ・レベル・プログラムしか実行しないので,システム・リソースは殆ど使用しません。 NFS 要求の処理で CPU 時間と実時間の大部分が消費されるので,ファイル・システムのチューニングは重要です。 ファイル・システムのチューニングについての詳細は,第 11 章を参照してください。

また,NFS を TCP (Transmission Control Protocol) 上で動作させている場合は,多くのアクティブなクライアントがいるときには,TCP のチューニングでも性能が改善される可能性があります。 ネットワーク・サブシステムのチューニングについての詳細は,10.2 節を参照してください。 NFS を UDP (User Datagram Protocol) 上で動作させている場合は,ネットワーク・サブシステムのチューニングは通常は必要ありません。

NFS だけをサービスしているシステムでは,表 5-4のガイドラインに従ってチューニングを行ってください。

表 5-4:  NFS サーバのチューニング・ガイドライン

ガイドライン 参照先
maxusers 属性の値に,想定される毎秒当たりのサーバ NFS 操作の回数を設定する。 8.1 節
namei キャッシュのサイズを大きくする。 11.1.2 項
AdvFS を使っている場合は,AdvFS アクセス構造体用に予約されているメモリを増やす。 11.1.5 項
UFS を使っている場合は,メタデータ・バッファ・キャッシュのサイズを大きくする。 11.1.4 項

5.6.1    NFS サーバ側の属性の変更

以下のネットワーク・ファイル・システム (nfs) サブシステム属性をチューニングすることで,ネットワーク・ファイル・システム・サーバの性能を改善できることがあります。

注意

nfs カーネル・サブシステムのパラメータには,dbx を使ったアクセスだけが可能です。 /sbin/sysconfig コマンド,または dxkerneltuner GUI では,これに相当するシステム属性はアクセスできません。 dbx についての詳細は,3.2 節を参照してください。

詳細は, sys_attrs_inet(5) を参照し,カーネル・サブシステムの変更については,第 3 章を参照してください。

5.6.1.1    書き込みの集積

クライアントから要求されたデータのディスクへの書き込みを延期する,書き込みの集積機能によって,サーバの性能が改善される可能性があります。 メタデータの更新は,書き込み要求の頻度よりも少ない頻度で行われます。 書き込みの集積機能では,要求処理サイクルを少し遅らせ,同一のディスク・ブロックへの書き込み要求がサーバに到着するのを待ちます。 しかし,サーバの CPU 時間を解放することによる全体的な利点が,多くの場合,この処理に必要なオーバヘッドを上回ります。

書き込みの集積機能は,より少ない回数で,より大きいデータの書き込みを可能にするので,帯域幅を改善します (たとえば,シークや回転待ちが少なくなります)。 NFS V3 クライアントには,非同期書き込みをサポートするものもあり,その場合,書き込みの集積機能の利点は明白ではありません。 しかし,NFS V2 クライアントやある種の NFS V3 クライアントのように,非同期書き込みをサポートしていないクライアントでは,回復時に同期書き込みが必要であり,このとき書き込みの集積機能は有効になっています。 この場合,システム性能は改善されます。

省略時の設定では,書き込みの集積機能は有効になっています。 この機能の利点を最大に活用するために,クライアントで nfsiods をチューニングすれば,大規模なサーバのスケーラビリティの改善にも効果があります。

nfs_write_gather を無効にした場合,適用されない nfs 変数があります。 たとえば,nfs_ufs_lbolt は,nfs_write_gather が有効になっているときだけ,オンまたはオフにできます。 以下の条件は,NFS V2 と NFS V3 で共通です。

変数は以下の条件で変更できます。

  1. nfs_write_gather がオン (省略時の設定) --> nfs_ufs_lbolt がオン --> サーバが書き込みを遅らせる時間を指定できる (5.6.1.2 項を参照)。

  2. nfs_write_gather がオン --> nfs_ufs_lbolt がオフ --> nfs_*_ticks を変更しても,何の影響もない。

  3. nfs_write_gather がオフ --> nfs_ufs_lbolt がオフ --> nfs_*_ticks を変更しても,何の影響もない。

PC や biod をサポートしないクライアント,あるいは書き込みを稀にしか要求しないクライアントのような単一スレッドのダム・クライアントをサービスするときは,サーバからの応答が遅れても待つので,書き込みの集積を行うとクライアントの動作が遅くなります。 これは,書き込みを遅らせるという,サーバ側に追加された待ちのオーバヘッドが原因です。 クライアントの性能を改善するには,nfs_write_gather を無効にします。 すなわち,dbx -k /vmunix を使用して,0 を設定します。 dbx についての詳細は,3.2 節または5.6.1.1.1 項を参照してください。

5.6.1.1.1    クライアントの書き込み要求に対する NFS サーバの応答速度を改善する

nfs_ufs_lbolt パラメータを 0 に変更すると,以下のいずれかの条件のときに,クライアントの書き込み要求に対する NFS サーバの応答速度が著しく改善されることがあります。

nfs_ufs_lbolt の設定は,NFS V2 プロトコルが使われているときだけ有効です。 NFS V2 の場合,NFS サーバでの同期型書き込み要求の性能改善は,書き込みの集積機能に依存します。 書き込みの集積機能の特徴の 1 つは,クライアントへの書き込みの応答を返すのを遅らせて一定の間隔内の同一ファイルに対する後続の書き込み要求を待ち受けることです。 遅延間隔内で処理されるすべての要求がストレージに安全に格納されたとき,サーバは関連する応答を同時に発行します。

サーバがクライアントからの追加の要求を待つ間隔は,シーク操作に必要な時間よりは短く,デバイスのキャッシュにフラッシュする時間よりは長い時間です。 したがって,デバイス・キャッシュが非揮発性の場合 (データはメディアへの転送が完了する前に,安全にストレージに格納されています),サーバが追加の要求を待っている時間は,効率的ではありません。 さらに,間隔が遅れることにより,同時に 1 つしか要求を発行せず,その応答を待つクライアント・システムでは,性能が低下します。

以下の例は,dbx assign コマンドを使用して,実行中のカーネルの nfs_ufs_lbolt パラメータを変更し,また dbx patch コマンドを使用して,新しい設定をディスク上の /vmunix ファイルにも確実に反映させる方法を示しています。

# dbx -k /vmunix
dbx version 5.1
Type 'help' for help.
 
(dbx) print nfs_ufs_lbolt = 1
(dbx) assign nfs_ufs_lbolt = 0
(dbx) patch nfs_ufs_lbolt = 0

nfs_ufs_lbolt パラメータは,NFS V2 を UFS で使用する場合にのみ使用するわけではありません。 このパラメータを 0 に設定すると,AdvFS や CFS (クラスタ・ファイル・システム) での NFS V2 の性能も改善されます。 しかし,クラスタ環境では,欠点があります。 NFS サーバと NFS 用の CFS サーバは,同じメンバ・システムであるとは限りません。 これらのサーバが異なるメンバ・システムにあり,nfs_ufs_lbolt が 0 に設定されている場合は,TCP マウントを通した NFS 書き込み要求に対する複数の応答は,クラスタ内の 2 つのサーバ間の 1 つの RPC にまとめられません。 この場合,RPC の数が増え,クラスタの性能が低下します。

nfs3_ufs_lbolt に 0 を設定すると,NFS V2 ではなく,NFS V3 を使用した要求について,nfs_ufs_lbolt を設定したときと同様に遅延間隔が無くなります。 NFS V3 では,クライアントの要求に対して書き込みの集積機能はほとんど利用しないので,nfs3_ufs_lbolt に 0 を設定しても,NFS V3 の性能は目立つほどには改善しません。

dbx についての詳細は,3.2 節5.6.1.1.1 項を参照してください。

5.6.1.2    サーバが書き込みを遅らせる時間を秒単位で指定する

nfs サブシステム変数の,nfs_slow_ticksnfs_fast_ticks および nfs_unkn_ticks は,書き込みの集積機能用であり,サーバが書き込みを遅らせる時間を秒単位で指定するために使用します。 書き込みの集積機能ではこれらの変数を使用して書き込みを遅らせ,同一のファイルに対する書き込み要求の数を増やすようにします。

書き込みの集積機能が無効になっていたり,nfs_ufs_lbolt がオフになっている場合は,nfs 変数は有効ではありません。 詳細は,5.6.1.1 項を参照してください。

使用中のネットワーク・カードを調べるには,以下のいずれかのコマンドを実行します。

3 つの nfs 変数のどれを使用するか指定するには,NFS クライアント/サーバ通信で使用しているネットワーク・カードを調べて,表 5-5 の値と照合します。

表 5-5:  ネットワーク・カードのタイプの確認

ネットワーク・カードのタイプ 変数 省略時の値 (ミリ秒)
FDDI nfs_fast_ticks 8
Ethernet nfs_slow_ticks 5
その他 nfs_unkn_ticks 8

ギガビット・イーサネットのような新しい高速なネットワーク・カードに対しては,nfs_slow_ticks (IFT_ETHER) のサイズを小さくすると性能が向上することがあります。

5.6.1.3    NFS 送受信バッファのサイズを大きくする

nfs_tcpsendspace および nfs_tcprecvspace 変数は,NFS での TCP ソケットの送受信バッファの省略時のサイズを指定します。 ギガビット・イーサネットのような高速のネットワーク・アダプタを使用している場合は,これらの変数の値を大きくするとシステムの性能が改善することがあります。

次のコマンドを使用してこれらの変数の値を変更します。

# dbx -k/vmunix
 

nfs_tcpsendspacenfs_tcprecvspace の省略時の値は 98304 バイトです。 NFS V3 では,I/O 転送サイズが 64 KB のとき,ほとんどのネットワーク・アダプタでの推奨値は省略時の値と同じになります。 NFS Version 2.0 では,I/O 転送サイズが 8 KB のとき,省略時の値が推奨値になります。

tcpdump を使用して,リモート・システムの NFS が 65536 バイトより大きなサイズの TCP ウィンドウをサポートしているかどうかを確認します。 TCP ウィンドウの省略時のサイズは 65536 バイトです。 省略時の設定では RFC 1323 をサポートしており,ウィンドウ・スケーリングによって大きなサイズのウィンドウを設定することができます。 ただし,リモート・システムの NFS が RFC 1323 をサポートしていないときは,接続時に送信する SYN パケットが拒否されます。

サーバの nfs_tcpsendspace ウィンドウ・サイズを大きく設定すると,パケットの送信が速くなり,性能が向上します。 クライアント側では,クライアント・システムにギガビット・イーサネットが実装されているときには同じ利点を享受することができます。

ウィンドウ・スケーリングの詳細は,『ネットワーク・プログラミング・ガイド』 を参照してください。

5.7    NFS クライアントのチューニング

クライアントにディスクまたはメモリを追加すると,2 つの理由で性能が向上します。 1 つはアクセス時間を改善できるため,2 つにはサーバやネットワークの全体の負荷が削減できるためです。 クライアントでは,共用されないファイル (ルート,スワップ領域,一時ファイルなど) に対してローカル・ディスクを使うことで,ネットワーク・ファイル・システム (NFS) の性能問題を避けることができます。 ディスクレス・クライアントの場合,メモリを追加すると,性能は著しく向上します。 クライアントのスワッピングやページングの頻度が下がるからです。 ローカル・リソースを追加することで,サーバやネットワークの負荷を減少させることができます。

クライアントの性能は,メモリやディスクを追加することで簡単に向上させることができますが,この向上策は,オペレーティング・システムの保守に必要になる管理作業を考えると,コスト効果的には優れていません。 たとえば,重要なデータをローカル・ディスクに保存している場合,ディスクのバックアップが必要になります。 データが共用されている場合は,他のシステムのアクセスも考える必要があります。 サーバにリソースを追加した場合は,クライアントにリソースを追加した場合よりも,追加の管理コストは低くなります。

以降の節では,nfs サブシステム属性を変更して,nfs の性能を改善する方法を説明します。

5.7.1    NFS クライアント側の属性の変更

以下の nfs サブシステム属性をチューニングすることで,NFS サーバの性能が改善できることがあります。

注意

nfs カーネル・サブシステムのパラメータには,dbx を使ったアクセスだけが可能です。 /sbin/sysconfig コマンド,または dxkerneltuner GUI では,これに相当するシステム属性はアクセスできません。

詳細は, sys_attrs_inet(5) を参照し,カーネル・サブシステム属性の変更については,第 3 章を参照してください。

5.7.1.1    読み取り性能を改善する

NFS バージョン 3.0 のクライアントが,長いシーケンシャルな読み込みまたは部分ブロックの書き込みを完了していて,アイドル状態のクライアントが出現した場合,NFS V3 のクライアントは,先読みを試みます。 nfs3_readahead 変数には,クライアントが先読みを行うページ数を指定しますが,最大ページ数を越えることはできません。 nfs3_maxreadahead 変数には,クライアントが先読みする最大のページ数を指定します。 nfs3_readahead の省略時の値は 2 で,nfs3_maxreadahead の省略時の値は 8 です。

先読み機能は,読み込み性能の改善に効果があります。 新しい高速なネットワーク・インタフェースを備えたシステムの場合は,両方の変数と,実行する nfsiod の数をチューニングすると,ネットワーク・インタフェースを飽和状態で動作させることができます。 これによって,ハードウェアの能力を最大限に引き出すことが可能になります。 この変数をチューニングすると,新しいギガビット・ネットワーク・カードでは,読み取り性能を 2 倍に向上させることができます。

5.7.1.2    クライアントが再送を開始するまでの時間を制御する

nfs3_jukebox_delay は,クライアントが再送を開始するまでの時間を秒単位で制御するクライアント側の変数です。 負荷の高いサーバでのトランザクション処理では,nfs3_jukebox_delay の値を大きくして,不必要なクライアントの要求の再送を減らすことができます。 nfs3_jukebox_delay の省略時の値は 10 秒です。

nfs3_jukebox_delay 変数は,ストレージ HSM メカニズムとは関係がありません。 この名前は,サーバから送信されるエラー・メッセージ NFS3ERR_JUKEBOX にちなんで付けられました。 JUKEBOX という用語は,NFS の歴史的な出来事に由来しており,ファイルが一時的にアクセスできないことを意味しています。 これによって,クライアントはサーバの状態を認識し,要求を繰り返し再送する代わりに,ファイルへのアクセスを意識的に遅らせるかどうかの判断ができるようになります。

5.7.1.3    ディレクトリ名の検索用キャッシュ (DNLC)

nfs_dnlc 変数には,ディレクトリ名の検索用キャッシュを指定します。 省略時の設定では,クライアントは最新のファイル・システム・ディレクトリの検索操作の結果のキャッシュを保持しています。 サーバへの検索要求の数が減ることになるので,クライアントの性能は改善されます。

ディレクトリ名の検索キャッシュを無効にするには,mount コマンドに -noac オプションを指定します。 -noac が mount 時に指定されていない場合は,nfs_dnlc 変数をオフにして,dnlc を無効にすることができます。

サーバがディレクトリ内のファイルを頻繁に変更している場合には,nfs_dnlc を無効にすると効果があります。 こうすると,ファイルのオープンで古いファイルのハンドルを使うのをやめて,新たに検索呼び出しを行うように強制できます。

5.7.1.4    ネガティブ名キャッシュの検索 (NNC)

nfs_nnc 変数には,ネガティブ名キャッシュを指定します。 クライアントの検索操作では,キャッシュ検索に失敗した場合,失敗した vfs 層のキャッシングを記録するために,ネガティブ名キャッシュも保持します。 これによって,将来,回線を通して同じサーバに対する不必要な検索を行わないようにします。

省略時の設定では,nfs_nnc は有効になっています。 NFS ディレクトリの検索要求を行わない,または検索要求の数の少ないアプリケーションでは,nfs_nnc を無効にするとアプリケーションの性能が改善される可能性があります。

サーバがディレクトリ内のファイルを頻繁に変更している場合には,nfs_dnlc を無効にすると効果があります。 こうすると,ファイルのオープンで古いファイルのハンドルを使うのをやめて,新たに検索呼び出しを行うように強制できます。

5.7.1.5    NFS クライアント間でのファイルの一貫性を指定する

nfs_cto 変数には,CTO (closed-to-open) 処理を指定します。 ファイルがクローズされ,そのファイルに関連するすべての変更されたデータがサーバにフラッシュされるとき,またはファイルをオープンするとき,クライアントはクライアント内のキャッシュを確認する要求を,サーバに送信します。 この操作によって,複数の NFS クライアント間でファイルの一貫性が保たれます。

マウント時に -nocto オプションを指定すると,クライアントはクローズ時にフラッシュを実行しません。 そのため,同一ファイルの,複数のクライアントに格納されているコピーが異なったものになる可能性があります。 mount コマンドの実行例は,次のとおりです。

# mount -nocto fubar:/abc/local

省略時の設定では,nfs_cto はオンになっています。 この変数をオンにすることの利点は,複数のクライアントからアクセスされるファイルの一貫性が失われる問題を回避できることです。 最初のクライアントがファイルへの書き込みを行いクローズすると,次のクライアントがそのファイルをオープンしたときに,そのクライアントにあるデータが最新のものであることが保証されます。

nfs_cto をオフにする利点は,特定のファイル・システムへのアクセスが,1 つのクライアントだけから実行される場合にあります。 この場合は,nfs_cto を無効にすると性能が改善される可能性があります。

クライアントは CTO による一貫性をマウント時に検査します。 まず,クライアントは nfs_cto 変数を検査し,mount の -nocto オプションの設定を検査します。 その後,クライアントは nfs_cto がオンになっているか,または mount の -nocto オプションが設定されていないかを検査して,CTO による一貫性の検査をします。

マウント時に -nocto オプションを使用して,nfs_cto がオフになっている場合は,dbx -k を使って nfs_cto の設定を行うと,クライアントはマウントされているファイル・システムの CTO による一貫性の検査を行うようになります。

5.7.1.6    NFS クライアントがファイル属性をフェッチする際の動きを変える

nfs_quicker_attr 変数を 0 以外の値に設定すると,ファイル属性をフェッチする (たとえば,ls -l または stat(2)) 際の NFS クライアントの動作が変わります。 省略時の設定では,NFS はファイル I/O の完了を待ってから fsync() 関数を実行して最新の属性情報を入手します。 ただし,このことによって,ディスクより高速のインタフェースを通してファイルを書き込む際に遅れが生じてしまいます。 管理された環境では,この変数を設定すると,キャッシュされた属性をフェッチするようになります。

nfs_quicker_attr 変数の変更は,テストまたはデバッグ環境で,大きなファイルの書き込みの状況を観察する際に,(たとえば,ls -l を使用して) ファイル属性を何度もフェッチするときに役に立ちます。