Directory Server のハードウェアサイジング

中規模から大規模の Directory Server 配備に適したハードウェアを決定するには、本番時に提供することが予期されるデータに類似したデータと、予期されるクライアントアプリケーションからのアクセスパターンに類似したアクセスパターンに基づいて、何らかのテストを行う必要があります。特定のシステム用に最適化する場合には、システムバス、周辺バス、入出力デバイス、およびサポートされているファイルシステムがどのように動作するのかを、必ず理解しておく必要があります。この知識があれば、Directory Server をサポートするように入出力サブシステムの機能をチューニングする際に、それらの機能を活用しやすくなります。Sun サービスは、要件に合ったハードウェアサイジングなど、正しい配備決定を行う際に役立つ可能性があります。

この節では、Directory Server のハードウェアサイジングへのアプローチ方法を説明します。ここでは、配備内の Directory Server 専用として使用するプロセッサの個数、メモリーの容量、ディスクの容量、およびネットワーク接続の種類を決定する際の考慮点を示します。

この節の内容は、次のとおりです。

• 「チューニングプロセス」

• 「サンプルディレクトリデータの作成」

• 「設定すべき項目とその理由」

• 「クライアントアプリケーション負荷のシミュレーション」

• 「Directory Server とプロセッサ」

• 「Directory Server とメモリー」

• 「Directory Server とローカルディスク容量」

• 「Directory Server とネットワーク接続」

• 「クライアントが使用可能な Directory Server リソースの制限」

• 「Directory Server が使用するシステムリソースの制限」

• 「Directory Server の基本的なサイジングの例: ディスクとメモリーの要件」

特に明記されていないかぎり、次の各節で説明されている「サーバープロパティー」は dsconf コマンドで設定できます。dsconf の使用方法の詳細については、dsconf(1M) のマニュアルページを参照してください。

チューニングプロセス

パフォーマンスのチューニングは、デフォルト設定を変更して特定の配備要件が反映されるようにすることを意味します。次のプロセスフェーズのリストには、Directory Server のチューニング時に考慮すべき主要項目が記載されています。

目標の定義

配備要件に基づいて、特定の測定可能なチューニング目標を定義します。

次の各質問を検討してください。

• どのアプリケーションが Directory Server を使用しますか。

• システムの全体を Directory Server の専用にすることができますか。

  システム上でほかのアプリケーションも実行されますか。

  そうであれば、システム上で実行されるほかのアプリケーションはどれですか。

• この配備によって何件の「エントリ」が処理されますか。

  エントリ件数はどのくらいになりますか。

• Directory Server は 1 秒あたり何件の「検索」をサポートする必要がありますか。

  どのようなタイプが検索されるか

• Directory Server は 1 秒あたり何件の「更新」をサポートする必要がありますか。

  どのようなタイプが更新されるか

• どのような種類のピークの更新頻度および検索頻度が予期されますか。

  平均の更新頻度はどれくらいになると予期されますか。

• 配備がこのシステム上で一括インポートによる初期化を繰り返し必要としますか。

  そうであれば、データのインポート頻度はどのくらいであると予期されますか。何件のエントリがインポートされますか。

  エントリの種類はわかりますか。

  サーバーが稼働したままの状態で、オンラインで初期化を実行する必要があるか

このリストはすべての要素を網羅しているわけではありません。自身の目標リストがすべての要素を網羅していることを確認してください。

方法の選択

最適化をどのように実施する予定であるかを決定します。また、最適化結果をどのように測定および解析する予定であるかも決定します。

次の各質問を検討してください。

• システムのハードウェア構成を変更できるか。

• すでに存在しているハードウェアを使用したり、サーバーが稼働しているオペレーティングシステムや Directory Server のみをチューニングしたりすること以外に方法がないか。

• ほかのアプリケーションをどのような方法でシミュレートできるか。

• テスト用の典型的なデータサンプルをどのような方法で生成すべきか。

• 結果をどのような方法で測定すべきか。

• 結果をどのような方法で解析すべきか。

テストの実行

計画したテストを実行します。配備が大規模で複雑な場合、このフェーズでかなりの時間がかかる可能性があります。

結果の確認

テストした潜在的な最適化によって、プロセス開始時に定義した目標が達成されたかどうかをチェックします。

最適化によって目標が達成された場合には、その結果を文書化します。

最適化によって目標が達成されなかった場合には、Directory Server のプロファイリングと監視を行います。

プロファイリングおよび監視

潜在的な変更を適用したあとで、Directory Server の動作のプロファイリングと監視を行います。

関係するすべての動作の測定値を収集します。

グラフ化と解析

プロファイリング中や監視中に監視した動作をグラフ化および解析します。証拠を見つけたり、さらなるテストを示唆するパターンを発見したりする努力を行なってください。

「プロファイリングおよび監視」フェーズに戻って別のデータを収集する必要がある可能性もあります。

調整およびチューニング

測定値の解析結果が示唆する、さらなる潜在的な最適化を適用します。

「テストの実行」フェーズに戻ります。

結果の文書化

適用した最適化によってプロセス開始時に定義した目標が達成された場合には、その最適化を適切に文書化し、あとでその最適化を容易に再現できるようにします。

サンプルディレクトリデータの作成

Directory Server に割り当てるディスクやメモリーの容量は、ディレクトリデータに依存します。サンプルデータが LDIF 形式ですでに存在している場合には、配備のハードウェアをサイジングする際にそのデータを使用します。ここで、サンプルデータとは、配備時に使用することが予期されるデータに対応するサンプルデータを意味しており、「配備時の実際のデータ」を意味しているのではありません。実際のデータは、現実的なプライバシーに関する配慮を必要とし、サンプルデータの生成に必要となる仕様に比べて桁違いに大きくなる可能性があるため、テスト対象のすべてのケースを実施することが難しくなる可能性があります。サンプルデータに含まれるエントリの平均サイズは、配備時に予期されるサイズに近く、その属性は、配備時に予期される値に似た値を持ち、その数は、配備時に予期される比率に似た比率で存在しています。

サンプルデータに基づいて何らかの決定を下す際には、予期される増加分を考慮に入れるようにしてください。容量計画時には、現在のデータのオーバーヘッド分を含めることをお勧めします。

サンプルデータをまだ用意していない場合には、makeldif(1) コマンドを使ってサンプル LDIF を生成し、それを Directory Server にインポートします。第 4 章「データ特性の定義」は、配備用のサンプルデータを決定する際に役立つ可能性があります。makeldif コマンドは Directory Server Resource Kit ツールの 1 つです。

