この章では、最適な NFS 性能を得るための推奨構成について説明します。障害追跡上のヒントについては、第 4 章「障害追跡」を参照してください。
この章では、以下の環境における推奨調整方法を説明します。
属性依存の環境
主に 100 〜 200 バイトの小さなファイルにアクセスするアプリケーションや環境です。ソフトウェア開発環境は、属性依存の環境です。
データを扱うことの多い環境
主に大きなファイルにアクセスするアプリケーションや環境です。大きなファイルとは、転送に 1 秒以上かかる、最低でも 1MB ほどのファイルと定義できます。たとえば、CAD や CAE 環境は、大きなデータを扱うことの多い環境です。
システム調整にあたっては、以下の事項を確認してください。
NFS サーバーを設定した後、システムの調整を行ってください。NFS サーバーを調整するには、ネットワーク、ディスクドライブ、CPU、メモリーと NFS 性能の関係についての基礎的な知識が必要になります。また、システムを調整するには、どのパラメタを調整すれば、バランスが良くなるかを理解しておく必要があります。
統計情報を収集します。
統計情報を収集します。
制限を受けている、または、過度に使用されている資源の特定と、それに基づくシステムを再構成します。
第 2 章「NFS 性能の分析」と、この章で推奨している調整方法の説明を参照してください。
再構成後の長期間にわたる性能測定と評価を行います。
NFS 処理は、必ずユーザーレベルのタスクに優先して、オペレーティングシステムのカーネル内部で行われます。
NFS の負荷が大きい場合に、それ以上 NFS サーバーがタスクを実行しようとすると、その処理は遅くなるため、1 台の NFS サーバー上で複数のデータベースを実行したり、複数の時分割負荷をかけたりしないでください。
一般的に、メールの送信や印刷などの非対話型処理では、NFS の処理と NFS 以外の処理という 2 つの目的にサーバーが使用されます。これらの非対話型処理には、SPARCprinter (Solaris 2.6 以降のリリースではサポートされません) や、NeWsprint(TM) ソフトウェアに基づくサンのプリンタによる処理は含まれません。CPU の処理能力に余裕があり、NFS の負荷が小さい場合は、対話型の作業は問題なく行うことができます。
十分なネットワーク帯域幅および可用性を提供することが NFS サーバーを環境設定する上で最も重要な要素となります。これを実現するには、適切な数と種類のネットワークとインタフェースを設定する必要があります。
ネットワークを設定する際は、以下のことを注意してください。
すべてのクライアントネットワークにわたって、ネットワークトラフィックを効率よく分散し、どのネットワークにも過度に負荷がかからないようにしてください。
1 つのクライアントネットワークに過度の負荷がかかっている場合は、以下を行ってください。
そのセグメントの NFS トラフィックを監視して、サーバーに対して最大の要求をしているホストを特定し、負荷を分散させる。
クライアントを別のセグメントに移す。
ディスクに対する入出力の処理が、頻繁に行われるシステムではない場合は、単にシステムにディスクを追加しても、NFS の性能が向上することはありません。ファイルサーバーのサイズが大きくなるにしたがって、ネットワークが NFS の性能を制限する要素になる可能性が高くなります。システムのバランスを保つためには、ネットワークインタフェースを追加する必要があります。
1 つのネットワークでより多くのデータブロックを転送するのではなく、代表的なクライアントが使用するデータ量の特徴を把握して、複数のネットワークに NFS の読み書きを分散させてください。
データを扱うことの多い (Data-Intensive) アプリケーションは、ほとんどの場合はネットワークを必要としません。ただし、ネットワークを使用する場合は、大きな帯域幅が必要となります。
運用環境が以下のいずれかの特徴をもつ場合は、高速なネットワーク環境が必要になります。
クライアントが全体として毎秒 1MB を超えるデータ転送速度を必要とする
複数のクライアントが、毎秒 1MB を同時に使用できる必要がある
FDDI、SunATM(TM) などの高速ネットワークを構築する
光ファイバケーブルを使用できない場合は、より対線式の FDDI や CDDI、SunFastEthernet の導入を検討してください。SunATM は、FDDI と同じサイズのファイバケーブルを採用しています。FDDI についての詳細は、『FDDI/S3.0 User's Guide』を参照してください。
同時に動作する完全に NFS アクティブなクライアント 5〜7 台につき、FDDI リング 1 つの割合でネットワークを構築する
データを扱うことの多いアプリケーションで、連続的に NFS 要求をするアプリケーションはほとんどありません。通常のデータを扱うことの多い EDA や地球資源アプリケーションでは、1リング当たりのクライアント数は 24〜40 になります。
一般的には、操作対象の大きなデータブロックを読み込んで、サーバーに書き戻すという使用方法です。こうした環境では、データを書き戻す処理があるため、書き込みの割合が非常に大きくなる可能性があります。
Ethernet ケーブルを設置している場合は、アクティブなクライアント 2 台に対して Ethernet 1 つの割合でネットワークを構築し、1 ネットワークあたりのクライアント数を最高でも 4〜6 にする
コミュニティを有用なものにするには多くのネットワークが必要になります。したがって、SPARCserver 1000/1000E、SPARCcenter 2000/2000E、Ultra Enterprise 3000/4000/5000/6000 といったシステムが必要になります。1 ネットワークあたりのクライアント数は、最大でも 4 〜 6 にしてください。
データを扱うことの多いアプリケーションと比較して、大部分の属性依存 (Atribute-Intensive) のアプリケーションは、高価なネットワークを構築せずに容易に対処することができます。ただし、属性依存のアプリケーションでも、多数のネットワークが必要となります。Ethernet やトークンリングなどの低速のネットワークメディアを使用してください。
サーバーの主要アプリケーションが、属性依存の場合の推奨ネットワーク構成は、以下のとおりです。
Ethernet またはトークンリングを構築する
完全にアクティブな 8〜10 のクライアントに Ethernet 1 つの割合でネットワークを構築する。
1 つの Ethernet あたりのクライアント数が 20〜50 を超えると、多数のクライアントがアクティブになったときに、性能が大幅に低下します。Ethernet は、衝突率は高くなりますが、SPECnfs_097 (LADDIS) ベンチマークで約 250〜300 NFS ops/秒の性能を維持することができます。継続して 200 NFS ops/秒を超えることはお薦めできません。
アクティブな 10〜15 のクライアントに対して、トークンリング 1 つの割合でネットワークを構成する。
Ethernet と比較して、大きな負荷に対する性能低下が少ないため、必要に応じて、1 つのトークンリングネットワークに対して、クライアント 50〜80 という構成にすることができます。
異なる種類のネットワークを混在させるのが一般的です。たとえば、FDDI とトークンリングはともに、文書画像作成アプリケーション (データを扱うことが多い) や、PC で動作する財務分析アプリケーション (ほとんどの場合は属性依存) をサポートするサーバーに適しています。
多数のネットワークインタフェースカードが必要になることがあるため、選択するプラットフォームは、ネットワークの種類と数によって決まります。
ディスクドライブの使用状況は、NFS サーバーの性能に依存する最も重要な要素です。ファイルシステムからのデータによって、キャッシュを素早く満たすことができない場合は、十分なメモリー構成でも、性能が改善しないことがあります。
iostat を使用してディスクの使用状況を調べます。
1 秒あたりの読み取り・書き込み回数を確認してください (第 2 章「NFS 性能の分析」を参照) 。
NFS 要求のストリームには相関関係がほとんどないため、生成されるディスクアクセスには、ディスクに対する大量のランダムアクセスが含まれます。ランダム入出力の最大回数は、ディスク 1 台当たり 40〜90 回です。
1 台のディスクドライブが、最大ランダム入出力能力の 60 %を超えて使用されると、そのディスクが性能上の障害となります。
NFS サーバーのディスク帯域幅は、NFS クライアントの性能に最も大きな影響をもちます。最高のファイルサーバー性能を得るには、ファイルシステムのキャッシュに十分な帯域幅とメモリーを用意することです。また、読み取りや書き込みの待ち時間も重要です。たとえば、NFSop ごとにディスクアクセスが伴うと、ディスクサービス時間が NFSop 待ちの時間に加わるため、ディスク動作が遅くなることは、NFS サーバーの動作も遅くなることを意味します。
ディスクのボトルネックを緩和するために、以下のガイドラインに従ってください。
システムのすべてのディスクに入出力負荷を均等に分散する。
特定のディスクの負荷が大きく、他のディスクが能力の低いレベルで動作している場合は、ディレクトリや、頻繁にアクセスするファイルを、あまり使用されていないディスクに移動してください。
負荷の大きいディスクのファイルシステムを分割し、複数のディスクに分散する
ディスクを増設することによってディスク容量が増え、ディスクの入出力帯域幅が広くなります。
NFS クライアントが使用するファイルシステムが読み取り専用になっていて、変更することのないデータが含まれている場合は、ファイルシステムを複製し、クライアントに対するネットワークからディスクへの帯域幅を広くする。
「ファイルシステムの複製の作成」を参照してください。
頻繁に使用するファイルシステムデータを、メモリー上でアクセスできるように、オぺレーティングシステム内のキャッシュを適切な大きさに設定する。
i ノード (ファイル情報ノード) やファイルシステムのメタデータ (シリンダグループ情報など) 、名前から i ノードへの変換用のキャッシュは、十分な大きさにする必要があります。十分な大きさがない場合は、キャッシュに対するヒットミスでディスクトラフィックが増加します。たとえば 、NFS クライアントがファイルをオープンする場合に、NFS サーバーでは、名前から i ノードへの変換動作が複数回行われます。
ディレクトリ名ルックアップキャッシュ (DNLC) でヒットしなかった場合は、サーバーは、ディスク上のすべてのディレクトリエントリから適切なエントリ名を探します。通常はメモリー上の処理で行われることが、複数回のディスク動作となります。このような場合は、ファイルに関係するページもキャッシュされません。
通常、NFS サーバーでは、以下のファイルシステムが使用されます。
ディスクレスクライアントの /usr ディレクトリ
ローカルツールとライブラリ
サン製品以外の一般的なパッケージ
読み取り専用のアーカイブ版ソースコード
上記のファイルシステムの複製を作成すると、ファイルシステムの性能を向上させることができます。特定の 1 つのファイルシステムに対する要求を処理する場合に、NFS サーバーは、ディスク帯域幅の制限を受けます。データの複製を作成することによって、総体的に、NFS クライアントからデータ方向へのパイプが大きくなります。ただし、複製は、ホームディレクトリからなるファイルシステムなどの書き込み可能なデータ性能の改善には、実用的な手段ではありません。複製は、読み取り専用のデータに使用してください。
ファイルシステムの複製を作成するには、以下を行います。
複製を作成するファイルまたはファイルシステムを特定します。
複数のファイルの複製を作成する場合は、1 つのファイルシステムにまとめます。
1 つのディスクに、頻繁に使用するファイルをまとめることによって生じる可能性がある性能の低下は、複製を作成することによって補うことができます。
一般的に入手可能なツール (nfswatch) を使用し、NFS サーバーグループで最も頻繁に使用されるファイルおよびファイルシステムを確認します。
表 A-1 に、nfswatch などの性能監視ツールと入手方法を紹介しています。
クライアントがどのように複製を選択するかを決定します。
/etc/vfstab ファイルにサーバー名を記述し、NFS クライアントからサーバーへの対応を指定します。もう 1 つの方法として、オートマウンタのマップに全サーバー名を記述することによって、完全に動的な結合を指定することもできます。ただし、この方法を使用すると、クライアントが一部の NFS サーバーに偏る可能性があります。クライアントグループが、専用の複製 NFS サーバーをもつ「ワークグループ」パーティションを実施した場合は、最も予測可能な性能を得ることができます。
新しいデータを配布するための更新スケジュールと方法を選定します。
新しい読み取り専用データを配布する計画と方法は、そのデータを変更する頻度によって決定してください。内容が完全に変更されてしまうファイルシステム、たとえば、毎月更新される履歴データをもつようなファイルは、各マシン上で配付媒体のデータをコピーするか、ufsdump と ufsrestore を組み合せる方法をお薦めします。ほとんど変更のないファイルシステムは、rdist などの管理ツールを使用して対処することができます。
複製サーバー上の古いデータをユーザーが使用したときに、どのような問題が生じるかを検討します。
この場合は、Solaris 2.x JumpStart(TM) 機構と cron を組み合わせる方法があります。
キャッシュファイルシステムはクライアントが中心となります。クライアント上のキャッシュファイルシステムを使用して、サーバーの負荷を軽減します。キャッシュファイルシステムを使用した場合は、ファイルはブロックごとにサーバーから読み込まれます。ファイルは、クライアントのメモリーに送られ、ファイルに対する操作は直接行われます。操作されたデータは、サーバーのディスクに書き戻されます。
マウントを行うクライアントに、キャッシュファイルシステムを追加することによって、各クライアントにローカルの複製を作成することができます。キャッシュファイルシステムの /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 を介した操作よりも多くのトラフィックが発生します。
キャッシュファイルシステムの効果を監視するには、cachefsstat コマンドを使用します (Solaris 2.5 以降で使用可能です)。
system# /usr/bin/cachefsstat [-z] パス名
-z は統計情報を初期化します。cachefsstat を実行してキャッシュ性能の統計情報を収集する前に、cachefsstat -z (スーパーユーザーのみ) を実行する必要があります。統計情報は、統計情報が再び初期化されるまでの情報を反映します。
パス名は、キャッシュファイルシステムがマウントされているパス名です。パス名を指定しないと、マウントされているすべてのキャッシュファイルシステムが対象となります。
-z オプションを使用しない限り、このコマンドを通常の UNIX ユーザーとして使用することができます。cachefsstat コマンドが提供する統計情報には、キャッシュのヒット率、一貫性の検査、および修正の数が含まれます。
表 3-1 cachefsstat コマンドが提供する統計情報出力 | 説明 |
---|---|
cache hit rate |
キャッシュの試行の数と成功した数の比率。成功した数と失敗した数が表示されます。 |
consistency checks |
一貫性の検査の実行数。合格した数と、問題があった数が表示されます。 |
modifies |
変更の数。書き込みと作成が含まれます。 |
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 は、キャッシュファイルシステムの統計情報が記録されている場合に情報を表示します。これらのコマンドを使用して、キャッシュファイルシステムが適切な状態になっているかどうかを確認してください。
ディスクドライブを設定するときは、以下の一般的なガイドラインに従ってください。データを扱うことが多い環境や属性依存の環境の場合は、一般的なガイドラインの他に、それぞれの環境に応じたガイドラインがあります。
アクティブなドライブ数が SCSI の標準ガイドラインを超えない範囲で、性能を低下させることなく、各ホストアダプタのドライブを増設する
Solstice DiskSuite を使用し、多数のディスクにディスクアクセス負荷を分散させる。
詳細は、「Solstice DiskSuite または Online: DiskSuite によるディスクのアクセス負荷の分散」を参照してください。
ディスクの最高速の領域を使用する
詳細は、「最適なディスク領域の利用」を参照してください。
データを扱うことが多い環境でのディスクドライブの構成では、以下の規則を順守してください。
逐次的な環境に設定する。
最も高速な転送速度のディスクを使用する (可能であればストライプ化する)。
アクティブなバージョン 3 のクライアント 3 台について、1 台の RAID デバイス (論理ボリュームまたはメタディスク) を設定する。または、バージョン 2 のクライアント 4、5 台について、1 台のデバイスを設定する。
Ethernet またはトークンリング上のアクティブなクライアント 1 台に対して、少なくともディスクドライブ 1 台の構成にする。
属性に依存する環境 (Atribute-Intensive)
適切な数の SCSI ホストアダプタ (ディスクアレイなど) に小型のディスクを多く接続する。
Fast SCSI ホストアダプタ 1 基に対して、4 台から 5 台以下の (または 8 台から 9 台の) ディスクドライブの構成にする。小型のディスクドライブを複数使用することは、大型のディスクドライブを 1 台使用するよりはるかに良い結果が得られます。
ネットワークのタイプに関係なく、クライアント 2 台に対して少なくともディスクドライブ 1 台の構成にする。
Fast/Wide SCSI ホストアダプタ 1 基に対して、6 台から 7 台以下の 2.9GB ディスクドライブの構成にする
NFS サーバーでは、ディスクドライブとディスクコントローラに、負荷を効率よく分散できない場合があります
負荷のバランスをとるために、以下を行ってください。
論理的な使用状況からではなく、物理的な使用状況から負荷のバランスをとってください。Solstice DiskSuite または Online: DiskSuite のストライプ機能とミラー機能により、透過的にディスクドライブに対するディスクアクセスが分散するようにします。
Solstice DiskSuite または Online: DiskSuite のディスクミラー化機能は、同じデータのコピー (2 つまたは 3 つ) にアクセスすることによって、ディスクのアクセス時間を短縮し、ディスクの使用回数を減らします。読み取りを主とする環境では特に有効です。一方、ミラー化によって作成されたディスクに対する書き込みは、通常遅くなります。これは、論理的な 1 つの要求に対して、2 回または 3 回の書き込みを行う必要があるためです。
ディスクを連結することによって、最低レベルの負荷の分散がなされますが、これは、ディスクがそれなりに満杯になっている場合だけです。
データ量の多い環境では、ディスクのスループットを改善し、サービス負荷を分散させるために飛び越し間隔の小さいストライプ処理を行ってください。ディスクのストライプ処理により、アプリケーションの連続した読み取り・書き込み速度が向上します。最初の飛び越し間隔の大きさとしては、ストライプを構成するディスク 1 台につき 64KB にしてください。
属性に依存する環境 (ディスクに対するアクセスが不規則な環境) では、デフォルトの飛び越し (1 つのディスクシリンダ) でディスクをストライプ化してください。
iostat と sar コマンドを使用して、ディスクドライブの使用状況を調べてください。
ディスクが均等に使用されるようにするには、数回にわたって監視を行い、データを再編成する必要があります。また、ディスクの使用パターンは時間とともに変化します。インストール時には最適に設定していたデータのレイアウトも、時間が経過するにしたがって、非常に効率が悪くなることがあります。ディスクドライブの使用状況を確認する方法についての詳細は、第 2 章「NFS 性能の分析」を参照してください。
Solaris 2.4 から Solaris 7 のソフトウェア環境と Online: DiskSuite 3.0 または Solstice DiskSuite を組み合せることによって、標準の UNIX ファイルシステムをログベース化し、ディスクベースの Prestoserve NFS アクセラレータのように扱うことができます。
メインのファイルシステムのディスクの他に、ディスクの一部 (一般的に 10MB の大きさ) が書き込みのシーケンシャルログ領域として使用されます。以下の 2 つの利点をもつ、このログベース化によって、Prestoserve NFS アクセラレータと同じ種類の動作が高速化されます。
デュアルマシンの高可用性 (HA) の構成では、Prestoserve NFS アクセラレータは利用することができませんが、ログは共有できるため、このような環境でも使用することができます。
オぺレーティングシステムに障害が起きた場合でも、ログベースのファイルシステムの fsck が、ログだけを順次読み取りします。大規模なファイルシステムの場合でも、ほとんど瞬時に読み取りが行われます。
1 つのファイルシステムに Prestoserve NFS アクセラレータとログを同時に使用することはできません。
ディスク上のデータレイアウトの分析をする場合は、ゾーンビット記録方式の採用を検討してください。
サンの 207MB ディスク以外のすべてのディスクには、回転するディスクに特有な幾何特性を利用し、円盤の縁に最も近い部分に、より多くのデータを詰め込むエンコーディング方式が採用されています。この方式により、通常は、外側のシリンダに対応する下位のディスクアドレスが、内側のアドレスと比較して、性能が 50 % 向上します。
若い番号のシリンダにデータを書き込みます。
ゾーンビット記録方式のデータレイアウトでは、若い番号のシリンダが高速になります。
この性能の差は、シリアル転送で顕著ですが、入出力時のランダムアクセスにも影響します。外側のシリンダ (ゼロ) は、読み取り・書き込みヘッドによるアクセスが速くなるだけでなく、サイズも大きくなります。データが分散するシリンダが少なくなることにより、シーク回数が少なくなり、シーク時間も短くなります。
この節では、CPU(中央演算処理装置) の使用状況を調査する方法と NFS サーバーの CPU を構成するときのガイドラインについて説明します。
%プロンプトに対して 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 サーバーの性能上、ディスクからメモリーへのファイルシステムデータのページングが問題になる場合があります。
vmstat 30 コマンドを実行してスキャンレートを調べます。
スキャンレート (sr、スキャンされたページ数) が毎秒 200 ページを超える場合は、メモリーが不足しています。システムは、再利用可能な未使用ページを探します。再利用可能なページをキャッシュして、NFS クライアントによる再読み取りが行えるようにします。
メモリーを増設します。
メモリーを増設することによって、同じデータが繰り返し読み取られることがなくなり、サーバーのページキャッシュとのやりとりで NFS 要求を処理することができます。NFS サーバーに必要なメモリーの大きさの計算方法については、「メモリー容量の計算」を参照してください。
最適な性能を得るために必要なメモリー容量は、そのサーバー上で使用されるファイルの大きさの合計値によって異なります。メモリーは、最近読み取られたファイルに対してはキャッシュとして動作します。キャッシュを最も効率的に使用するには、使用するファイルの大きさの合計にできるだけ近い値にします。
メモリーキャッシュ機能が使用されているため、サーバーが長時間アクティブな場合は、NFS サーバーの未使用メモリーが、0.5MB〜1.0MB の範囲になる場合があります。メモリーを十分に確保することで、複数の要求を問題なく処理することができます。
実際に使用されるファイルは、時間とともに変化します。しかしながら、全体として使用されるファイルの大きさは、比較的一定です。NFS は、ある一定の監視期間に取り扱うファイルに依存して、アクティブなファイルのスライドウインドウを作成します。
メモリー容量は、一般的なメモリー規則、または条件付きメモリー規則のいずれかの方法に従って求めることができます。
以下の一般的なガイドラインに従って、必要なメモリーの容量を計算します。
仮想メモリー = RAM (メインメモリー) + スワップ領域
5 分規則に従ってメモリー容量を計算する
メモリーの大きさは、16MB に、5 分間に 2 回以上アクセスされるデータをキャッシュするためのメモリー容量を加えた値になります。
以下の条件付きのガイドラインに従って、必要なメモリーの容量を計算します。
多くのクライアントにユーザーデータを供給するサーバーの場合は、メモリーを最低限の大きさにする。
小規模なコミュニティーでは 32MB、大規模なコミュニティーでは 128MB 程度にします。マルチプロセッサ構成では、1 プロセッサ当たり少なくとも 64MB を用意します。通常、メモリーから受ける恩恵は、データを扱うことの多いアプリケーションよりも、属性依存のアプリケーションの方が大きくなります。
ファイルを頻繁に使用するアプリケーションに、一時ファイル領域を供給することの多いサーバーの場合は、サーバー上で使用されるアクティブな一時ファイルの大きさの合計の 75 %程度のメモリー構成にする。
たとえば、各クライアントの一時ファイルの大きさが約 5MB で、サーバーが完全にアクティブの状態で 20 のクライアントを処理すると予測される場合は、メモリーを以下の大きさにします。
(20クライアント x 5MB) ÷ 75% = 133MB 簡単にメモリーを構成する場合、最も適当な大きさは 128MB です。
実行可能なイメージだけを供給することの多いサーバーの場合は、ライブラリを含めて、使用頻度の高いバイナリファイルの合計に等しい大きさのメモリー構成にする。
たとえば、/usr/openwin を供給するためのサーバーには、X サーバー、コマンドツール、libX11.so、libview.so、libXt をキャッシュするのに十分なメモリーをインストールします。この NFS アプリケーションは、あらゆるクライアントに同じファイルを繰り返し供給することを通常の仕事としていて、必要なデータを効果的にキャッシュすることができる、より一般的な /home や /src、あるいはデータサーバーと異なります。クライアントは、すべてのバイナリの全ページを必ず使用するわけではないため、頻繁に使用されるプログラムや、ライブラリを保持するために十分なメモリー構成にするのが妥当です。可能であれば、クライアントで Cachefs を使用し、サーバーに対する負荷と、サーバーで必要となるメモリー容量を減らしてください。
クライアントが DOS PC または Macintosh の場合は、Sun NFS サーバー側のメモリーキャッシュを増設する
DOS PC や Macintosh システムが行うキャッシュは、UNIX システムのクライアントが行うキャッシュよりも少なくなります。
NFS サーバーはユーザー処理を実行しないため、スワップ領域が必要になることはほとんどありません。
仮想メモリー (メインメモリー + スワップ領域) を最低でも 64MB の大きさにします。
システムに障害が発生したときに障害ダンプを保存できるように、メインメモリーの 50 % を緊急用のスワップ領域として設定します。
表 3-4 必要なスワップ領域
RAM の容量 |
必要なスワップ領域 |
---|---|
16 MB |
48 MB |
32 MB |
32 MB |
64 MB 以上 |
なし |
NFS バージョン 3 でサポートされる機能によって、Prestoserve(TM) 機能の必要性が少なくなっています。Perstoserve NFS アクセラレータは、NFS バージョン 2 と合わせて使用した場合に大きな効果が得られますが、NFS バージョン 3 と合わせて使用した場合には僅かな効果しか得られません。
NFS の性能を向上させるもう 1 つの手段として、Prestoserve NFS アクセラレータを追加するという方法があります。NFS バージョン 2 プロトコルには、あらゆる書き込みを安定した記憶領域に書き込んでから、応答をするという規定があります。この条件は、Prestoserve NFS アクセラレータを使用して、低速のディスクではなく高速の NVRAM に書き込むという形で満たすことができます。
Prestoserve NFS アクセラレータが使用する NVRAM には、以下の 2 種類があります。
NVRAM-NVSIMM
SBus
Prestoserve NFS アクセラレータの SBus と NVRAM-NVSIMM のどちらの場合も、以下の処理を行って NFS サーバーの処理を高速化します。
ファイルシステムを高速に選択する
同期入出力時の書き込みデータのキャッシュを行う
同期書き込みをディスクに対して行わずに、不揮発性メモリーにデータを格納する
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 アクセラレータは、以下のシステムにインストールすることができます。
SPARCserver 20 システム
SPARCserver 1000/1000E システム
SPARCcenter 2000/2000E システム
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 コマンドを使用して、高速書き込みを有効にしてください。
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 アクセラレータは、以下のシステムにインストールすることができます。
SPARCserver 5 システム
SPARCserver 20 システム
Sun Enterprise 1 システム
Sun Enterprise 2 システム
SPARCserver 600 シリーズ
この節では、NFS スレッド数の設定方法について説明します。さらに、/etc/system ファイルに含まれている、 NFS 性能に関連する主要パラメタの調整について説明します。/etc/system ファイルのパラメタを調整するときは、サーバーの物理メモリーの大きさやカーネルのアーキテクチャーに注意してください。
調整に問題があると、システムが不安定になり、最悪の場合には、起動ができなくなるなど問題が発生することがあります
性能の向上のために、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 つの方法のうちで最大の値を使用してください。
アクティブなクライアントプロセス 1 つに対して NFS スレッド数を 2 個にする
通常、クライアントワークステーションがもつアクティブプロセスは 1 個だけです。ただし、NFS クライアントが時分割システムの場合は、多数のアクティブプロセスをもつことがあります。
CPU 1 個に対して NFS スレッド数を 16〜32 個にする
SPARCclassic や SPARCserver 5 システムでは、NFS スレッド数を 16 個程度にします。60MHz の SuperSPARC プロセッサを搭載したシステムでは、32 個にします。
ネットワーク容量 10M ビットに対して NFS スレッド数を 16 個の割合にする
たとえば、SunFDDI` インタフェースを 1 つ使用している場合は、スレッド数を 160 に設定し、2 つ使用している場合は、スレッド数を 320 に設定します。
カーネルの固定サイズテーブル数は、Solaris ソフトウェア環境の新しいリリースが出るたびに減少しています。現在では、ほとんどのテーブルは動的にサイズ変更されるか、maxusers 値とリンクしています。Solaris 2.4 から Solaris 7 のソフトウェア環境では、さらに、DNLC と i ノードキャッシュを増やすための調整が必要になります。また、Solaris 2.4 では、ページャーの調整が必要です。Solaris 2.5、2.5.1、2.6、7 の操作環境では、ページャーの調整は必要ありません。
オぺレーティングシステムのカーネルは、起動時に /etc/system ファイルを読み込み、ロード可能なオぺレーティングシステムのカーネルモジュールの検索パスを設定して、カーネル変数を設定できるようにします。詳細は、system(4)のマニュアルページを参照してください。
/etc/system ファイルにコマンドを記述する場合は、十分に注意してください。/etc/system ファイル内のコマンドによって、カーネルの設定が自動的に変更されます。
使用しているマシンが起動せず、/etc/system に問題があると思われる場合は、 boot -a オプションを使用してください。このオプションを指定すると、システムはデフォルトの設定で起動し、起動パラメタの指定を求めます。これには、構成ファイルの /etc/system も含まれます。構成ファイル /etc/system の指定を求めるプロンプトに対しては、元の /etc/system ファイルのバックアップ用コピーの名前を入力するか、/dev/null と入力してください。ファイルを修正し、ただちにシステムを再起動して、正しく動作するかどうかを確認します。
プロセステーブルなどの各種テーブルのサイズは、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 に設定した場合、どのカーネルアーキテクチャでも安全なレベルで使用できますが、大量のオぺレーティングシステムのカーネルメモリーを使用することなります。
性能に関係するオぺレーティングシステムカーネルパラメタである、i ノードキャッシュとネームキャッシュのデフォルト値を以下に示します。
表 3-5 i ノードキャッシュとネームキャッシュのデフォルト値
カーネル資源 |
変数 |
デフォルト値 |
---|---|---|
i ノードキャッシュ | ufs_ninode |
17 * maxusers + 90 |
ネームキャッシュ | ncsize |
17 * maxusers + 90 |
/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) は、maxusers に基づいてデフォルト値が設定されます。NFS サーバーに多数のクライアントを接続している場合は、キャッシュサイズ (ncsize) を大きくしてください。大幅に性能が改善されます。
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 バイトです。
/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 に設定します。
メモリー常駐の 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.4 操作環境では、i ノード 1 個は、lg_mem pool から 300 バイトのカーネルメモリーを使用します。
Solaris 2.5.1、2.6、7 操作環境では、i ノード 1 個は、lg_mem pool から 320 バイトのカーネルメモリーを使用します。
Solaris 2.5.1、2.6、7 操作環境では、ufs_ninode は、最低でも ncsize と同じ値になるように自動的に調整されます。ヒット率を高めるために ncsize を調整し、システムがデフォルトの ufs_ninodes 値を使用できるようにしてください。
i ノードキャッシュのヒット率が 90 %より低いか、DNLC からローカルディスクのファイル入出力負荷の調整要求が出された場合は、以下の操作を行ないます。
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 ノード数だけを制限します。
システムを再起動します。
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 をサポートしていない旨の通知がある場合は、この調整を行ってください。