Überlegungen zur Speicherauslastung für die Optimierung der AD DS-Leistung

In diesem Artikel werden einige Grundlagen des Subsystemdiensts für die lokale Sicherheitsautorität (Local Security Authority Subsystem Service, LSASS, auch als „Lsass.exe“-Prozess bezeichnet), bewährte Methoden für die Konfiguration von LSASS und Erwartungen hinsichtlich der Speicherauslastung beschrieben. Dieser Artikel sollte als Leitfaden für die Analyse der Leistung und Speicherauslastung von LSASS auf Domänencontrollern (DCs) verwendet werden. Die Informationen in diesem Artikel können hilfreich sein, wenn Sie Fragen zum Optimieren und Konfigurieren von Servern und DCs haben, um diese Engine zu optimieren.

LSASS ist für die Verwaltung der Domänenauthentifizierung der lokalen Sicherheitsautorität (Local Security Authority, LSA) und der Active Directory-Verwaltung verantwortlich. LSASS verarbeitet die Authentifizierung sowohl für den Client als auch für den Server und regelt außerdem die Active Directory-Engine. LSASS ist für die folgenden Komponenten verantwortlich:

• Lokale Sicherheitsautorität
• Anmeldedienst (NetLogon)
• Sicherheitskonto-Manager-Dienst (Security Accounts Manager, SAM)
• LSA-Serverdienst
• Secure Sockets Layer (SSL)
• Kerberos v5-Authentifizierungsprotokoll
• NTLM-Authentifizierungsprotokoll
• Andere Authentifizierungspakete, die in LSA geladen werden

Die Active Directory-Datenbankdienste (NTDSAI.dll) funktionieren mit der Extensible Storage Engine (ESE, ESENT.dll).

Hier sehen Sie ein visuelles Diagramm der LSASS-Speicherauslastung auf einem DC:

Die Arbeitsspeichermenge, die LSASS für einen DC verwendet, steigt entsprechend der Active Directory-Nutzung. Wenn Daten abgerufen werden, werden sie im Arbeitsspeicher zwischengespeichert. Daher ist es normal, dass LSASS eine Menge an Arbeitsspeicher verwendet, die größer ist als die Größe der Active Directory-Datenbankdatei (NTDS.dit).

Wie im Diagramm dargestellt, lässt sich die LSASS-Speicherauslastung in mehrere Teile unterteilen, einschließlich des ESE-Datenbankpuffercaches, des ESE-Versionsspeichers und anderer. Der Rest dieses Artikels vermittelt Ihnen Erkenntnisse zu jedem dieser Teile.

ESE-Datenbankpuffercache

Die größte variable Speicherauslastung innerhalb von LSASS ist der ESE-Datenbankpuffercache. Die Größe des Caches kann zwischen weniger als 1 MB und der Größe der gesamten Datenbank liegen. Da ein größerer Cache die Leistung verbessert, versucht die Datenbank-Engine für Active Directory (ESENT), den Cache so groß wie möglich zu halten. Während die Größe des Caches mit der Arbeitsspeicherauslastung auf dem Computer variiert, wird die maximale Größe des ESE-Datenbankpuffercaches nur durch den physischen RAM begrenzt, der auf dem Computer installiert ist. Solange keine andere Arbeitsspeicherauslastung vorhanden ist, kann der Cache auf die Größe der Active Directory-Datenbankdatei „NTDS.dit“ anwachsen. Je mehr von der Datenbank zwischengespeichert werden kann, desto besser ist die Leistung des DC.

ESE-Versionsspeicher

Die Speicherauslastung durch den ESE-Versionsspeicher variiert (der rote Teil im obigen Diagramm). Die Menge des verwendeten Arbeitsspeichers hängt davon ab, ob Sie über Windows Server 2019 oder ältere Versionen von Windows verfügen.

• In älteren Windows Server-Versionen als Windows Server 2019 kann LSASS standardmäßig bis zu 400 MB Arbeitsspeicher (abhängig von der Anzahl der CPUs) auf einem 64-Bit-Computer für den ESE-Versionsspeicher verwenden. Weitere Informationen zur Verwendung des Versionsspeichers finden Sie im folgenden ASKDS-Blogbeitrag von Ryan Ries: The Version Store Called and They're All Out of Buckets.