本番時に数百万件のエントリを提供することが予期される配備では、数百万件のエントリをテスト用に読み込むのが理想的です。ただし、数百万件のエントリを読み込むことは、最初の評価目的としては現実的でない可能性もあります。まず、10,000 件のエントリ、100,000 件のエントリ、1,000,000 件のエントリなど、サンプルデータのセットをいくつか作成し、それらをインポートし、その監視結果に基づいて推定することで、さらなるテストに必要となるハードウェアを見積もります。ハードウェア要件を見積もる際には、複数のサーバーにレプリケートされるデータを準備してください。

LDIF から Directory Server 内にディレクトリデータをインポートすると、その結果として得られるデータベースファイル (インデックスを含む) は、LDIF 表現よりも大きくなります。データベースファイルはデフォルトで、instance-path/db/ ディレクトリ内に格納されます。

設定すべき項目とその理由

Directory Server のデフォルト設定は典型的な小規模配備向けに定義されたものであり、その目的は、この製品を容易にインストールおよび評価できるようにすることです。この節では、中規模から大規模の配備で調整すべきいくつかの主要設定について調査します。中規模から大規模の配備では、設定をユーザーの特定の配備に適応させることでパフォーマンスを大幅に改善できることがよくあります。

Directory Server のデータベースページサイズ

Directory Server は、データの読み書きを行う際に、ページと呼ばれる固定長のデータブロックを操作します。ページサイズを増やすことにより、1 つのディスク操作で読み書きされるブロックのサイズを増やせます。

ページサイズはエントリのサイズと関係しており、パフォーマンスを考えるうえで不可欠の要素です。エントリの平均サイズが db-page-size/4–24 (24 はページごとのバイナリツリー内部構造) より大きいことがわかっている場合は、データベースページサイズを増やす必要があります。さらに、データベースのページサイズはファイルシステムのディスクブロックサイズと一致すべきです。

Directory Server のキャッシュサイズ

Directory Server は、クライアントアプリケーションの要求にすばやく応答するように設計されています。Directory Server は、ディスクからディレクトリデータが読み取られるまで待たずにすむように、メモリー内にデータを書き込みます。データベースファイル用、ディレクトリエントリ用、および LDIF からのディレクトリデータのインポート用のキャッシュとして、どれだけのメモリーを割り当てるかを設定できます。

すべてのディレクトリデータをキャッシュするのに十分な容量の物理メモリーを割り当てることのできるハードウェア上で Directory Server を実行するのが理想的です。データが無理なく収まるようにすることで、システムがその正常動作に必要な物理メモリーを確保でき、かつファイルシステムも自身のキャッシュ処理や正常動作に必要な物理メモリーを確保できるようにすべきです。いったんデータがキャッシュに書き込まれると、ディレクトリエントリが変更されないかぎり、Directory Server はディスクに対してデータの読み書きを行う必要がなくなります。

Directory Server は、64 ビットメモリーアドレス指定をサポートしているため、64 ビットプロセッサがアドレス指定可能なサイズであれば、どのように大きな合計キャッシュサイズでも処理できます。小規模から中規模の配備では、すべてのディレクトリデータをキャッシュ内に保持できるだけのメモリーを確保できることがよくあります。これに対し、大規模配備では、すべてをキャッシュに保持することは、現実的でないか、あるいは費用効果的に問題がある可能性があります。

大規模配備では、すべてをメモリーに保持すると、副作用が生じる可能性があります。プロセスのメモリーマップをトラバースしてデータを収集する、pmap コマンドなどのツールを実行すると、ユーザーが気づく程度の期間、サーバープロセスが動かなくなる可能性があります。コアファイルが非常に大きくなるため、クラッシュ時にそれらをディスクに書き込むのに数分かかる可能性があります。サーバーが突然停止されたあと再起動された場合、起動時間が長くなる可能性があります。さらに、Directory Server がチェックポイントに到達し、ダーティーキャッシュページをディスクにフラッシュしなければならない場合には、サーバーが一時的に停止し、応答しなくなる可能性もあります。キャッシュが非常に大きい場合はこの一時停止も非常に長くなり、Directory Server が停止しているものと監視ソフトウェアによって判断される可能性があります。

オペレーティングシステムレベルの入出力バッファーを使えば、パフォーマンスが向上する可能性があります。非常に大きなバッファーは、比較的小さなデータベースキャッシュの悪影響を打ち消すことができます。

キャッシュやキャッシュ設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 5 章「Directory Server Data Caching」を参照してください。キャッシュサイズの調整方法については、「The Basics of Directory Server Cache Sizing 」を参照してください。

Directory Server のインデックス

Directory Server は、ディレクトリエントリの属性値に対するインデックスを作成することで、それらの属性の検索を高速化します。属性は、さまざまな方法でインデックスが作成されるように設定できます。たとえば、インデックスを使えば、ある属性が値を持っているか、特定の値に等しい値を持っているか、あるいは特定の部分文字列を含む値を持っているかを、Directory Server がよりすばやく決定できるようになります。

インデックスを使えば、検索時のパフォーマンスが向上する可能性がありますが、書き込み時のパフォーマンスに悪影響が及ぶ可能性もあります。ある属性のインデックスが作成されると、Directory Server はその属性の値が変更されるたびにインデックスを更新しなければいけません。

Directory Server はインデックスデータをファイルに保存します。設定するインデックスが多いほど、必要なディスク容量も多くなります。Directory Server のインデックスとデータファイルはデフォルトで、instance-path/db/ ディレクトリ内に格納されます。

インデックス作成やインデックス設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 6 章「Directory Server Indexing」を参照してください。

Directory Server の管理ファイル

Directory Server のいくつかの管理ファイルは、サイズが非常に大きくなる可能性があります。そうしたファイルとしては、ディレクトリデータを含む LDIF ファイル、バックアップ、コアファイル、ログファイルなどが挙げられます。

配備によっては、Directory Server データのインポート、補助バックアップの両方の用途で LDIF を使用することができます。標準テキスト形式の LDIF を使えば、バイナリデータだけでなく文字列もエクスポートできます。大規模配備の場合、LDIF は大量のディスク容量を占有する可能性があります。たとえば、平均サイズが 2K バイトのエントリを 1 千万件含んでいるディレクトリは、LDIF 表現ではディスク上で 20G バイトを占有します。この LDIF 形式を補助バックアップとして使用する場合、このサイズの LDIF ファイルが複数個維持される可能性があります。

