基本的な推奨事項を次に示します。これらの推奨事項はほとんどの状況で適用可能です。ここに示した推奨事項は基本的に有効ですが、実際の配備への影響を理解することなしにこれらの推奨事項を適用することは避けてください。この節の目的はチェックリストを提供することであり、模範解答を提供することではありません。
キャッシュサイズを調整します。
理想的なサーバーでは、利用可能な物理メモリーが十分に存在しており、Directory Server が使用するすべてのキャッシュを保持できます。さらに、ある適切な量の追加物理メモリーが、将来の規模増大を考慮して利用可能になっています。十分な物理メモリーが利用可能な場合には、エントリキャッシュサイズを十分に大きな値に設定し、ディレクトリ内のすべてのエントリを保持できるようにします。entry-cache-size サフィックスプロパティーを使用します。db-cache-size プロパティー経由でデータベースキャッシュサイズを十分に大きな値に設定し、すべてのインデックスを保持できるようにします。dn-cache-size または dn-cache-count プロパティーを使用し、DN キャッシュのサイズを制御します。
インデックス作成を最適化します。
不要なインデックスを削除します。予期される要求をサポートするための追加インデックスを追加します。
新しいアプリケーションからの要求をサポートする追加インデックスを追加することもあります。インデックスの追加、削除、または変更は、Directory Server の稼働中に行えます。たとえば、dsconf create-index や dsconf delete-index などのコマンドを使用します。
システムインデックスを削除しないように注意してください。システムインデックスの一覧については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の「System Indexes and Default Indexes」を参照してください。
ユーザーがインデックスに変更を加えると、Directory Server は徐々にデータのインデックスを作成します。dsconf reindex コマンドを使って Directory Server に強制的にインデックスを再生成させることもできます。
インデックスを使用する検索のみを許可します。
インデックスを使用しない検索は、サーバーのパフォーマンスに多大な悪影響を及ぼす可能性があります。インデックスを使用しない検索は、多くのサーバーリソースを消費する可能性もあります。
require-index-enabled サフィックスプロパティーを on に設定することで、インデックスを使用しない検索を拒否するようサーバーに強制することを検討してください。
all-ids-threshold プロパティーを使って、1 インデックスキーあたりの値の最大数を調整します。
idsktune コマンドからの推奨内容に従って、サーバーを稼働しているマシンのオペレーティングシステムをチューニングします。詳細については、idsktune(1M) のマニュアルページを参照してください。
操作制限を調整します。
操作制限を調整することで、Directory Server がある単一の操作に過度のリソースを割り当ててしまうのを防ぐことができます。大きな容量を要求するクライアントアプリケーションに一意のバインド DN を割り当て、それらの一意のバインド DN に対して具体的なリソース制限を設けることを検討してください。
ディスクのアクティビティーを分散します。
大量の更新をサポートする配備では特に、Directory Server はきわめてディスク入出力集中型になる可能性があります。可能であれば、独立したコントローラを使ってこの負荷を複数のディスクに分散することを検討してください。
不要なロギングを無効にします。
ディスクアクセスはメモリーアクセスよりも低速です。したがって、過度のロギングはパフォーマンスに悪影響を及ぼします。読み取り専用のサーバーインスタンス上など、監査ロギングが必要ない場合にそのロギングをオフにしておくことで、ディスクの負荷を減らします。エラーログを使って問題のトラブルシューティングを行わないときには、エラーロギングを最小レベルにしておきます。また、ログファイルを専用のディスク上や、レプリケーション変更ログ用のディスクなど、使用頻度の少ないディスク上に配置することによっても、ロギングの影響を減らせます。
多数の更新をレプリケートする場合には、適切なレプリケーションアグリーメントプロパティーを調整することを検討してください。
プロパティーは transport-compression、transport-group-size、および transport-window-size です。
Solaris システム上では、データベースホームディレクトリを tmpfs ファイルシステムに移動します。
db-env-path プロパティーで指定されるデータベースホームディレクトリは、Directory Server がデータベースキャッシュバッキングファイルを格納する場所を示します。データファイルはデフォルトでは、instance-path/db 内に存在し続けます。
データベースキャッシュバッキングファイルを tmpfs ファイルシステム上に格納すれば、システムがデータベースキャッシュバッキングファイルをディスクに繰り返しフラッシュしなくなります。したがって、更新時のパフォーマンス障害の発生を回避できます。場合によっては、検索時のパフォーマンス障害の発生も回避できます。データベースのキャッシュメモリーは Directory Server のプロセス空間にマップされます。システムは基本的に、tmpfs ファイルシステム内のキャッシュメモリーとバッキングファイルの保持に使用されるメモリーを共有します。したがって、必要メモリー容量の点で基本的に何のコストも払うことなしに、パフォーマンスの向上を図れます。
この最適化に関連する主なコストは、ホストマシンの再起動後にデータベースキャッシュを再構築する必要がある、という点です。ソフトウェアまたはハードウェアでの障害発生時にのみ再起動が発生することが予期される場合、このコストはおそらく避けて通ることはできません。そのような障害が発生すれば、いずれにしてもデータベースキャッシュを再構築する必要があります。
ソフトウェアまたはハードウェアでの障害発生時に更新が失われてもかまわない場合には、トランザクションバッチを有効にします。
トランザクションバッチを有効にするには、サーバープロパティー db-batched-transaction-count を設定します。
トランザクションログが更新されるたびに、更新データが失われないように同期処理が続いて実行されます。トランザクションバッチを有効にすると、いくつかの更新が一緒にまとめられてから、トランザクションログに書き込まれます。同期処理が実行されるのは、バッチの全体がトランザクションログに書き込まれるときだけです。したがって、トランザクションバッチを使えば、更新時のパフォーマンスを大幅に改善できます。この改善にはトレードオフがあります。そのトレードオフとは、クラッシュした時点でトランザクションログにまだ書き込まれていない更新データは失われてしまう、ということです。
トランザクションバッチを有効にすると、ソフトウェアまたはハードウェアでの障害発生時に最大 db-batched-transaction-count - 1 件の更新が失われます。この損失が発生するのは、Directory Server が、バッチが満たされるまでの間か 1 秒間、どちらか短いほうだけ待機したあとで、内容をトランザクションログに、したがってディスクに、フラッシュするからです。
更新が失われると困る場合には、この最適化を使用「しない」でください。
参照の完全性プラグインを設定して完全性チェックを遅延させます。
参照の完全性プラグインは、エントリが変更されたりディレクトリから削除された場合に、それらのエントリへのすべての参照が間違いなく更新されるようにします。この処理はデフォルトでは、削除操作に対する応答がクライアントに返される前に、同期的に実行されます。この更新が非同期で実行されるようにプラグインを設定できます。ref-integrity-check-delay サーバープロパティーを使用します。