test

Sun NFS サーバーの調整

第 3 章 最適な NFS 性能を得るためのサーバーとクライアントの設定

この章では、最適な NFS 性能を得るための推奨構成について説明します。障害追跡上のヒントについては、第 4 章「障害追跡」を参照してください。

調整による NFS 性能の改善

この章では、以下の環境における推奨調整方法を説明します。

システム調整にあたっては、以下の事項を確認してください。

NFS サーバーを設定した後、システムの調整を行ってください。NFS サーバーを調整するには、ネットワーク、ディスクドライブ、CPU、メモリーと NFS 性能の関係についての基礎的な知識が必要になります。また、システムを調整するには、どのパラメタを調整すれば、バランスが良くなるかを理解しておく必要があります。

サーバー性能を監視、調整する

  1. 統計情報を収集します。

    統計情報を収集します。

  2. 制限を受けている、または、過度に使用されている資源の特定と、それに基づくシステムを再構成します。

    第 2 章「NFS 性能の分析」と、この章で推奨している調整方法の説明を参照してください。

  3. 再構成後の長期間にわたる性能測定と評価を行います。

NFS サーバーの負荷の分散

NFS 処理は、必ずユーザーレベルのタスクに優先して、オペレーティングシステムのカーネル内部で行われます。

注 -

NFS の負荷が大きい場合に、それ以上 NFS サーバーがタスクを実行しようとすると、その処理は遅くなるため、1 台の NFS サーバー上で複数のデータベースを実行したり、複数の時分割負荷をかけたりしないでください。

一般的に、メールの送信や印刷などの非対話型処理では、NFS の処理と NFS 以外の処理という 2 つの目的にサーバーが使用されます。これらの非対話型処理には、SPARCprinter (Solaris 2.6 以降のリリースではサポートされません) や、NeWsprint(TM) ソフトウェアに基づくサンのプリンタによる処理は含まれません。CPU の処理能力に余裕があり、NFS の負荷が小さい場合は、対話型の作業は問題なく行うことができます。

ネットワーク条件

十分なネットワーク帯域幅および可用性を提供することが NFS サーバーを環境設定する上で最も重要な要素となります。これを実現するには、適切な数と種類のネットワークとインタフェースを設定する必要があります。

ネットワークを設定する際は、以下のことを注意してください。

ディスクに対する入出力の処理が、頻繁に行われるシステムではない場合は、単にシステムにディスクを追加しても、NFS の性能が向上することはありません。ファイルサーバーのサイズが大きくなるにしたがって、ネットワークが NFS の性能を制限する要素になる可能性が高くなります。システムのバランスを保つためには、ネットワークインタフェースを追加する必要があります。

1 つのネットワークでより多くのデータブロックを転送するのではなく、代表的なクライアントが使用するデータ量の特徴を把握して、複数のネットワークに NFS の読み書きを分散させてください。

データを扱うことの多いアプリケーションに対するネットワーク条件

データを扱うことの多い (Data-Intensive) アプリケーションは、ほとんどの場合はネットワークを必要としません。ただし、ネットワークを使用する場合は、大きな帯域幅が必要となります。

運用環境が以下のいずれかの特徴をもつ場合は、高速なネットワーク環境が必要になります。

サーバーの主要アプリケーションがデータを扱うことの多い場合にネットワークを設定する

属性依存のアプリケーション

データを扱うことの多いアプリケーションと比較して、大部分の属性依存 (Atribute-Intensive) のアプリケーションは、高価なネットワークを構築せずに容易に対処することができます。ただし、属性依存のアプリケーションでも、多数のネットワークが必要となります。Ethernet やトークンリングなどの低速のネットワークメディアを使用してください。

サーバーの主要アプリケーションが、属性依存の場合の推奨ネットワーク構成は、以下のとおりです。

複数のユーザークラスが存在するシステム

異なる種類のネットワークを混在させるのが一般的です。たとえば、FDDI とトークンリングはともに、文書画像作成アプリケーション (データを扱うことが多い) や、PC で動作する財務分析アプリケーション (ほとんどの場合は属性依存) をサポートするサーバーに適しています。

多数のネットワークインタフェースカードが必要になることがあるため、選択するプラットフォームは、ネットワークの種類と数によって決まります。

  1. 複数のユーザークラスが存在するサーバーに対しては、異なる種類のネットワークを混在させます。

ディスクドライブ

ディスクドライブの使用状況は、NFS サーバーの性能に依存する最も重要な要素です。ファイルシステムからのデータによって、キャッシュを素早く満たすことができない場合は、十分なメモリー構成でも、性能が改善しないことがあります。

性能の低下の原因がディスクにあるかどうか確認する

  1. iostat を使用してディスクの使用状況を調べます。

    1 秒あたりの読み取り・書き込み回数を確認してください (第 2 章「NFS 性能の分析」を参照) 。