バイナリのバックアップファイルも、少なくとも安全を確保するためにどこかほかの場所に移動されるまでは、ディスクの容量を占有します。Directory Server ユーティリティーによって生成されるバックアップファイルは、ディレクトリデータベースファイルのバイナリコピーから構成されます。大規模配備の場合は別の方法として、Directory Server を凍結モードにしたあと、ファイルシステムのスナップショットを取ることもできます。いずれにしても、バックアップに利用可能なディスク容量が存在している必要があります。

Directory Server はデフォルトで、ログメッセージを instance-path/logs/access と instance-path/logs/errors に書き込みます。Directory Server はデフォルトで、access ログ用として 1G バイトのローカルディスク容量を必要とし、errors ログ用としてさらに 200M バイトのローカルディスク容量を必要とします。

Directory Server のロギングの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 7 章「Directory Server Logging」を参照してください。

Directory Server のレプリケーション

Directory Server では、ディレクトリデータをレプリケートすることで、配備内のサーバーの可用性を高め、サーバー間の負荷分散を行えるようになっています。Directory Server では、複数の読み書き (マスター) レプリカを一緒に配備できます。

サーバーはこれを可能にするために、内部的にディレクトリデータへの変更を追跡します。同じデータが複数の読み書きレプリカ上で変更されても、Directory Server はその変更をすべてのレプリカ上で解決できます。これらの変更を追跡するためのデータは、レプリケーション時に必要とされなくなるまで、保持しておく必要があります。変更は、「パージ遅延」によって指定された期間だけ保持されます。デフォルト値は 7 日間です。ディレクトリデータに多数の変更が加えられると、このデータは非常に大きくなる可能性があります。大きな複数値属性に変更が加えられる場合は特にそうです。

データの増大するレベルはさまざまな要素によって決まるので、データの増大量を求めるための決定的な公式はありません。最善のアプローチ方法は、通常の変更をテストして増大量を測定してみることです。エントリの変更によるデータの増大に影響する要素には、次のようなものがあります。

• 変更対象のエントリのタイプと属性のタイプ。

  複数値属性だとデータの増大量が大きくなります。属性値が小さい場合は、増大量が見えやすくなります。

• エントリに適用される作業負荷。

  エントリの追加や削除を行うと、データの増大量が大きくなります。属性値を追加すると、属性値を置き換えた場合よりもデータの増大量が大きくなります。

• 変更対象のエントリ数と、各エントリ内の変更対象の属性の数。

• データベースページのサイズ。

  非常に多くの変更を行なった場合、特定のエントリがデータベースページサイズよりも大きくなる可能性があります。

パージ遅延の期間が過ぎて、エントリがもう一度変更されるまで、レプリケーションのメタデータはエントリ内に保持されたままになっています。

Directory Server のレプリケーションの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」を参照してください。

Directory Server のスレッドとファイル記述子

Directory Server はマルチスレッドプロセスとして実行され、マルチプロセッサシステム上では高いスケーラビリティーを実現できるように設計されています。Directory Server が起動時に作成する処理用スレッドの数を設定することができます。Directory Server はデフォルトで 30 個のスレッドを作成します。この値を設定するには、dsconf(1M) コマンドを使ってサーバープロパティー thread-count を調整します。

大切なのは、多数のスレッドを処理する必要性による undo 処理のオーバーヘッドを発生させることなく、スレッドをできるだけビジー状態に保つことです。すべてのディレクトリデータがキャッシュ内に収まっているかぎり、プロセッサ数の 2 倍に予期される同時更新処理数を加えた値を thread-count に設定すると、しばしば良好なパフォーマンスが得られます。大きなディレクトリデータセットの一部しかキャッシュ内に収まらない場合には、データがディスクから読み取られるのを Directory Server のスレッドが待たなければいけない状況がしばしば発生します。そうした場合には、利用可能なプロセッサ数の最大 16 倍という、格段に大きなスレッド数を使用すれば、パフォーマンスを改善できる可能性があります。

Directory Server はファイル記述子を使って、開いているクライアントアプリケーション接続に関係するデータを保持します。Directory Server はデフォルトで、最大 1024 個のファイル記述子を使用します。この値を設定するには、dsconf コマンドを使ってサーバープロパティー file-descriptor-count を調整します。too many fds open というメッセージが errors ログに含まれている場合には、file-descriptor-count を増やすことでパフォーマンスが向上する可能性があります。ただし、Directory Server が追加のファイル記述子を開くことをシステムが許可するものと仮定しています。

file-descriptor-count プロパティーは、Windows には適用されません。

Directory Server の規模の増大

Directory Server がいったん配備されると、その使用量はおそらく増加していきます。規模増大への備えが、配備を成功させ、一貫して高レベルのサービスを提供し続けるための鍵となります。将来的に予期される規模の増大も考慮に入れた要件定義を行い、現時点で必要なシステムよりも大規模で強力なシステムを計画してください。

ディレクトリサービスは、急激にあるいは突然に規模を増大させる必要に迫られる場合があります。たとえば、ある組織用にサイジングされたディレクトリサービスが別の組織のディレクトリサービスとマージされる場合などが、そのケースに該当します。規模増大への備えを前もって行い、予期される内容を明示的に特定することによって、急激な規模増大や突然の規模増大により適切に対処できるようになります。なぜなら、予期された増大が計画された容量を超えるかどうかを前もって知ることができるからです。

最重要のチューニングヒント

基本的な推奨事項を次に示します。これらの推奨事項はほとんどの状況で適用可能です。ここに示した推奨事項は基本的に有効ですが、実際の配備への影響を理解することなしにこれらの推奨事項を適用することは避けてください。この節の目的はチェックリストを提供することであり、模範解答を提供することではありません。

1. キャッシュサイズを調整します。

   理想的なサーバーでは、利用可能な物理メモリーが十分に存在しており、Directory Server が使用するすべてのキャッシュを保持できます。さらに、ある適切な量の追加物理メモリーが、将来の規模増大を考慮して利用可能になっています。十分な物理メモリーが利用可能な場合には、エントリキャッシュサイズを十分に大きな値に設定し、ディレクトリ内のすべてのエントリを保持できるようにします。entry-cache-size サフィックスプロパティーを使用します。db-cache-size プロパティー経由でデータベースキャッシュサイズを十分に大きな値に設定し、すべてのインデックスを保持できるようにします。dn-cache-size または dn-cache-count プロパティーを使用し、DN キャッシュのサイズを制御します。

