基本的な配備でのパフォーマンスの向上

もっとも基本的な配備でも、特定の領域のパフォーマンスを向上させるために Directory Server の調整が必要になる場合があります。以降の節では、単純な単一サーバー配備に適用できる、基本的なチューニング戦略について説明します。これらの戦略は、トポロジ全体のパフォーマンスを向上させるために、より大規模で、より複雑な配備内の各サーバーにも適用できます。

検索を高速化するためのインデックスの使用

インデックスを使用すると、検索で一致するものを見つけるためにチェックする必要のあるエントリの数が実質的に削減されるため、検索が高速化されます。インデックスには、値のリストが含まれています。各値は、エントリ識別子のリストに関連付けられています。Directory Server は、インデックス内のエントリ識別子のリストを使用して、各エントリをすばやく検索できます。Directory Server が、インデックスのない状態でエントリのリストを管理するには、検索で一致するものを見つけるためにサフィックス内のすべてのエントリをチェックする必要があります。

Directory Server は、各検索要求を次のように処理します。

1. Directory Server がクライアントから検索要求を受信します。

2. Directory Server は要求を検査して、その検索を処理できることを確認します。

   Directory Server が検索を実行できない場合は、クライアントにエラーを返します。また、その検索を Directory Server の別のインスタンスに任せる場合もあります。

3. Directory Server は、その検索に対応する 1 つ以上のインデックスを管理しているかどうかを判定します。

   • Directory Server がその検索に対応するインデックスを管理している場合、サーバーは、対応するすべてのインデックスを検索して候補エントリを見つけます。候補エントリとは、検索要求に一致する可能性のあるエントリです。

   • Directory Server がその検索に対応するインデックスを管理していない場合、サーバーは、データベース内のすべてのエントリをチェックすることによって候補エントリのセットを生成します。

     Directory Server がインデックスを使用できない場合は、この処理で消費される時間とシステムリソースが増えます。

4. Directory Server は各候補エントリを検査して、そのエントリが検索条件に一致するかどうかを判定します。

5. Directory Server は、一致するエントリを見つけると、そのエントリをクライアントアプリケーションに返します。

次のことを行うことによって、検索のパフォーマンスを最適化できます。

• インデックスが生成されていないエントリに対して Directory Server が検索を実行しないようにします。

• キャッシュサイズが適切に調整されていることを確認します。

• インデックスの長さを制限します。

インデックスの動作の包括的な概要については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 6 章「Directory Server Indexing」を参照してください。インデックスの定義については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の第 12 章「Directory Server のインデックス」を参照してください。

検索のパフォーマンス向上のためのキャッシュの最適化

検索のパフォーマンスを向上させるには、メモリー内にできるだけ多くのディレクトリデータをキャッシュします。ディレクトリサーバーがディスクから情報を読み取る回数を減らすことで、ディスクの I/O ボトルネックが軽減されます。これを実行するための方法は、ディレクトリツリーのサイズ、使用可能なメモリーの量、および使用されているハードウェアによって異なります。配備によっては、検索のパフォーマンスを最適化するために、エントリキャッシュやデータベースキャッシュに割り当てるメモリーを増やしたり減らしたりすることを選択する場合があります。あるいは、異なるサーバー上の Directory Server コンシューマに検索を分散させることを選択する場合もあります。

次のシナリオを検討してみます。

• 「すべてのエントリとインデックスがメモリーに収まる」

• 「32 ビット Directory Server のための十分なメモリーがある」

• 「メモリー不足」

すべてのエントリとインデックスがメモリーに収まる

最適な場合は、データベースキャッシュとエントリキャッシュが使用可能な物理メモリーに収まります。エントリキャッシュは、ディレクトリ内のすべてのエントリを保持するための十分な大きさがあります。データベースキャッシュは、すべてのインデックスとエントリを保持するための十分な大きさがあります。この場合、検索対象はすべてキャッシュ内で見つかります。Directory Server は、エントリを取得するために、ファイルシステムキャッシュまたはディスクにアクセスする必要がまったくありません。

更新や拡張のあとも、データベースキャッシュにすべてのデータベースインデックスが含まれている必要があります。データベースキャッシュ内のインデックスの領域が不足すると、検索を行うたびに、Directory Server がディスクからインデックスを読み取らなければならなくなり、スループットが大幅に低下します。ページングやキャッシュのアクティビティーは、DSCC またはコマンド行を使用して監視できます。