NFS 要求のストリームには相関関係がほとんどないため、生成されるディスクアクセスには、ディスクに対する大量のランダムアクセスが含まれます。ランダム入出力の最大回数は、ディスク 1 台当たり 40〜90 回です。

1 台のディスクドライブが、最大ランダム入出力能力の 60 %を超えて使用されると、そのディスクが性能上の障害となります。

ディスクボトルネックの緩和

NFS サーバーのディスク帯域幅は、NFS クライアントの性能に最も大きな影響をもちます。最高のファイルサーバー性能を得るには、ファイルシステムのキャッシュに十分な帯域幅とメモリーを用意することです。また、読み取りや書き込みの待ち時間も重要です。たとえば、NFSop ごとにディスクアクセスが伴うと、ディスクサービス時間が NFSop 待ちの時間に加わるため、ディスク動作が遅くなることは、NFS サーバーの動作も遅くなることを意味します。

ディスクのボトルネックを緩和するために、以下のガイドラインに従ってください。

ファイルシステムの複製の作成

通常、NFS サーバーでは、以下のファイルシステムが使用されます。

上記のファイルシステムの複製を作成すると、ファイルシステムの性能を向上させることができます。特定の 1 つのファイルシステムに対する要求を処理する場合に、NFS サーバーは、ディスク帯域幅の制限を受けます。データの複製を作成することによって、総体的に、NFS クライアントからデータ方向へのパイプが大きくなります。ただし、複製は、ホームディレクトリからなるファイルシステムなどの書き込み可能なデータ性能の改善には、実用的な手段ではありません。複製は、読み取り専用のデータに使用してください。

ファイルシステムの複製を作成するには、以下を行います。

キャッシュファイルシステムの追加

キャッシュファイルシステムはクライアントが中心となります。クライアント上のキャッシュファイルシステムを使用して、サーバーの負荷を軽減します。キャッシュファイルシステムを使用した場合は、ファイルはブロックごとにサーバーから読み込まれます。ファイルは、クライアントのメモリーに送られ、ファイルに対する操作は直接行われます。操作されたデータは、サーバーのディスクに書き戻されます。

マウントを行うクライアントに、キャッシュファイルシステムを追加することによって、各クライアントにローカルの複製を作成することができます。キャッシュファイルシステムの /etc/vfstab エントリは、以下のようになります。 

# device    device    mount    FS    fsck    mount    mount
# to mount  to fsck   point    type  pass    at boot  options
server:/usr/dist      cache    /usr/dist     cachefs  3  yes
ro,backfstype=nfs,cachedir=/cache

アプリケーションファイルシステムなど、頻繁に読まれるファイルシステムに対してキャッシュファイルシステムを使用してください。それ以外にキャッシュファイルシステムを使用する状況として、遅いネットワーク上でデータを共有している場合があります。複製サーバーとは異なり、キャッシュファイルシステムは、書き込み可能なファイルシステムと組み合せることができますが、書き込みの割合が高くなるにしたがって性能が低下します。書き込みの割合が高すぎる場合は、キャッシュファイルシステムによって NFS の性能が低下する場合があります。

また、使用しているネットワークがルーターによって相互接続された高速のネットワークである場合にも、キャッシュファイルシステムの使用を検討する必要があります。

NFS サーバーが頻繁に更新されている場合は、キャッシュファイルシステムを使用しないでください。キャッシュファイルシステムを使用すると、NFS を介した操作よりも多くのトラフィックが発生します。

  1. キャッシュファイルシステムの効果を監視するには、cachefsstat コマンドを使用します (Solaris 2.5 以降で使用可能です)。

    cachefsstat コマンドの構文は以下のとおりです。 

    system# /usr/bin/cachefsstat [-z] パス名

    -z は統計情報を初期化します。cachefsstat を実行してキャッシュ性能の統計情報を収集する前に、cachefsstat -z (スーパーユーザーのみ) を実行する必要があります。統計情報は、統計情報が再び初期化されるまでの情報を反映します。

    パス名は、キャッシュファイルシステムがマウントされているパス名です。パス名を指定しないと、マウントされているすべてのキャッシュファイルシステムが対象となります。

    -z オプションを使用しない限り、このコマンドを通常の UNIX ユーザーとして使用することができます。cachefsstat コマンドが提供する統計情報には、キャッシュのヒット率、一貫性の検査、および修正の数が含まれます。

    表 3-1 cachefsstat コマンドが提供する統計情報
     出力 説明
     cache hit rate

    キャッシュの試行の数と成功した数の比率。成功した数と失敗した数が表示されます。 
     consistency checks

    一貫性の検査の実行数。合格した数と、問題があった数が表示されます。 
     modifies

    変更の数。書き込みと作成が含まれます。 

    cachefsstat コマンドの使用例を以下に示します。 

    system% /usr/bin/cachefsstat /home/sam