2. インデックス作成を最適化します。

   1. 不要なインデックスを削除します。予期される要求をサポートするための追加インデックスを追加します。

      新しいアプリケーションからの要求をサポートする追加インデックスを追加することもあります。インデックスの追加、削除、または変更は、Directory Server の稼働中に行えます。たとえば、dsconf create-index や dsconf delete-index などのコマンドを使用します。

      システムインデックスを削除しないように注意してください。システムインデックスの一覧については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「System Indexes and Default Indexes」を参照してください。

      ユーザーがインデックスに変更を加えると、Directory Server は徐々にデータのインデックスを作成します。dsconf reindex コマンドを使って Directory Server に強制的にインデックスを再生成させることもできます。

   2. インデックスを使用する検索のみを許可します。

      インデックスを使用しない検索は、サーバーのパフォーマンスに多大な悪影響を及ぼす可能性があります。インデックスを使用しない検索は、多くのサーバーリソースを消費する可能性もあります。

      require-index-enabled サフィックスプロパティーを on に設定することで、インデックスを使用しない検索を拒否するようサーバーに強制することを検討してください。

   3. all-ids-threshold プロパティーを使って、1 インデックスキーあたりの値の最大数を調整します。

3. idsktune コマンドからの推奨内容に従って、サーバーを稼働しているマシンのオペレーティングシステムをチューニングします。詳細については、idsktune(1M) のマニュアルページを参照してください。

4. 操作制限を調整します。

   操作制限を調整することで、Directory Server がある単一の操作に過度のリソースを割り当ててしまうのを防ぐことができます。大きな容量を要求するクライアントアプリケーションに一意のバインド DN を割り当て、それらの一意のバインド DN に対して具体的なリソース制限を設けることを検討してください。

5. ディスクのアクティビティーを分散します。

   大量の更新をサポートする配備では特に、Directory Server はきわめてディスク入出力集中型になる可能性があります。可能であれば、独立したコントローラを使ってこの負荷を複数のディスクに分散することを検討してください。

6. 不要なロギングを無効にします。

   ディスクアクセスはメモリーアクセスよりも低速です。したがって、過度のロギングはパフォーマンスに悪影響を及ぼします。読み取り専用のサーバーインスタンス上など、監査ロギングが必要ない場合にそのロギングをオフにしておくことで、ディスクの負荷を減らします。エラーログを使って問題のトラブルシューティングを行わないときには、エラーロギングを最小レベルにしておきます。また、ログファイルを専用のディスク上や、レプリケーション変更ログ用のディスクなど、使用頻度の少ないディスク上に配置することによっても、ロギングの影響を減らせます。

7. 多数の更新をレプリケートする場合には、適切なレプリケーションアグリーメントプロパティーを調整することを検討してください。

   プロパティーは transport-compression、transport-group-size、および transport-window-size です。

8. Solaris システム上では、データベースホームディレクトリを tmpfs ファイルシステムに移動します。

   db-env-path プロパティーで指定されるデータベースホームディレクトリは、Directory Server がデータベースキャッシュバッキングファイルを格納する場所を示します。データファイルはデフォルトでは、instance-path/db 内に存在し続けます。

   データベースキャッシュバッキングファイルを tmpfs ファイルシステム上に格納すれば、システムがデータベースキャッシュバッキングファイルをディスクに繰り返しフラッシュしなくなります。したがって、更新時のパフォーマンス障害の発生を回避できます。場合によっては、検索時のパフォーマンス障害の発生も回避できます。データベースのキャッシュメモリーは Directory Server のプロセス空間にマップされます。システムは基本的に、tmpfs ファイルシステム内のキャッシュメモリーとバッキングファイルの保持に使用されるメモリーを共有します。したがって、必要メモリー容量の点で基本的に何のコストも払うことなしに、パフォーマンスの向上を図れます。

   この最適化に関連する主なコストは、ホストマシンの再起動後にデータベースキャッシュを再構築する必要がある、という点です。ソフトウェアまたはハードウェアでの障害発生時にのみ再起動が発生することが予期される場合、このコストはおそらく避けて通ることはできません。そのような障害が発生すれば、いずれにしてもデータベースキャッシュを再構築する必要があります。

9. ソフトウェアまたはハードウェアでの障害発生時に更新が失われてもかまわない場合には、トランザクションバッチを有効にします。

   トランザクションバッチを有効にするには、サーバープロパティー db-batched-transaction-count を設定します。

   トランザクションログが更新されるたびに、更新データが失われないように同期処理が続いて実行されます。トランザクションバッチを有効にすると、いくつかの更新が一緒にまとめられてから、トランザクションログに書き込まれます。同期処理が実行されるのは、バッチの全体がトランザクションログに書き込まれるときだけです。したがって、トランザクションバッチを使えば、更新時のパフォーマンスを大幅に改善できます。この改善にはトレードオフがあります。そのトレードオフとは、クラッシュした時点でトランザクションログにまだ書き込まれていない更新データは失われてしまう、ということです。

   ---

   注 –

   トランザクションバッチを有効にすると、ソフトウェアまたはハードウェアでの障害発生時に最大 db-batched-transaction-count - 1 件の更新が失われます。この損失が発生するのは、Directory Server が、バッチが満たされるまでの間か 1 秒間、どちらか短いほうだけ待機したあとで、内容をトランザクションログに、したがってディスクに、フラッシュするからです。

   更新が失われると困る場合には、この最適化を使用「しない」でください。

   ---

10. 参照の完全性プラグインを設定して完全性チェックを遅延させます。

    参照の完全性プラグインは、エントリが変更されたりディレクトリから削除された場合に、それらのエントリへのすべての参照が間違いなく更新されるようにします。この処理はデフォルトでは、削除操作に対する応答がクライアントに返される前に、同期的に実行されます。この更新が非同期で実行されるようにプラグインを設定できます。ref-integrity-check-delay サーバープロパティーを使用します。

クライアントアプリケーション負荷のシミュレーション

Directory Server のパフォーマンスを測定するには、サーバーを準備したあと、本番時に予期されるタイプのクライアントアプリケーショントラフィックをそのサーバーに対して与えます。本番時に発生するクライアントアプリケーションのアクセスパターンタイプの再現性が高まるほど、ハードウェアのサイジングと Directory Server の設定の精度も高くなります。

Directory Server Resource Kit には、基本的なテストを行う際に使用可能な authrate(1)、modrate(1)、および searchrate(1) コマンドが含まれています。これらのコマンドを使えば、使用するディレクトリサービスがサポート可能なバインド頻度、変更頻度、および検索頻度を測定できます。

