AD DS のパフォーマンス チューニングでのメモリ使用量に関する考慮事項

  • [アーティクル]

この記事では、ローカル セキュリティ機関サブシステム サービス (LSASS、Lsass.exe プロセスとも呼ばれます) の基本事項、LSASS の構成に関するベスト プラクティス、予想されるメモリ使用量について説明します。 この記事は、ドメイン コントローラー (DC) での LSASS のパフォーマンスとメモリ使用の分析に関するガイドとしてお使いください。 この記事の情報は、このエンジンを最適化するためにサーバーと DC をどのように調整し、構成するかについて不明な点がある場合に役立ちます。

LSASS の役目は、ローカル セキュリティ機関 (LSA) のドメイン認証の管理と Active Directory の管理です。 LSASS では、クライアントとサーバーの両方の認証を処理し、Active Directory エンジンも制御します。 LSASS が担当する対象は次のコンポーネントです。

  • ローカル セキュリティ機関
  • Netlogon サービス
  • セキュリティ アカウント マネージャ (SAM) サービス
  • LSA サーバー サービス
  • SSL (Secure Sockets Layer)
  • Kerberos v5 認証プロトコル
  • NTLM 認証プロトコル●ntlmにんしょうぷろとこる○
  • LSA に読み込まれるその他の認証パッケージ

Active Directory データベース サービス (NTDSAI.dll) は、Extensible Storage Engine (ESE、ESENT.dll) と連携します。

DC での LSASS メモリ使用量の図を次に示します。

Diagram of the components that use LSASS memory

DC で LSASS が使用するメモリの量は、Active Directory の使用に伴って増加します。 データは、照会されるとメモリにキャッシュされます。 そのため、通常は、Active Directory データベース ファイル (NTDS.dit) のサイズより多くのメモリが LSASS で使用されます。

図に示すように、LSASS のメモリ使用量は、ESE データベース バッファー キャッシュ、ESE バージョン ストアなど、いくつかの部分に分割できます。 この記事の残りの部分では、これらの各部分について説明します。

ESE データベース バッファー キャッシュ

LSASS 内で可変メモリ使用量が最も大きいのは、ESE データベース バッファー キャッシュです。 このキャッシュのサイズは、1 MB 未満からデータベース全体のサイズにまで及びます。 キャッシュのサイズが大きいとパフォーマンスが向上するため、Active Directory のデータベース エンジン (ESENT) はキャッシュをできる限り大きく維持しようとします。 キャッシュのサイズはコンピューターのメモリ負荷によって異なりますが、ESE データベース バッファー キャッシュの最大サイズを制限するのはコンピューターにインストールされた物理 RAM "のみ" です。 これ以外にメモリ負荷がなければ、このキャッシュは Active Directory NTDS.dit データベース ファイルのサイズにまで拡大できます。 キャッシュできるデータベースが多いほど、DC のパフォーマンスは向上します。

注意

データベース キャッシュ アルゴリズムのしくみにより、データベースのサイズが使用可能な RAM より小さい 64 ビット システムでは、データベース キャッシュをデータベースのサイズより 30 から 40% 大きくすることができます。

ESE バージョン ストア

ESE バージョン ストアによる可変メモリ使用量 (上の図の赤い部分) が存在します。 使用されるメモリの量は、Windows Server 2019 以前のバージョンの Windows を使用しているかどうかによって異なります。

その他のメモリ使用

最後に、コード、スタック、ヒープや、さまざまな固定サイズのデータ構造 (スキーマ キャッシュなど) があります。 LSASS によって使用されるメモリの量は、コンピューターの負荷によって変化します。 実行中のスレッドの数が増えると、メモリ スタックの数も増加します。 LSASS では、これらの固定コンポーネントに対して平均 100 MB から 300 MB のメモリを使用します。 大量の RAM がインストールされている場合、LSASS では使用する RAM の量を増やし、仮想メモリの量を減らすことができます。

ドメイン コントローラー上のプログラムの数を制限または最小限にするか必要に応じて RAM を追加する

最適なパフォーマンスを達成するために、LSASS では特定の DC 上でできる限り多くの RAM を使用します。 他のプロセスによってその RAM が求められると、LSASS によって解放されます。 この目的は、コンピューター上で実行されている他のプロセスに対応しながら、LSASS のパフォーマンスを最適化することです。 考慮する対象のプログラムの一覧には、監視エージェントが含まれます。 一部のお客様は、大量の RAM リソースを消費する可能性があるさまざまなサーバー機能に個別のエージェントを使用します。 中には、多くの WMI クエリを発行する場合もあります。その詳細については以下を参照してください。

この理由により、また、パフォーマンスを向上するために、DC 上のプログラムの数を制限するか最小限にすることをお勧めします。 メモリの要求がない場合、LSASS ではこのメモリを使用して Active Directory データベースをキャッシュするので、最適なパフォーマンスが得られます。

DC にパフォーマンスの問題が発生した場合は、多くのメモリを使用しているプロセスにも注意してください。 それらに、トラブルシューティングが必要な問題が発生しているおそれがあります。 Microsoft コンポーネントがそれらに含まれている可能性があります。 サービス更新プログラムを最新の状態に保つようにしてください。Microsoft では、品質更新プログラムの一部として過剰なメモリ使用に対するソリューションを提供しています。これによっても DC のパフォーマンスが向上する可能性があります。

使用量プロファイルに応じて大量の RAM を消費する、組み込みの OS 機能が存在します。

  • ファイル サーバー。 DC は SYSVOL および Netlogon 共有用のファイル サーバーでもあり、グループ ポリシーとポリシーのスクリプト、およびスタートアップ/ログオン スクリプトを提供します。 しかし、お客様は DC を使用して他のファイル コンテンツを提供しています。 それによって SMB ファイル サーバーはアクティブ クライアントを追跡するために RAM を消費しますが、最も重要なことは、ファイルの内容が OS のファイル キャッシュを拡大させ、ESE データベース キャッシュと RAM を競合することです。

  • WMI クエリ。 多くの場合、監視ソリューションによって多くの WMI クエリが行われます。 個々のクエリの実行にはコストはかからないと考えられます。 多くの場合、オーバーヘッドを生じるのは呼び出しの量であり、特に、監視ソリューションによって Windows で管理されるさまざまなイベント ログから新しいイベントが抽出されるときです。

    生成される量が最も多いイベント ログは、通常、セキュリティ イベント ログです。 そしてこれが、セキュリティ管理者が (特に DC から) 収集するイベント ログでもあります。

    WMI サービスでは、クエリを最適化する動的メモリ割り当てスキームを使用します。 そのため、WMI サービスは多くのメモリを割り当てる可能性があり、この場合も ESE データベース キャッシュと競合します。