• In Windows Server 2019 ist dies vereinfacht, und wenn der NTDS-Dienst zum ersten Mal gestartet wird, wird die ESE-Versionsspeichergröße jetzt mit 10 % des physischen RAM berechnet, mit mindestens 400 MB und maximal 4 GB. Ausführliche Informationen hierzu und zur Problembehandlung für den Versionsspeicher finden Sie in einem weiteren großartigen Blog von Ryan Ries: Deep Dive: Active Directory ESE Version Store Changes in Server 2019.

Sonstige Speicherverwendung

Schließlich gibt es Code, Stapel, Heaps und verschiedene Datenstrukturen mit fester Größe (z. B. den Schemacache). Die Menge des von LSASS verwendeten Arbeitsspeichers kann je nach Auslastung des Computers variieren. Mit steigender Anzahl ausgeführter Threads wächst auch die Anzahl der Speicherstapel. Im Durchschnitt benötigt LSASS 100 MB bis 300 MB Arbeitsspeicher für diese festen Komponenten. Wenn eine größere Menge an RAM installiert ist, kann LSASS mehr RAM und weniger virtuellen Arbeitsspeicher verwenden.

Beschränken oder minimieren Sie die Anzahl von Programmen auf Ihrem Domänencontroller, ODER fügen Sie ggf. zusätzlichen RAM hinzu.

Um eine optimale Leistung zu erzielen, verwendet LSASS so viel RAM wie möglich auf einem bestimmten DC. LSASS gibt diesen RAM frei, wenn andere Prozesse ihn anfordern. Die Idee dahinter ist, die Leistung von LSASS zu optimieren und gleichzeitig andere Prozesse zu berücksichtigen, die möglicherweise auf einem Computer ausgeführt werden. Die Liste der zu beachtenden Programme umfasst Überwachungs-Agents. Einige Kunden verfügen über separate Agents für verschiedene Serverfunktionen, die erhebliche RAM-Ressourcen verbrauchen können. Einige senden möglicherweise viele WMI-Abfragen, für die wir unten einige Details bereitstellen.

Aus diesem Grund und zur Steigerung der Leistung ist es eine bewährte Praxis, die Anzahl der Programme auf einem DC zu begrenzen oder zu minimieren. Wenn keine Speicheranforderungen vorliegen, verwendet LSASS diesen Arbeitsspeicher, um die Active Directory-Datenbank zwischenzuspeichern und somit eine optimale Leistung zu erzielen.

Wenn Sie feststellen, dass ein DC Leistungsprobleme hat, achten Sie auch auf Prozesse mit erheblicher Speicherauslastung. Möglicherweise haben diese ein Problem, das Sie beheben müssen. Es können Microsoft-Komponenten beteiligt sein. Stellen Sie sicher, dass Sie bei den neuesten Wartungsupdates auf dem Laufenden bleiben. Microsoft nimmt Lösungen für übermäßige Speicherauslastung als Teil der Qualitätsupdates auf, die auch die Leistung Ihres DC verbessern können.

Es gibt integrierte Betriebssystemeinrichtungen, die je nach Nutzungsprofil erheblich RAM verbrauchen können:

• Dateiserver. DCs sind auch Dateiserver für SYSVOL- und Netlogon-Freigaben, Wartungsgruppenrichtlinien und Skripts für Richtlinien und Start-/Anmeldeskripts. Wir stellen jedoch fest, dass Kunden DCs verwenden, um andere Dateiinhalte zu verwalten. Der SMB-Dateiserver würde dann RAM nutzen, um die aktiven Clients nachzuverfolgen, aber in erster Linie würde der Dateiinhalt den Betriebssystem-Dateicache anwachsen lassen und mit dem ESE-Datenbankcache um RAM konkurrieren.

• WMI-Abfragen. Überwachungslösungen senden häufig viele WMI-Abfragen. Die Ausführung einer einzelnen Abfrage kann kostengünstig sein. Häufig ist es die Menge Aufrufe, die einen gewissen Mehraufwand verursacht, insbesondere wenn die Überwachungslösungen neue Ereignisse aus den verschiedenen Ereignisprotokollen extrahieren, die von Windows verwaltet werden.

  Das Ereignisprotokoll, das den größten Umfang erzeugt, ist in der Regel das Sicherheitsereignisprotokoll. Dies ist auch das Ereignisprotokoll, das Sicherheitsadministratoren sammeln möchten, insbesondere von DCs.

  Der WMI-Dienst verwendet ein dynamisches Speicherzuordnungsschema, das Abfragen optimiert. Daher kann der WMI-Dienst viel Arbeitsspeicher zuordnen, was wiederum mit dem ESE-Datenbankcache konkurriert.