SLAMD を使って複雑で現実的なクライアントアクセスのシミュレーション、測定、およびグラフ化を行うこともできます。SLAMD 分散負荷生成エンジン (SLAMD) は、ネットワークベースのアプリケーションの負荷テストを行なったりそのパフォーマンスを解析したりするために設計された、Java アプリケーションです。これは当初、LDAP Directory Server のベンチマーク測定およびパフォーマンス解析用として、Sun Microsystems, Inc. によって開発されました。SLAMD は、OSI が承認したオープンソースライセンスである Sun Public License のもとでオープンソースアプリケーションとして公開されています。SLAMD についての情報を入手するには、http://www.slamd.com/ を参照してください。SLAMD は java.net プロジェクトとしても公開されています。https://slamd.dev.java.net/ を参照してください。

Directory Server とプロセッサ

Directory Server は複数のプロセッサが搭載されたシステム上で動作するように開発されたマルチスレッドプロセスであり、そのパフォーマンスはほとんどの場合、割り当てるプロセッサの数を増やすにつれて線形的に増加していきます。多数のプロセッサが搭載されたシステム上で Directory Server を実行する場合、Directory Server がサーバー操作を処理するために起動するスレッドの数を表すサーバープロパティー thread-count を、dsconf コマンドを使って調整することを検討してください。

ただし、特定のディレクトリ配備では、プロセッサを追加してもパフォーマンスがあまり改善されない可能性があります。検索、インデックス、およびレプリケーションで要求の厳しいパフォーマンス要件を扱うときは、解決策の一部として、負荷分散やディレクトリプロキシなどの技術を検討します。

Directory Server とメモリー

必要メモリー量に大きな影響を与える要因は、次のとおりです。

• Directory Server のデータベースキャッシュ、エントリキャッシュ、およびインポートキャッシュの設定

• ピーク時のレプリケーション負荷

• ピーク時のクライアントアプリケーション負荷

• file-descriptor-count と thread-count のサーバー設定

• オペレーティングシステム、システム上で実行されるほかのアプリケーション、およびシステム管理アクティビティーのオーバーヘッド

Directory Server の実行に必要なメモリーのサイズを見積もるには、Directory Server Resource Kit コマンドや SLAMD などによって生成されたアプリケーション負荷など、本番時と同様の負荷のかかったシステム上の特定の Directory Server 設定で必要とされるメモリーを見積もります。

Directory Server プロセスのサイズを測定する前に、サーバーを起動してからしばらく放置し、通常処理時またはピーク処理時と同様にエントリキャッシュが満たされるようにします。すべてをキャッシュメモリーに格納するだけの容量が存在する場合、ディレクトリ内のすべてのエントリを読み取ってエントリキャッシュを満たすことで、この Directory Server のウォームアップ期間を短縮することができます。すべてをキャッシュメモリーに格納するだけの容量が存在しない場合には、実際の場合と同様にキャッシュが満たされるまで、通常処理またはピーク処理のパターンを使ってクライアントアクセスのシミュレーションをしばらく実行します。

サーバーが平衡状態に達したら、Solaris や Linux 上の pmap、Windows タスクマネージャーなどのユーティリティーを使って Directory Server プロセスが使用しているメモリーを測定できます。このプロセスは、UNIX システム上では ns-slapd、Windows システム上では slapd.exe になります。詳細については、pmap(1) のマニュアルページを参照してください。通常処理時、ピーク処理時の両方のプロセスサイズを測定したあとで、使用すべきメモリーの量を決定してください。

システム管理に必要なメモリーとシステム自体に必要なメモリーの量を、必ず見積もりに追加してください。オペレーティングシステムのメモリー要件は、システムの構成によって大きく変わる可能性があります。したがって、使用するオペレーティングシステムの実行に必要なメモリーの見積もりは、実験的に行う必要があります。システムのチューニングが完了したら、メモリーの使用量を監視し、その量を見積もりに追加します。Solaris の vmstat および sar コマンド、Windows のタスクマネージャーなどのユーティリティーを使えば、メモリーの使用量を測定できます。

Directory Server の実行時に、パフォーマンスに悪影響を及ぼす継続的なページスワッピングが発生しないだけのメモリーを、最低限提供するようにしてください。サポート対象外ですが Solaris システム用として別途入手可能な MemTool などのユーティリティーは、メモリーが実行中のアプリケーションによってどのように使用され、それらのアプリケーションにどのように割り当てられているかを監視する際に役立つ可能性があります。

システムに追加のメモリーを搭載できない場合に、これまでどおり継続的なページスワップを監視し続けるには、データベースキャッシュやエントリキャッシュのサイズを減らします。heap-high-threshold-size および heap-low-threshold-size サーバー設定を使ってメモリーの使用量を調整することもできますが、ヒープしきい値メカニズムを使うのは最後の手段と考えてください。Directory Server がヒープメモリーを解放するためにほかの処理を遅延させる必要が生じると、パフォーマンスが低下します。

Red Hat Linux システムの場合、/proc/sys/vm/swappiness パラメータを調整して、カーネルがどの程度積極的にメモリーをスワップアウトするかをチューニングできます。swappiness の値が大きいとカーネルがスワップアウトするデータ量が大きいことを意味し、swappiness の値が小さいとカーネルがスワップスペースをできるかぎり使用しないようにすることを意味します。したがって、swappiness 設定値を少なくすることにより、カーネルがメモリーに保持するサーバープロセスが増えてスワップアウトするまでの時間が長くなるので、Directory パフォーマンスが改善される場合があります。システムが単一の Directory Server インスタンス専用である場合は、swappiness をゼロに設定します。システム上で複数の重い処理または複数の Directory Server の並列インスタンスを実行している場合は、swappiness の設定をいろいろ変えて Directory パフォーマンスをテストしてみてください。

Directory Server とローカルディスク容量

ディスクの使用と I/O 能力は、パフォーマンスに強く影響します。多数の変更をサポートする配備では特に、ディスクサブシステムが入出力の障害点になる可能性があります。この節では、Directory Server インスタンスの全体的なディスク容量を見積もるために推奨される方法を示します。

Directory Server やそれがアクセスするデータをネットワークディスク上にインストール「しない」でください。

Directory Server ソフトウェアは、ネットワークに接続されたストレージを NFS、AFS、または SMB 経由で使用することをサポートしません。設定、データベース、およびインデックスファイルはすべて、インストールを終えてからも、常にローカルストレージ上に配置する必要があります。ログファイルはネットワークディスク上に格納できます。

必要なローカルディスク容量に大きな影響を与える要因は、次のとおりです。

• ディレクトリエントリの数

• エントリの平均サイズ