cache hit rate: 73% (1234 hits, 450 misses)
consistency checks:  700 (650 pass, 50 fail)
modifies: 321

上記の例では、ファイルシステムにおけるキャッシュのヒット率は 30 % よりも高くなっている必要があります。キャッシュのヒット率が 30 % よりも低い場合は、ファイルシステムに対するアクセスが全体的に不規則であるか、キャッシュが大きさが不十分であることを意味しています。

一貫性の検査の結果は、キャッシュファイルシステムがサーバーに対してデータが有効であるかどうかを検査した結果です。失敗率が高い場合は (15 〜 20 %)、検査対象のデータが頻繁に変更されていることを意味しています。キャッシュは、キャッシュされたファイルシステムよりも高速に更新することができる可能性があります。一貫性の検査の結果と変更の数を調べることによって、このクライアントが変更を行っているのか、他のクライアントが変更を行っているのかを調べることができます。

変更の数は、クライアントがファイルシステムに変更を行った回数です。この結果を調べることは、ヒット率が低い理由を調べるもう 1 つの方法です。変更の数が多いと、通常は一貫性の検査の数が多くなり、ヒット率が低くなります。

Solaris 2.5 以降では、cachefswssize と cachefsstat を使用することができます。cachefswssize は、キャッシュファイルシステムで使用されるファイルのサイズの合計を表示します。cachefsstat は、キャッシュファイルシステムの統計情報が記録されている場合に情報を表示します。これらのコマンドを使用して、キャッシュファイルシステムが適切な状態になっているかどうかを確認してください。

ディスクドライブを設定する上での規則

ディスクドライブを設定するときは、以下の一般的なガイドラインに従ってください。データを扱うことが多い環境や属性依存の環境の場合は、一般的なガイドラインの他に、それぞれの環境に応じたガイドラインがあります。

データを扱うことが多い環境でのディスクドライブの構成では、以下の規則を順守してください。

属性に依存する環境 (Atribute-Intensive)

Solstice DiskSuite または Online: DiskSuite によるディスクのアクセス負荷の分散

NFS サーバーでは、ディスクドライブとディスクコントローラに、負荷を効率よく分散できない場合があります

負荷のバランスをとるために、以下を行ってください。

ディスクが均等に使用されるようにするには、数回にわたって監視を行い、データを再編成する必要があります。また、ディスクの使用パターンは時間とともに変化します。インストール時には最適に設定していたデータのレイアウトも、時間が経過するにしたがって、非常に効率が悪くなることがあります。ディスクドライブの使用状況を確認する方法についての詳細は、第 2 章「NFS 性能の分析」を参照してください。

Solstice DiskSuite または Online: DiskSuite 3.0 によるファイルシステムのログベース化

Solaris 2.4 から Solaris 7 のソフトウェア環境と Online: DiskSuite 3.0 または Solstice DiskSuite を組み合せることによって、標準の UNIX ファイルシステムをログベース化し、ディスクベースの Prestoserve NFS アクセラレータのように扱うことができます。

メインのファイルシステムのディスクの他に、ディスクの一部 (一般的に 10MB の大きさ) が書き込みのシーケンシャルログ領域として使用されます。以下の 2 つの利点をもつ、このログベース化によって、Prestoserve NFS アクセラレータと同じ種類の動作が高速化されます。

最適なディスク領域の利用

ディスク上のデータレイアウトの分析をする場合は、ゾーンビット記録方式の採用を検討してください。

サンの 207MB ディスク以外のすべてのディスクには、回転するディスクに特有な幾何特性を利用し、円盤の縁に最も近い部分に、より多くのデータを詰め込むエンコーディング方式が採用されています。この方式により、通常は、外側のシリンダに対応する下位のディスクアドレスが、内側のアドレスと比較して、性能が 50 % 向上します。

  1. 若い番号のシリンダにデータを書き込みます。

    ゾーンビット記録方式のデータレイアウトでは、若い番号のシリンダが高速になります。

    この性能の差は、シリアル転送で顕著ですが、入出力時のランダムアクセスにも影響します。外側のシリンダ (ゼロ) は、読み取り・書き込みヘッドによるアクセスが速くなるだけでなく、サイズも大きくなります。データが分散するシリンダが少なくなることにより、シーク回数が少なくなり、シーク時間も短くなります。

CPU

この節では、CPU(中央演算処理装置) の使用状況を調査する方法と NFS サーバーの CPU を構成するときのガイドラインについて説明します。