適切なキャッシュサイズは、代表的なデータでの実験的なテストを通して決定してください。一般に、データベースキャッシュサイズは、(データベースファイルの合計サイズ) x 1.2 として計算できます。最初は、キャッシュに大量のメモリーを割り当ててください。次に、Directory Server を実行して監視し、その結果を観察します。この処理を、必要に応じて繰り返します。エントリキャッシュは特に、これらのキャッシュに割り当てた分よりはるかに多くのメモリーを使用する可能性があります。

32 ビット Directory Server のための十分なメモリーがある

エントリキャッシュとデータベースキャッシュ内のすべてのデータを保持するための十分なメモリーを備えているが、64 ビット Directory Server プロセスをサポートしていないシステムを考えてみます。ハードウェアの制約によって、64 ビットをサポートする Solaris システム上に Directory Server を配備できない場合は、32 ビットプロセスのメモリー制限を考慮してキャッシュサイズを適切に決定してください。次に、残りのメモリーをファイルシステムキャッシュに割り当てます。

パフォーマンスベンチマークの出発点として、エントリキャッシュのサイズを、できるだけ多数のエントリを保持するように決定します。データベースキャッシュのサイズは、完全に最小化せずに 100M バイト程度に比較的小さくしますが、ファイルシステムキャッシュにはデータベースページが保持されるようにします。

ファイルシステムキャッシュは、システム上のほかのプロセス、特にファイルベースの操作と共有されます。そのため、特に Directory Server 専用のシステムでない場合、ファイルシステムキャッシュの制御はほかのキャッシュの制御より困難です。

システムがファイルシステムキャッシュをほかのプロセスに再割り当てする可能性があります。

インポートキャッシュは Directory Server プロセスに関連付けられているため、この状況でのオンラインインポートは避けてください。

メモリー不足

エントリキャッシュとデータベースキャッシュ内のすべてのデータを保持するにはメモリーが不足しているシステムを考えてみます。この場合は、エントリキャッシュとデータベースキャッシュの合計サイズが使用可能な物理メモリーを超えることのないようにしてください。もし超えてしまうと、仮想記憶のページングが大量に発生し、システムが事実上停止してしまう可能性があります。

小規模なシステムのベンチマークでは、最初、使用可能なメモリーをすべてエントリキャッシュとデータベースキャッシュに割り当てください (サイズはそれぞれ 100M バイト以上)。mount_ufs コマンドの -o forcedirectio オプションを使用して Solaris UFS ファイルシステムをマウントすることによって、ファイルシステムキャッシュの無効化を試みてください。詳細については、mount_ufs(1M) のマニュアルページを参照してください。ファイルシステムキャッシュを無効にすると、Directory Server に必要なメモリーがファイルシステムキャッシュでは使用されないようにすることができます。

大規模なマシン上で実行されている大規模な Directory Server では、ファイルシステムキャッシュを最大化し、データベースキャッシュを減らします。実験的なテストを通してこの前提を確認し、修正してください。

書き込みのパフォーマンス向上のためのキャッシュの最適化

配備に書き込みのスケーラビリティーを持たせるように最初から計画することに加えて、データベースキャッシュがメモリー内の更新を処理できるだけの十分なメモリーを用意してください。また、ディスクアクティビティーも最小限に抑えてください。データベースキャッシュの有効性は、Directory Service Control Center でヒット率を読み取ることによって監視できます。

Directory Server がしばらく実行されたあとは、キャッシュ内に、それ以上ディスク読み取りが必要ないほど十分なエントリとインデックスが含まれているようにしてください。更新の結果は、メモリー内の大規模なデータベースキャッシュにあるデータに反映され、データベースキャッシュはたまにしかフラッシュされないはずです。

チェックポイント中のディスクへのデータのフラッシュは、ボトルネックになる場合があります。データベースキャッシュサイズが大きければ大きいほど、このボトルネックは大きくなります。Sun StorEdge^TM ディスクアレイなどの別の RAID システムにデータベースを格納すると、更新のパフォーマンス向上に役立つ場合があります。潜在的な I/O ボトルネックを分離するには、Solaris システムにおける iostat などのユーティリティーを使用できます。詳細については、iostat(1M) のマニュアルページを参照してください。

次の表は、2、3、および 4 つのディスクを備えたシステムでのデータベースとログの配置方法に関する推奨事項を示しています。