• サーバーデータベースのページサイズの設定 (ディレクトリデータをインポートする場合)

  データベースのページサイズを調整するには、nsslapd-db-page-size 属性を設定します。詳細については、「Directory Server のデータベースページサイズ」を参照してください。

• ディレクトリデータ上で維持されるインデックスの数

• 格納される LDIF、バックアップ、ログ、およびコアファイルのサイズ

インデックスの設定、データベースのページサイズの調整、およびディレクトリデータのインポートが完了したら、instance-path/ の内容のサイズを読み取り、それに予期される LDIF、バックアップ、ログ、およびコアファイルのサイズを追加することで、インスタンスに必要なディスク容量を見積もることができます。また、特にピーク処理時に、測定したサイズがどのくらい増加することが予期されるかを見積もります。ログレベルやログサイズをデバッグ目的で増やす必要が生じた場合のために、数 G バイトの追加容量を errors ログ用として必ず残すようにしてください。

ディレクトリデータに必要なディスクの見積もりは、推定によって行える場合があります。本番時に予期されるのと同量のデータを使って Directory Server に負荷をかけることが現実的ではない場合には、「サンプルディレクトリデータの作成」で示唆したように、より小さなサンプルデータセットに基づいて推定します。使用するディレクトリデータの量が本番時より少ない場合、ほかの測定値についても推定する必要があります。

ローカルディスクがどのくらい高速でなければいけないかを決定する要因は、次のとおりです。

• レプリケーショントラフィックの量など、維持される更新のレベル

• ディレクトリデータが主にキャッシュ内、ディスク上のどちらに存在するか

• アクセスロギングとエラーロギングで使用するログレベル、および監査ログを有効にするかどうか

• ディレクトリデータ、ログ、およびトランザクションログ (更新用) をそれぞれ専用のディスクサブシステム上に配置できるかどうか

• Directory Server がオンライン、オフラインのいずれの状態のときにバックアップを実行するか

通常の運用環境で、使用されるディスクをいっぱいにしないでください。Solaris iostat コマンドなどのツールを使えば、潜在的な入出力障害を特定できます。

ディスクのスループットを増やすには、ディスクサブシステム間でファイルを分散させます。トランザクションログ (dsconf set-server-prop db-log-path:/transaction/log/path)、データベース (dsconf create-suffix --db-path /suffix/database/path suffix-name)、およびログファイル (dsconf set-log-prop path:/log/file/path) にそれぞれ専用のディスクサブシステムを割り当てることを検討してください。さらに、Solaris tmpfs ファイルシステムなどのメモリーベースのファイルシステム上に、データベースキャッシュファイルを配置することを検討してください。そのようなファイルシステムでは、利用可能なメモリーが使い果たされた場合にのみファイルがディスクにスワップされます (例: dsconf set-server-prop db-env-path:/tmp)。メモリーベースのファイルシステム上にデータベースキャッシュファイルを配置する場合には、システムの容量が不足してそのファイルシステムの全体をメモリー内に保持できなくなることのないよう、注意する必要があります。

スループットをさらに増やすには、複数のディスクを RAID 構成にして使用します。Sun StorEdge^TM 製品で提供されているような大容量で不揮発性 I/O バッファーや高パフォーマンスのディスクサブシステムによって、Directory Server のパフォーマンスや稼動時間は大きく向上します。Solaris 10 システムの場合、ZFS を使用してもパフォーマンスが改善する可能性があります。

Directory Server とネットワーク接続

Directory Server はネットワーク集約型アプリケーションです。次の式を使えば、理論的な最大スループットを見積もることができます。この式ではレプリケーションのトラフィックが考慮されていない点に注意してください。

max. throughput = max. entries returned/second x average entry size

Directory Server はピーク時に毎秒 5000 件の検索に応答する必要があり、またサーバーは検索ごとに 1 つのエントリを返すものとします。エントリの平均サイズは 2000 バイトです。理論的な最大スループットは 10M バイトつまり 80M ビットになります。ただし、レプリケーションは考慮していません。しかし 80M ビットの方が、100M ビット Ethernet アダプタ 1 つで実現するスループットよりも大きくなる傾向があります。Directory Server インスタンスのネットワーク可用性を改善するには、システムにより高速な接続を装備するか、複数のネットワークインタフェースを装備してください。Directory Server は、同一プロセス内で複数のネットワークインタフェース上で待機できます。

先の例では、ディレクトリの読み取り時または検索時にクライアントアプリケーションが「すべての」属性を要求するものと仮定していました。一般に、「必要な」属性のみを要求するようにクライアントアプリケーションを設計すべきです。

負荷分散のために、同じネットワーク上で Directory Server をクラスタにする場合は、レプリケーションで新たに生じる負荷がネットワークインフラストラクチャーで対応できることを確認します。広域ネットワーク上でマルチマスターレプリケーションを計画する場合には、その構成のテストを行い、その接続が最小限の待ち時間とゼロに近いパケット損失で十分なスループットを提供できることを確認してください。長い待ち時間と大量のパケット損失はどちらも、レプリケーションの速度を低下させます。さらに、レプリケーショントラフィックがロードバランサを通過するようなトポロジは避けてください。

クライアントが使用可能な Directory Server リソースの制限

Directory Server のデフォルトの設定では、クライアントアプリケーションが必要以上の Directory Server リソースを使用できるようになっています。

次のようなリソースの使い方をすると、ディレクトリのパフォーマンスに悪影響が及ぶ可能性があります。

• 多数の接続を開いたあと、それらをアイドル状態や未使用状態のまま放置する

• インデックスを使用しない高コストの検索を不必要に起動する

• 予定外の巨大なバイナリ属性値を格納する

配備状況によっては、デフォルトの設定を変更すべきでないことがあります。Directory Server のチューニングが不可能な配備では、Directory Proxy Server を使用することで、リソースの制限とサービス拒否攻撃への防備を行なってください。

配備状況によっては、Directory Server の 1 つのインスタンスが、ユーザーメールアプリケーションなどのディレクトリクライアントやメッセージングサーバーといった、クライアントアプリケーションをサポートしなければならないことがあります。そのような状況では、バインド DN ベースのリソース制限を使用することで、ディレクトリ集約型アプリケーションに対して個別の制限を設けることを検討してください。ある特定のアカウントの制限を調整するには、そのエントリ上の属性 nsSizeLimit、nsTimeLimit、nsLookThroughLimit、および nsIdleTimeout を設定します。個々のアカウントのリソース制限を制御する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「各クライアントアカウントのリソース制限の設定」を参照してください。