CPU の使用状況を調査する

  1. %プロンプトに対して mpstat 30 と入力して 30 秒間の平均値を得ます。

    以下が画面に表示されます。: 

    system% mpstat 30
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    6   0    0   114   14   25    0    6    3    0    48    1   2  25  72
  1    6   0    0    86   85   50    0    6    3    0    66    1   4  24  71
  2    7   0    0    42   42   31    0    6    3    0    54    1   3  24  72
  3    8   0    0     0    0   33    0    6    4    0    54    1   3  24  72

mpstat 30 コマンドは、各プロセッサの統計情報を表示します。表の各行は、1 つのプロセッサのアクティビティー情報です。最初の行は、システムが最後に起動されてからの全アクティビティー情報で、それ以降の行が、各時間間隔のアクティビティー情報を表しています。すべての値が、1 秒当たりのイベント数に基づく割合を表します。

mpstat 出力の各欄の項目の意味は、以下のとおりです。

表 3-2 mpstat コマンドの出力
 usr

ユーザー時間の割合 
 sys

システム時間の割合 
 wt

待ち時間の割合 
 idl

アイドル時間の割合 

sys が 50% を超えている場合は、CPU パワーを大きくして、NFS の性能を改善してください。

NFS サーバーの CPU を構成する場合のガイドラインを以下に示します。

表 3-3 サーバーの CPU を構成する場合のガイドライン

条件 

処置 

中速の Ethernet またはトークンリングネットワーク、1〜3 個の構成で、主として属性依存の環境である 

単一プロセッサで十分です。さらに小規模なシステムの場合は、UltraServer 1、SPARCserver 5、SPARCserver 4 のいずれかのシステムで、サーバーとして十分なプロセッサの処理能力が得られます。 

中速の Ethernet またはトークンリングネットワーク、4〜60 個の構成で、主として属性依存の環境であ 

UltraServer 2、SPARCserver 20、SPARCserver 10 のいずれかのシステムを使用してください。 

大規模な属性依存の環境であり、SBus とディスクを拡張する十分な余裕がある 

UltraServer 2、SPARCserver 20、SPARCserver 10 のいずれかのシステムのマルチプロセッサモデルを使用してください。 

大規模な属性依存の環境である. 

以下のようなデュアルプロセッサシステムを使用してください。 

- SPARCserver 10 システムモデル 512 

- SPARCserver 20 システム 

- SPARCserver 1000/1000E システム 

- Sun Enterprise 3000/4000/5000/6000、3500/4500/5500/6500 システム 

- SPARCcenter 2000/2000E システム 

SPARCcenter 2000 システムの 40MHz/1MB または 50MHz/2MB モジュールのいずれも NFS の負荷に対して問題ありませんが、50MHz/2MB モジュールの方がより良い性能が得られます。 

データを扱うことの多い環境で、高速なネットワークがある 

高速なネットワーク (FDDI など) 1 つに対して SuperSPARC プロセッサ 1 基の構成にしてください。 

データを扱うことの多い環境であるが、ケーブルに制限があり、Ethernet を使用する必要がある 

Ethernet またはトークンリングネットワーク 4 つに SuperSPARC プロセッサ 1 基の構成にしてください。 

純粋な NFS 環境である. 

推奨する台数を超えて、サーバーのプロセッサを増設する必要はありません 

NFS 処理以外の処理をサーバーで行う 

プロセッサを増設して、大幅な性能向上を図ってください。 

メモリー

NFS はディスク入出力処理の多いサービスのため、低速のサーバーは、入出力が問題になることがあります。メモリーを増設し、ファイルシステムキャッシュを大きくすることによって、この入出力の問題は解消します。

システムは、ファイルシステムのページ待ち状態である場合や、スワップデバイスとの間でプロセスイメージをページングしている場合もあります。NFS サービスは、完全にオぺレーティングシステムのカーネル内で動作するため、ページング中にさらにサービスが供給された場合にだけ問題となります。

スワップデバイスで入出力動作が何も行われていない場合は、すべてのページング動作は、NFS 読み取りや書き込み、属性、ルックアップなどのファイル入出力操作に伴います。

NFS サーバーがメモリーを大量に使用するかどうかの調査

NFS サーバーの性能上、ディスクからメモリーへのファイルシステムデータのページングが問題になる場合があります。

NFS サーバーシステムがメモリーを大量に使用するかどうかを調査する

  1. vmstat 30 コマンドを実行してスキャンレートを調べます。

    スキャンレート (sr、スキャンされたページ数) が毎秒 200 ページを超える場合は、メモリーが不足しています。システムは、再利用可能な未使用ページを探します。再利用可能なページをキャッシュして、NFS クライアントによる再読み取りが行えるようにします。

  2. メモリーを増設します。

    メモリーを増設することによって、同じデータが繰り返し読み取られることがなくなり、サーバーのページキャッシュとのやりとりで NFS 要求を処理することができます。NFS サーバーに必要なメモリーの大きさの計算方法については、「メモリー容量の計算」を参照してください。

