次の方法で共有


ADDS パフォーマンス のチューニングでの LDAP の考慮事項

重要

以下は、 Active Directory Domain Services のキャパシティ プランニングに関する記事で詳しく説明されている Active Directory ワークロードのために、サーバーハードウェアを最適化するための主な推奨事項と考慮事項の概要を示しています。 Active Directory Domain Services のキャパシティ プランニングを検討して、これらの推奨事項に関する技術的な理解と影響を理解されることを強くお勧めします。

LDAP クエリの検証

LDAP クエリが効率的なクエリの作成に関する推奨事項に準拠していることを確認します。

Active Directory に対して使用するクエリを適切に記述、構築、および分析する方法に関する広範囲のドキュメントが、MSDN に用意されています。 詳細については、「より効率的な Microsoft Active Directory 対応アプリケーションの作成」を参照してください。

LDAP ページ サイズの最適化

クライアント要求への応答として複数のオブジェクトを含む結果を返す場合、ドメイン コントローラーは結果セットを一時的にメモリに格納する必要があります。 ページ サイズを大きくすると、メモリ使用量が増加し、キャッシュで不必要に古いアイテムが保持される可能性があります。 この場合、既定の設定が最適です。 ページ サイズの設定を増やすことが推奨されるシナリオがいくつかあります。 特に不適切なことが見つからない限り、既定値を使用することをお勧めします。

クエリに多くの結果が含まれている場合は、同時に実行される同様のクエリの制限が発生する可能性があります。 これは、LDAP サーバーが Cookie プールと呼ばれるグローバル メモリ領域を消費する可能性があるためです。 「LDAP サーバー Cookie の処理方法」で説明されているように、プールのサイズを増やす必要がある場合があります。

これらの設定を調整するには、「Windows Server 2008 and newer domain controller returns only 5000 values in a LDAP response (Windows Server 2008 と新しいドメイン コントローラーが LDAP 応答で 5000 の値のみを返す)」を参照してください。

インデックスを追加するかどうかを判断する

属性のインデックス作成は、フィルターで属性名を持つオブジェクトを検索する場合に便利です。 インデックスを作成すると、フィルターを評価するときにアクセスする必要があるオブジェクトの数を減らすことができます。 ただし、これにより書き込み操作のパフォーマンスが低下します。これは、対応する属性が変更または追加されたときにインデックスを更新する必要があるためです。 また、ディレクトリ データベースのサイズも大きくなりますが、多くの場合、ストレージのコストを上回るメリットがあります。 ログ記録を使用して、高コストで非効率なクエリを見つけることができます。 見つかった場合は、検索のパフォーマンスを向上させるために、対応するクエリで使用されるいくつかの属性のインデックスを作成することを検討してください。 Active Directory 検索の動作の詳細については、「Active Directory の検索のしくみ」を参照してください。

インデックスの追加でメリットが得られるシナリオ

  • データの要求におけるクライアントの負荷が大きな CPU 使用率が発生していても、クライアントのクエリの動作を変更または最適化できない。

  • インデックスなしの属性が原因で、クライアントの負荷によってサーバー上で大量のディスク I/O が生成されていても、クライアントのクエリの動作を変更または最適化できない。

  • インデックスの対象範囲が不足しているために、クエリの実行に時間がかかり、クライアントが許容できる時間内に完了していない。

  • 長時間の大量のクエリが原因で、ATQ LDAP スレッドの消費と枯渇が発生している。 次のパフォーマンス カウンターを監視します。

    • NTDS\Request Latency –これは、要求の処理にかかる時間によって異なります。 Active Directory では、120 秒後 (既定値) に要求がタイムアウトになりますが、ほとんどの処理はもっと高速に実行され、極端に実行時間が長いクエリは、全体の数値の中で見えなくなります。 絶対しきい値ではなく、このベースラインの変化を見ます。

      注意

      この値が高い場合は、他のドメインに対する "プロキシ処理" 要求や CRL チェックの遅延を示している可能性もあります。

    • NTDS\Estimated Queue Delay –最適なパフォーマンスを得るために、これが 0 に近いことが理想的です。これは要求が処理のために待たされる時間がないことを意味するからです。

このようなシナリオは、次の 1 つまたは複数の方法を使用して検出できます。

インデックスに関するその他の考慮事項

  • オプションとしてのクエリの調整をすべて行った後に、インデックスの作成が問題に対する適切な解決策であることを確認してください。 ハードウェアのサイズを正しく設定することは非常に重要です。 適切な修正が属性のインデックスを作成することで、ハードウェアの問題を見えなくする試みではない場合にのみ、インデックスを追加する必要があります。

  • インデックスを作成すると、少なくともインデックスを作成する属性の合計サイズだけ、データベースのサイズが大きくなります。 したがって、データベースの増加量の見積もりは、属性のデータの平均サイズを取得し、それに属性が設定されるオブジェクトの数を乗算することで評価できます。 一般に、これはデータベース サイズの約 1% の増加に相当します。 詳細については、データストアのしくみに関するページを参照してください。

  • 検索操作が主に組織単位レベルで行われる場合は、コンテナー化された検索のためのインデックス作成を検討してください。

  • タプル インデックスは通常のインデックスよりも大きくなりますが、サイズを見積もるのは非常に困難です。 増加の下限として、通常のインデックス サイズの見積もりを使用し、最大値は 20% にします。 詳細については、データストアのしくみに関するページを参照してください。

  • 検索操作が主に組織単位レベルで行われる場合は、コンテナー化された検索のためのインデックス作成を検討してください。

  • タプル インデックスは、中間の検索文字列と最終的な検索文字列をサポートするために必要です。 最初の検索文字列にタプル インデックスは必要ありません。

    • 最初の検索文字列– (samAccountName = MYPC *)

    • 中間の検索文字列– (samAccountName=*MYPC*)

    • 最後の検索文字列– (samAccountName=*MYPC$)

  • インデックスを作成すると、インデックスの作成中にディスク I/O が生成されます。 これは、優先順位の低いバックグラウンド スレッドで実行され、受信要求はインデックス構築より優先されます。 環境の容量計画が正常に完了している場合は、このことを意識する必要はありません。 ただし、書き込みが多いシナリオや、ドメイン コントローラーの記憶域の負荷が不明な環境では、クライアントの操作性が低下する可能性があるため、営業時間外に行う必要があります。

  • インデックスの構築はローカルで行われるため、レプリケーション トラフィックへの影響は最小限に抑えられます。

詳細については、以下を参照してください。

その他の参照情報