この記事では、ローカル セキュリティ機関サブシステム サービス (LSASS、Lsass.exe プロセスとも呼ばれます)、LSASS の構成のベスト プラクティス、およびメモリ使用量に対する期待の基本について説明します。 この記事は、ドメイン コントローラー (DC) での LSASS のパフォーマンスとメモリ使用量の分析のガイドとして使用する必要があります。 この記事の情報は、このエンジンを最適化するためにサーバーと DC を調整および構成する方法について質問がある場合に役立ちます。
LSASS は、ローカル セキュリティ機関 (LSA) ドメイン認証と Active Directory 管理の管理を担当します。 LSASS は、クライアントとサーバーの両方の認証を処理し、Active Directory エンジンも制御します。 LSASS は、次のコンポーネントを担当します。
- ローカル セキュリティ機関
- NetLogon サービス
- セキュリティ アカウント マネージャー (SAM) サービス
- LSA サーバー サービス
- Secure Sockets Layer (SSL)
- Kerberos v5 認証プロトコル
- NTLM 認証プロトコル
- LSA に読み込まれるその他の認証パッケージ
Active Directory データベース サービス (NTDSAI.dll) は、拡張可能ストレージ エンジン (ESE、ESENT.dll) と連携します。
DC での LSASS メモリ使用量の視覚的な図を次に示します。
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 があるかどうかによって異なります。
Windows Server 2019 より前の Windows Server バージョンでは、既定では LSASS は ESE バージョン ストアの 64 ビット コンピューターで最大約 400 MB のメモリを使用する場合があります (CPU の数に応じて)。 バージョン ストアの使用方法の詳細については、Ryan Ries による次の ASKDS ブログ投稿「The Version Store Called and They're All Out of Buckets」を参照してください。
Windows Server 2019 では、これは簡略化され、NTDS サービスが最初に開始されると、ESE バージョンストアのサイズは物理 RAM の 10% として計算され、最小 400 MB、最大 4 GB になります。 この問題とバージョン ストアのトラブルシューティングの詳細については、Ryan Ries の優れたブログ Deep Dive: Active Directory ESE Version Store Changes in Server 2019 を参照してください。
その他のメモリ使用量
最後に、コード、スタック、ヒープ、およびさまざまな固定サイズのデータ構造 (スキーマ キャッシュなど) があります。 LSASS が使用するメモリの量は、コンピューターの負荷によって異なる場合があります。 実行中のスレッドの数が増えると、メモリ スタックの数も増えます。 LSASS では、これらの固定コンポーネントに平均して 100 MB から 300 MB のメモリが使用されます。 大量の RAM がインストールされている場合、LSASS は、より多くの RAM とより少ない仮想メモリを使用できます。
ドメイン コントローラー上のプログラムの数を制限または最小化するか、必要に応じて RAM を追加します
最適なパフォーマンスを得るための LSASS は、特定の DC で可能な限り多くの RAM を使用します。 LSASS は、他のプロセスが必要とする場合に RAM を解放します。 考え方は、LSASS のパフォーマンスを最適化しながら、コンピューター上で実行される可能性のある他のプロセスを引き続き計算することです。 監視エージェントを含む、注意するプログラムの一覧。 一部のお客様には、さまざまなサーバー機能用の個別のエージェントがあり、かなりの RAM リソースを消費する可能性があります。 いくつかの WMI クエリを発行する場合があります。ここでは、いくつかの詳細を以下に示します。
このため、パフォーマンスを向上させるには、DC 上のプログラムの数を制限または最小化することをお勧めします。 メモリ要求がない場合、LSASS はこのメモリを使用して Active Directory データベースをキャッシュするため、最適なパフォーマンスを実現します。
DC にパフォーマンスの問題がある場合は、メモリ使用率が高いプロセスも監視します。 トラブルシューティングが必要な問題が発生する可能性があります。 これには Microsoft コンポーネントが含まれる場合があります。 最新のサービス更新プログラムに対応していることを確認してください。Microsoft には、品質更新プログラムの一部として過剰なメモリ使用率のソリューションが含まれており、DC のパフォーマンスにも役立つ可能性があります。
使用プロファイルに応じて、大量の RAM を消費する可能性がある組み込みの OS 機能があります。
ファイル サーバー。 DC は、SYSVOL 共有と Netlogon 共有用のファイル サーバー、サービス グループ ポリシー、およびポリシーおよびスタートアップ/ログオン スクリプト用のスクリプトでもあります。 ただし、お客様が DC を使用して他のファイル コンテンツにサービスを提供していることがわかります。 その後、SMB ファイル サーバーは RAM を使用してアクティブなクライアントを追跡しますが、何よりもまず、ファイル コンテンツによって OS ファイル キャッシュが拡張され、RAM の ESE データベース キャッシュと競合します。
WMI クエリ。 多くの場合、監視ソリューションでは多くの WMI クエリが実行されます。 個々のクエリの実行が低コストになる場合があります。 多くの場合、監視ソリューションが Windows が管理するさまざまなイベント ログから新しいイベントが抽出されるため、オーバーヘッドが発生するのは呼び出しの量です。
最も多くのボリュームを生成するイベント ログは、通常、セキュリティ イベント ログです。 また、これは、セキュリティ管理者が特に DC から収集するイベント ログでもあります。
WMI サービスは、クエリを最適化する動的メモリ割り当てスキームを使用します。 そのため、WMI サービスは大量のメモリを割り当て、再び ESE データベース キャッシュと競合する可能性があります。