最適な性能を得るために必要なメモリー容量は、そのサーバー上で使用されるファイルの大きさの合計値によって異なります。メモリーは、最近読み取られたファイルに対してはキャッシュとして動作します。キャッシュを最も効率的に使用するには、使用するファイルの大きさの合計にできるだけ近い値にします。

メモリーキャッシュ機能が使用されているため、サーバーが長時間アクティブな場合は、NFS サーバーの未使用メモリーが、0.5MB〜1.0MB の範囲になる場合があります。メモリーを十分に確保することで、複数の要求を問題なく処理することができます。

実際に使用されるファイルは、時間とともに変化します。しかしながら、全体として使用されるファイルの大きさは、比較的一定です。NFS は、ある一定の監視期間に取り扱うファイルに依存して、アクティブなファイルのスライドウインドウを作成します。

メモリー容量の計算

メモリー容量は、一般的なメモリー規則、または条件付きメモリー規則のいずれかの方法に従って求めることができます。

一般的なメモリー規則

以下の一般的なガイドラインに従って、必要なメモリーの容量を計算します。

メモリーの大きさは、16MB に、5 分間に 2 回以上アクセスされるデータをキャッシュするためのメモリー容量を加えた値になります。

条件付きのメモリー規則

以下の条件付きのガイドラインに従って、必要なメモリーの容量を計算します。

スワップ領域

NFS サーバーはユーザー処理を実行しないため、スワップ領域が必要になることはほとんどありません。

スワップ領域を設定する

  1. 仮想メモリー (メインメモリー + スワップ領域) を最低でも 64MB の大きさにします。

  2. システムに障害が発生したときに障害ダンプを保存できるように、メインメモリーの 50 % を緊急用のスワップ領域として設定します。

    表 3-4 必要なスワップ領域

    RAM の容量 

    必要なスワップ領域 

    16 MB 

    48 MB 

    32 MB 

    32 MB 

    64 MB 以上 

    なし 

Prestoserve NFS アクセラレータ

注 -

NFS バージョン 3 でサポートされる機能によって、Prestoserve(TM) 機能の必要性が少なくなっています。Perstoserve NFS アクセラレータは、NFS バージョン 2 と合わせて使用した場合に大きな効果が得られますが、NFS バージョン 3 と合わせて使用した場合には僅かな効果しか得られません。

NFS の性能を向上させるもう 1 つの手段として、Prestoserve NFS アクセラレータを追加するという方法があります。NFS バージョン 2 プロトコルには、あらゆる書き込みを安定した記憶領域に書き込んでから、応答をするという規定があります。この条件は、Prestoserve NFS アクセラレータを使用して、低速のディスクではなく高速の NVRAM に書き込むという形で満たすことができます。

Prestoserve NFS アクセラレータが使用する NVRAM には、以下の 2 種類があります。

Prestoserve NFS アクセラレータの SBus と NVRAM-NVSIMM のどちらの場合も、以下の処理を行って NFS サーバーの処理を高速化します。

NVRAM-NVSIMM

SBus、NVRAM-NVSIMM のどちらの NVRAM ハードウェアも使用できる場合は、Prestoserve キャッシュとして NVRAM-NVSIMM を使用してください。NVRAM-NVSIMM と SBus ハードウェアは機能的には同じですが、効率性の面で NVRAM-NVSIMM の方が若干優れており、SBus スロットを使用しません。NVRAM-NVSIMM はメモリーに置かれ、キャッシュも SBus ハードウェアにくらべて大きくなります。

NVRAM-NVSIMM Prestoserve NFS アクセラレータは、負荷の大きい NFS クライアントや、入出力バウンドのサーバーの応答時間を大幅に改善することができます。 NVRAM-NVSIMM Prestoserve NFS アクセラレータは、以下のシステムにインストールすることができます。

Sun Enterprise 3000/4000/5000/6000、3500/4500/5500/6500 システムの場合は、NFS 性能向上のもう 1 つの手段として、サーバーに接続された SPARCstorage Array の NVRAM をアップグレードします。

Sun Enterprise 3000/4000/5000/6000、3500/4500/5500/6500 システムでは、SPARCstorage Array NVRAM 高速書き込みを行うことができます。ssaadm コマンドを使用して、高速書き込みを有効にしてください。

NVRAM SBus

SBus Prestoserve NFS アクセラレータには、1MB のキャッシュのみを搭載し、SBus に接続します。SPARCserver 1000(E)、SPARCcenter 2000(E)、Sun Enterprise 3000/4000/5000/6000、3500/4500/5500/6500 システム以外の SBus を備えているサーバにインストールすることができます。