表 6–1 では、リソース制限のグローバル値を設定するパラメータについて説明します。 表 6–1 の制限は、Directory Manager ユーザーには適用されません。したがって、クライアントアプリケーションが決して Directory Manager ユーザーとして接続することのないようにしてください。

Directory Server が使用するシステムリソースの制限

表 6–2 では、Directory Server インスタンスによるシステムリソースやネットワークリソースの使用方法をチューニングするために使用可能なパラメータについて説明します。

20 + 
4 * (number of databases) +
 (total number of indexes) + 
(value of nsoperationconnectionslimit) * 
(number of chaining backends) + 
ReplDescriptors + 
PTADescriptors + 
SSLDescriptors

Directory Server の基本的なサイジングの例: ディスクとメモリーの要件

この節では、配備用として Directory Server のディスクおよびメモリー要件のサイジングを行う際の初期手順を示す例を取り上げます。この例で使用するシステムは、何か特別な理由があって選択したわけではなく、サイジングタスクをすばやく完了できるだけの処理能力とメモリーを備えているという理由で選択しただけです。これは必ずしも、業務用の推奨システムを表しているとはかぎりません。ただし、これを参考にすれば、本番システムで必要となるメモリーやディスクの容量に関する洞察が得られます。

システムの特性

次のシステム情報は、Solaris Management Console (smc) を使って監視したものです。

• 2 個の AMD64 CPU (2.2 GHz)

• Solaris 10 オペレーティングシステム

• 4G バイトの物理メモリー

• 40G バイトのスワップ

• Directory Server インストール前の使用済み物理メモリー: 700M バイト

• Directory Server インストール前の空き物理メモリー: 3400M バイト

• CPU 使用率: 1 %

• ローカルディスク: ロギング機能付き UFS としてフォーマットされた 1 つのパーティション

この例では、システムは Directory Server 専用でした。その他のユーザーは一人もログインしておらず、デフォルトのシステムプロセスのみが実行されていました。

Directory Server インスタンスの準備

zip ディストリビューションを展開したあと、Directory Server ソフトウェアをローカルディスク上にインストールします。

$ ./dsee_deploy install -c DS -i /local

便宜上、環境変数を次のように設定します。

$ export PATH=/local/ds6/bin:/local/dsrk6/bin:/local/dsee6/bin:${PATH}
$ export DIRSERV_PORT=1389
$ export LDAP_ADMIN_PWF=~/.pwd

ソフトウェアのインストールと環境変数の設定が完了したら、LDAP、LDAPS のそれぞれのデフォルトポートを使って Directory Server インスタンスを作成します。

$ dsadm create -p 1389 -P 1636 /local/ds
Choose the Directory Manager password:
Confirm the Directory Manager password:
$ du -hs /local/ds
610K   /local/ds

サフィックスを作成するまでは、Directory Server インスタンスの使用ディスク容量は 1M バイトを下回っています。

$ dsadm start /local/ds
Server started: pid=8046
$ dsconf create-suffix dc=example,dc=com
Certificate "CN=hostname, CN=1636, CN=Directory Server,
 O=Sun Microsystems" presented by the server is not trusted.
Type "Y" to accept, "y" to accept just once, "n" to refuse, "d" for more
 details: Y
$ du -hs /local/ds
53M   /local/ds

この例では、特に明記しないかぎり、Directory Server のデフォルト設定に対する追加変更は行いません。

サフィックスに 10,000 件のサンプルディレクトリエントリを設定する

Directory Server Resource Kit の一部として提供されている makeldif コマンドとサンプルファイルを使用すれば、1K バイトから 1M バイトまでのサイズのサンプル LDIF ファイルを作成できます。makeldif コマンドの使用方法を示す例については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「To Install Directory Server Enterprise Edition 6.3 From Zip Distribution」を参照してください。

次の各ファイル内のエントリは、実際の配備時に使用するエントリ数よりは少なめかもしれません。