SBus Prestoserve NFS アクセラレータは、以下のシステムにインストールすることができます。

パラメタの調整

この節では、NFS スレッド数の設定方法について説明します。さらに、/etc/system ファイルに含まれている、 NFS 性能に関連する主要パラメタの調整について説明します。/etc/system ファイルのパラメタを調整するときは、サーバーの物理メモリーの大きさやカーネルのアーキテクチャーに注意してください。

注 -

調整に問題があると、システムが不安定になり、最悪の場合には、起動ができなくなるなど問題が発生することがあります

NFS スレッド数の設定 (/etc/init.d/nfs.server)

性能の向上のために、NFS サーバーを設定する際には、必ず NFS スレッドを設定します。スレッド 1 つは、NFS 要求を 1 つ処理することができます。スレッドプールを大きくすることにより、サーバーは複数の NFS 要求を並行して処理することができます。Solaris 2.4 から Solaris 7 ソフトウェア環境では、デフォルトの設定は 16 であり、望ましい NFS 応答時間は得られません。プロセッサ数とネットワーク数に従って、このデフォルト値を大きくしてください。NFS サーバーのスレッド数は、/etc/init.d/nfs.server 内の nfsd 呼び出し行を編集することによって変更します。 

/usr/lib/nfs/nfsd -a 64

上記のコード例 では、要求時 NFS スレッドの最大割当数を 64 に指定しています。

NFS スレッド数を変更する方法は 3 つあります。本書の構成上の規則に従っているかぎり、どの方法を使用してもほぼ同じ数になります。NFS スレッドの数が余分にある場合も、問題が生じることはありません。

NFS スレッドの数を設定するには、以下の 3 つの方法のうちで最大の値を使用してください。

バッファーサイズの確認と変数の調整

カーネルの固定サイズテーブル数は、Solaris ソフトウェア環境の新しいリリースが出るたびに減少しています。現在では、ほとんどのテーブルは動的にサイズ変更されるか、maxusers 値とリンクしています。Solaris 2.4 から Solaris 7 のソフトウェア環境では、さらに、DNLC と i ノードキャッシュを増やすための調整が必要になります。また、Solaris 2.4 では、ページャーの調整が必要です。Solaris 2.5、2.5.1、2.6、7 の操作環境では、ページャーの調整は必要ありません。

/etc/system によるカーネル変数の変更

オぺレーティングシステムのカーネルは、起動時に /etc/system ファイルを読み込み、ロード可能なオぺレーティングシステムのカーネルモジュールの検索パスを設定して、カーネル変数を設定できるようにします。詳細は、system(4)のマニュアルページを参照してください。

注意 - 注意 -

/etc/system ファイルにコマンドを記述する場合は、十分に注意してください。/etc/system ファイル内のコマンドによって、カーネルの設定が自動的に変更されます。

使用しているマシンが起動せず、/etc/system に問題があると思われる場合は、 boot -a オプションを使用してください。このオプションを指定すると、システムはデフォルトの設定で起動し、起動パラメタの指定を求めます。これには、構成ファイルの /etc/system も含まれます。構成ファイル /etc/system の指定を求めるプロンプトに対しては、元の /etc/system ファイルのバックアップ用コピーの名前を入力するか、/dev/null と入力してください。ファイルを修正し、ただちにシステムを再起動して、正しく動作するかどうかを確認します。

キャッシュサイズの調整 (maxusers)

プロセステーブルなどの各種テーブルのサイズは、maxusers パラメタ値によって決定します。maxusers パラメタは、以下の形式で /etc/system ファイルに設定します。 

set maxusers = 200

Solaris 2.4 から Solaris 7 のソフトウェア環境では、maxusers は、システムに搭載されているメモリー容量に基づいて動的に設定されます。設定は以下の式で表されます。 

maxusers = システム内の構成されている RAM (MB)

メモリー容量 (MB) は、実際には、起動時にカーネルが使用する 2MB 程度を除いた値であり、physmem で表されます。最小値は 8、自動設定される最大値は 1024 であり、この最大値は 1GB 以上のメモリーを搭載したシステムに有効です。ユーザー自身が /etc/system に maxusers を設定することもできますが、設定された値はチェックされ、最大でも 2048 に制限されます。2048 に設定した場合、どのカーネルアーキテクチャでも安全なレベルで使用できますが、大量のオぺレーティングシステムのカーネルメモリーを使用することなります。

maxusers から導出するパラメタ

性能に関係するオぺレーティングシステムカーネルパラメタである、i ノードキャッシュとネームキャッシュのデフォルト値を以下に示します。

表 3-5 i ノードキャッシュとネームキャッシュのデフォルト値

カーネル資源 

変数 

デフォルト値 

i ノードキャッシュ 

 ufs_ninode

17 * maxusers + 90

ネームキャッシュ 

 ncsize

17 * maxusers + 90

バッファーキャッシュの調整 (bufhwm)

/etc/system ファイルに設定する bufhwm 変数は、バッファーキャッシュに割り当てる最大メモリー容量を決定し、KB 数で指定します。bufhwm のデフォルト値は 0 であり、この設定で、システムはシステムメモリーの 2 %まで使用することができます。バッファーキャッシュに使用可能な大きさは、最大でシステムメモリーの 20 %です。NFS 専用のファイルサーバーで、メモリーが比較的小容量の場合は、10 %程度にする必要が生じることがあります。大きなシステムの場合、オぺレーティングシステムのカーネルの仮想アドレス空間が不足しないように、さらに制限する必要があります。

バッファーキャッシュは、i ノードや間接ブロック、シリンダグループ関係のディスク入出力をキャッシュする目的にのみ使用されます。以下の例では、バッファーキャッシュ (bufhwm) を最大で 10MB まで確保できるように bufhwm を設定しています。通常、これ以上の値は設定しないでください。 

set bufhwm=10240

バッファーキャッシュの読み取りヒット率 (%rcache) と書き込みヒット率 (%wcache) を表示する sar -b コマンドを実行して (以下のコード例を参照)、バッファーキャッシュを監視することができます。 

# sar -b 5 10
SunOS hostname 5.2 Generic sun4c    08/06/93
23:43:39 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s
Average        0      25     100       3      22      88       0       0

バッファーキャッシュの読み取りヒット率 (%rcache) と書き込みヒット率 (%wcache) を表示する sar -b コマンドを実行して (以下のコード例を参照)、バッファーキャッシュを監視することができます。

上記の sar -b 5 10 コマンドの出力例では、読み取りヒット率が 90% 以上、書き込みヒット率が 65% 以上になっています。

sar コマンドの引数の意味は、以下のとおりです。

表 3-6 sar コマンドの引数
 b

バッファーの使用状況を検査します。 
 5

5 秒おきに検査します (最低でも 5 秒にします)。 
 10

統計情報を収集する回数です。 

システムは、バッファーキャッシュのサイズが許容範囲を超えることを防ぎます。バッファーキャッシュサイズを大きくすると、以下の問題が発生します。

ディレクトリ名ルックアップキャッシュ (DNLC)

ディレクトリ名ルックアップキャッシュ (DNLC) は、maxusers に基づいてデフォルト値が設定されます。NFS サーバーに多数のクライアントを接続している場合は、キャッシュサイズ (ncsize) を大きくしてください。大幅に性能が改善されます。

  1. DNLC のヒット率 (cache hits) を調べるには、vmstat -s と入力します。. 

    % vmstat -s
...[略]...
79062 total name lookups (cache hits 94%)
16 toolong

30 文字より短い長さのディレクトリ名はキャッシュされ、長すぎてキャッシュ不可能なディレクトリ名は報告だけされます。キャッシュされなかった場合は、ファイルを得るためにパス名の要素を検索していく際に、ディレクトリ名を読むというディスクの入出力が必要になります。ヒット率が 90 %よりはるかに低い場合は、注意が必要です。

NFS の性能が、キャッシュのヒット率によって大きな影響を受ける場合があります。getattr と setattr、lookup は、通常、全 NFS コールの 50 %より大きな値になります。要求された情報がキャッシュにない場合は、ディスクアクセスを行うので、read あるいは write 要求にともなう性能の低下が生じます。DNLC キャッシュの大きさを制限する要素は、使用可能なカーネルメモリーの容量です。

特に長い名前を多用していないのに、ヒット率（cache hits）が 90% より低い場合は、ncsize 変数を調整します (以下を参照)。ncsize 変数は、DNLC キャッシュの大きさを、キャッシュすることが可能な名前変換、および v ノード変換の数で表します。DNLC エントリ 1 個に使用されるカーネルメモリーは、約 50 バイトです。

ncsize を設定する

  1. /etc/system ファイルを開き、ncsize を設定します。maxusers 値に基づき、デフォルトより大きな値を設定します。

    As an initial guideline, since dedicated NFS servers do not need a lot of RAM, maxusers will be low and the DNLC will be small; double its size. 

    set ncsize=5000

    ncsize のデフォルト値は以下の式で表されます。

    ncsize (ネームキャッシュ) = 17 * maxusers + 90

    • NFS サーバーのベンチマークでは、16000 に設定されています。

    • maxusers = 2048 の場合は、34906 に設定します。

  1. システムを再起動します。

    以下を参照してください。

i ノードキャッシュの拡張