$ du -h /var/tmp/*
 57M   /var/tmp/100k.ldif
 5.7M   /var/tmp/10k.ldif
 573M   /var/tmp/1M.ldif

これらのファイル内のエントリの例を、次の LDIF に示します。

dn: uid=Aartjan.Aalders,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
givenName: Aartjan
sn: Aalders
cn: Aartjan Aalders
initials: AA
uid: Aartjan.Aalders
mail: Aartjan.Aalders@example.com
userPassword: trj49xeq
telephoneNumber: 935-748-6699
homePhone: 347-586-0252
pager: 906-399-8417
mobile: 452-898-9034
employeeNumber: 1000004
street: 64197 Broadway Street
l: Lawton
st: IN
postalCode: 57924
postalAddress: Aartjan Aalders$64197 Broadway Street$Lawton, IN  57924
description: This is the description for Aartjan Aalders.

まず、ディスク上で 5.7M バイトを占有する 10k.ldif の内容をインポートすることで、サイジングを始めます。

$ dsadm stop /local/ds
Server stopped
$ dsadm import -i /local/ds /var/tmp/10k.ldif dc=example,dc=com
…

デフォルトのインデックス作成では、10k.ldif により、インスタンスファイルのサイズが 72M バイト - 53M バイト、つまり 19M バイトだけ増加します。

$ du -hs /local/ds
 72M   /local/ds

さらに別の 5 つの属性にもインデックスを付けると、サイズが約 7M バイト増加します。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsconf reindex dc=example,dc=com
…
## example: Finished indexing.

Task completed (slapd exit code: 0).
$ du -hs /local/ds
 79M   /local/ds

デフォルトのキャッシュ設定でメモリーサイズを監視すると、サフィックスからエントリキャッシュへまだ何も読み込まれていなければ、サーバープロセスは約 170M バイトのメモリーを占有し、そのヒープサイズは約 56M バイトになります。

$ dsadm start /local/ds
Server started: pid=8482
$ pmap -x 8482
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
0000000000437000      61348      55632      55380          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     178444     172604      76532          -

次に、キャッシュに情報を格納してから pmap コマンドの出力を再度確認すると、ヒープが約 10M バイトだけ増加し、プロセスの合計サイズもそれと同じだけ増加しています。

$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8482
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      70564      65268      65024          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     187692     182272      86224          -

この数値を、デフォルトインデックス作成の場合と比較してみましょう。

$ dsconf delete-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsconf reindex dc=example,dc=com
…
## example: Finished indexing.

Task completed (slapd exit code: 0).
$ dsadm stop /local/ds
 Server stopped
$ dsadm start /local/ds
 Server started: pid=8541
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8541
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      70564      65248      65004          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     187680     182240      86192          -

エントリ数がわずか 10,000 件であれば、デフォルトのキャッシュサイズを変更しないでください。

$ dsconf get-server-prop | grep cache
db-cache-size                      :  32M
import-cache-size                  :  64M
$ dsconf get-suffix-prop dc=example,dc=com | grep entry-cache-size
entry-cache-size                   :  10M

デフォルトのエントリキャッシュはサイズが小さいため、エントリ数がわずか 10,000 件であっても、情報が格納されると間違いなく、キャッシュが完全にいっぱいになります。エントリが完全に収まるキャッシュのサイズを確認するには、エントリキャッシュサイズをある大きな値に設定し、データをインポートし直してから、キャッシュに情報を格納します。

$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G
$ dsadm stop /local/ds
Server stopped
$ dsadm import -i /local/ds /var/tmp/10k.ldif dc=example,dc=com
…
$ dsadm start /local/ds
Server started: pid=8806
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8806
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     116644     109996     109780          - rw---    [ heap ]

ここでは、10,000 件のエントリが、約 55M バイト (110 - 55) のエントリキャッシュメモリーを占有しています。

サフィックスに 100,000 件のサンプルディレクトリエントリを設定する

100,000 件のエントリを追加する場合は、データベースやエントリキャッシュ内に収めるべきディレクトリデータの量が増えます。まず、100,000 件のエントリをインポートし、この分量のディレクトリデータで必要となるディスクのサイズを確認します。

$ dsadm import -i /local/ds /var/tmp/100k.ldif dc=example,dc=com
…
$ du -hs /local/ds
 196M   /local/ds

データベース内に格納されている、サフィックス dc=example,dc=com のディレクトリデータは、この時点で約 142M バイトを占有しています。

$ du -hs /local/ds/db/example/
 142M   /local/ds/db/example

データベースキャッシュのサイズを増やせば、この内容がキャッシュ内に収まるようにすることができます。ディレクトリデータの分量が時間の経過とともに増加することが予期される場合には、データベースキャッシュを現在必要とされるよりも大きな値に設定できます。エントリキャッシュサイズも、必要とされるより大きな値に設定できます。エントリキャッシュは、起動時に割り当てられるデータベースキャッシュとは異なり、サーバーがクライアントの要求に応答するたびに増加します。

$ dsconf set-server-prop db-cache-size:200M
$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G

$ dsadm stop /local/ds
 Server stopped
$ dsadm start /local/ds
 Server started: pid=8640
$ pmap -x 8640
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      61348      55404      55148          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     491984     485736     174620          -

これから、起動時のサーバーインスタンスのヒープは比較的小さいが、データベースキャッシュのメモリーは割り当て済みであることがわかります。プロセスのサイズは、1G バイトの約半分になっています。

$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8640
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     610212     604064     603840          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    1040880    1034428     723360          -

ヒープサイズはこの時点で、情報が格納されたエントリキャッシュを反映したものとなっています。これは、100,000 件の小規模ディレクトリエントリの場合に約 550M バイト増えています。その LDIF はディスク上で 57M バイトを占有していました。

インデックスを 5 つ追加しても、プロセスのサイズはほぼ同じです。データベースキャッシュのサイズに変わりはありません。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsadm stop /local/ds
 Server stopped
$ dsadm import -i /local/ds /var/tmp/100k.ldif dc=example,dc=com
…
$ dsadm start /local/ds
 Server started: pid=8762
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8762
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     610212     603832     603612          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    1040876    1034192     723128          -

ただし、データベースのサイズは若干大きくなっています。インデックスを追加したことで、データベースのサイズが 142M バイトから 163M バイトへと増加しました。

$ du -hs /local/ds/db/example/
 163M   /local/ds/db/example

サフィックスに 1,000,000 件のサンプルディレクトリエントリを設定する

100,000 件のエントリから 1,000,000 件のエントリに移行すると、4G バイトの物理メモリーを備えたシステム上ではもはや十分な容量を確保できず、すべてのエントリをエントリキャッシュ内に収めることができなくなります。まず、データをインポートし、そのディスク上での占有サイズを確認します。

$ dsadm import -i /local/ds /var/tmp/1M.ldif dc=example,dc=com
…
$ du -hs /local/ds/db/example/
 1.3G   /local/ds/db/example

このインスタンスの存続期間中にディレクトリデータのサイズが約 25 % 増加することが予期されると仮定して、データベースキャッシュのサイズを 1700M バイトに設定します。

$ dsadm start /local/ds
Server started: pid=9060
$ dsconf set-server-prop db-cache-size:1700M
$ dsadm stop /local/ds
Server stopped
$ dsadm start /local/ds
Server started: pid=9118
$ pmap -x 9118
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      65508      55700      55452          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    1882448    1034180      76616          -

データベースキャッシュがこの大きさで、かつ物理メモリーが 4G バイトしかなければ、このサフィックスのエントリキャッシュに格納できるのは、ほんの一部のエントリだけになります。ここでは、エントリキャッシュサイズを 1G バイトに設定してからキャッシュに情報を格納し、プロセスのヒープサイズがどのように変化するかを確認します。

$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:1G
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 9118
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000    1016868    1009852    1009612          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    2883268    2477064    1080076          -

プロセスの合計サイズは 2.8G バイトを超えています。

$ prstat -p 9118
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
  9118 myuser   2816M 2374M sleep   59    0   0:03:26 0.5% ns-slapd/42

これまでのエントリキャッシュサイズに基づいて推定すると、十分な物理メモリーが存在していれば、エントリキャッシュだけで 5.5G バイトまたは 6G バイトが使用されることが予期できます。

インデックスを 5 つ追加してディレクトリデータベースのサイズを確認すると、そのインデックス追加によって、データベースのサイズが約 200M バイト増加したことがわかります。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsadm stop /local/ds
Server stopped
$ dsadm import -i /local/ds /var/tmp/1M.ldif dc=example,dc=com
…
$ du -hs /local/ds/db/example
 1.5G   /local/ds/db/example

測定結果

表 6–3 は、この例での測定内容を記録したものです。ここには、サーバープロセスサイズ、デフォルトデータベースキャッシュファイルサイズのいずれも含まれていません。

実際の配備環境で同様の実験を行なった場合の結果はおそらく、ここで示したものと大幅に異なります。

実際の配備時には、エントリ数やインデックスを作成する属性の数が大幅に増える可能性があります。ハードウェアを注文する前に各自で実験的なテストを行い、調整を施すようにしてください。