メモリー常駐の i ノードは、ファイルシステム内の実体の操作が行われるたびに使用されます。ディスクから読み取られた i ノードは、再び必要になる場合のために、キャッシュされます。ufs_ninode は、アイドル状態のノードのリストを UNIX ファイルシステムが保持しようとするサイズです。ufs_ninode を 1 に設定することによって、10,000 のアイドルノードが保持されます。アイドルノードの数が ufs_ninode を超えると、アイドルノードを削除することによってメモリーの空き領域が確保されます。

DNLC キャッシュのエントリは、それぞれ i ノードキャッシュのエントリに対応しています。そのため、i ノードキャッシュのサイズを変更する場合は、DNLC キャッシュのサイズも変更してください。また、i ノードキャッシュの大きさは、最低でも DNLC キャッシュと同じ大きさにする必要があります。最高の性能を得るには、Solaris 2.4 から Solaris 7 のソフトウェア環境では DNLC キャッシュと同じ大きさにすることを推奨します。

動作中のシステムで adb を使用して ufs_ninode を操作し、ただちにその結果を確認することができます。ufs_ninode の最大値は、i ノードが使用するカーネルメモリーの容量によって制限されます。この上限は maxusers = 2048 に対応しており、ncsize では 34906 になります。

カーネルメモリに割り当てられている容量は、sar -k を実行して調べます。

Solaris 2.5.1、2.6、7 操作環境では、ufs_ninode は、最低でも ncsize と同じ値になるように自動的に調整されます。ヒット率を高めるために ncsize を調整し、システムがデフォルトの ufs_ninodes 値を使用できるようにしてください。

Solaris 2.4 または 2.5 ソフトウェア環境において i ノードキャッシュを大きくする

i ノードキャッシュのヒット率が 90 %より低いか、DNLC からローカルディスクのファイル入出力負荷の調整要求が出された場合は、以下の操作を行ないます。

  1. i ノードキャッシュの大きさを大きくします。

    /etc/system ファイルの ufs_ninode を DNLC (ncsize) と同じ値に設定してください。たとえば Solaris 2.4 ソフトウェア環境では、以下のように設定します。 

    set ufs_ninode=5000

    i ノードキャッシュのデフォルト値は、ncsize と同じです。

    ufs_ninode (デフォルト値) = 17 * maxusers + 90

    注意 - 注意 -

    ncsize より小さな値を ufs_ninode に設定しないでください。ufs_ninode は、アクティブとアクティブではない i ノードの合計ではなく、アクティブではない i ノード数だけを制限します。

  2. システムを再起動します。

読み取りスループットの向上

FDDI、SunFastEthernet、SunATM` などの高速なネットワークでは、NFS クライアント側の先読み量を増やすことで、NFS の読み取りスループットが向上します。

以下の場合は、先読み値を増やさないでください。

使用可能なメモリーの量が十分に確保できない場合には、先読みは行われません。

デフォルトでは、先読みは 1 ブロック (バージョン 2 では 8KB、バージョン 3 では 32 KB) に設定されています。先読みを 2 ブロックに設定すると、ファイルから最初の 8 KB を読み取っている間に、次の 16K バイトがフェッチされます。先読みでは、8KB 単位で情報をフェッチすることによって、前もって新しい情報を確保しておくことができます。

先読み量をを増やすことによって、ある点までは読み取りスループットを向上させることができます。先読み量の最大値は、構成やアプリケーションによって異なります。先読み量が最大値を超えると、スループットが低下する場合があります。通常、先読み値を 8 (8 ブロック) より大きくしても、スループットは改善しません。

注 -

以下の手順では、nfs_nra と nfs3_nra 値は別々に調整することができます。Solaris 2.5。2.5.1、2.6、7 のいずれかがクライアントで動作している場合は、nfs_nra の調整が必要になることがあります (NFS バージョン 2)。クライアントからサーバーに、バージョン 3 をサポートしていない旨の通知がある場合は、この調整を行ってください。

先読み値を大きくする (NFS バージョン 2)

  1. NFS クライアントの /etc/system に以下の行を追加します。. 

    set nfs:nfs_nra=4

  2. システムを再起動して、新しい先読み値を有効にします。

先読み値を大きくする (NFS バージョン 3)

  1. NFS クライアントの/etc/system に以下の行を追加します。:

    • Solaris 2.6 より前の場合。 

      set nfs:nfs3_nra=6

    • Solaris 2.6 の場合。 

      set nfs:nfs3_nra=2

    • Solaris 7 の場合。 

      set nfs:nfs3_nra=4

      注 -

      先読み値を大きくしすぎると、読み取りのスループットが悪くなります。使用している環境における最適の値を見つけるために、nfs3_nra や nfs_nra の異なる値でベンチマークを行うことを推奨します。

  2. システムを再起動して、新しい先読み値を有効にします。