Freigeben über


Überlegungen zur Speicherauslastung bei der Leistungsoptimierung von AD DS

In diesem Artikel werden einige Grundlagen des Subsystemdiensts für lokale Sicherheitsstellen (LSASS, auch als Lsass.exe Prozess bezeichnet), bewährte Methoden für die Konfiguration von LSASS und die Erwartungen an die Speicherauslastung beschrieben. Dieser Artikel sollte als Leitfaden für die Analyse der LSASS-Leistung und der Speichernutzung auf DOmänencontrollern (DCs) verwendet werden. Die Informationen in diesem Artikel können hilfreich sein, wenn Sie Fragen dazu haben, wie Sie Server und DCs abstimmen und konfigurieren können, um diese Engine zu optimieren.

LSASS ist für die Verwaltung der LSA-Domänenauthentifizierung (Local Security Authority) und der Active Directory-Verwaltung verantwortlich. LSASS behandelt die Authentifizierung sowohl für den Client als auch für den Server, und es steuert auch das Active Directory-Modul. LSASS ist für die folgenden Komponenten verantwortlich:

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

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

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

Diagramm der Komponenten, die den LSASS-Speicher verwenden

Die Speichermenge, die LSASS auf einem DC verwendet, erhöht sich entsprechend der Active Directory-Nutzung. Wenn Daten abgefragt werden, wird sie im Arbeitsspeicher zwischengespeichert. Daher ist es normal, LSASS unter Verwendung eines Arbeitsspeichers anzuzeigen, der größer als die Größe der Active Directory-Datenbankdatei (NTDS.dit) ist.

Wie im Diagramm dargestellt, kann die LSASS-Speicherauslastung in mehrere Teile unterteilt werden, einschließlich des ESE-Datenbankpuffercaches, des ESE-Versionsspeichers und anderer. Der Rest dieses Artikels enthält Einblicke in jeden dieser Teile.

ESE-Datenbankpufferpool

Die größte variable Speichernutzung 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 das Datenbankmodul für Active Directory (ESENT), den Cache so groß wie möglich zu halten. Während die Größe des Caches mit dem Arbeitsspeicherdruck auf dem Computer variiert, ist die maximale Größe des ESE-Datenbankpuffercaches nur durch den physischen RAM begrenzt, der auf dem Computer installiert ist. Solange kein anderer Arbeitsspeicherdruck besteht, kann der Cache auf die Größe der Active Directory NTDS.dit-Datenbankdatei wachsen. Je mehr datenbank zwischengespeichert werden kann, desto besser ist die Leistung des DC.

Note

Aufgrund der Funktionsweise des Datenbankzwischenspeicherungsalgorithmus kann der Datenbankcache auf einem 64-Bit-System, auf dem die Datenbankgröße kleiner als der verfügbare RAM ist, größer werden als die Datenbankgröße um 30 bis 40 Prozent.

ESE-Versionsspeicher

Es gibt eine variable Speicherauslastung durch den ESE-Versionsspeicher (der rote Teil im obigen Diagramm). Die verwendete Arbeitsspeichermenge hängt davon ab, ob Sie über Windows Server 2019 oder ältere Versionen von Windows verfügen.

  • In Windows Server-Versionen vor Windows Server 2019 dürfte LSASS standardmäßig bis zu 400 MB Arbeitsspeicher (abhängig von der Anzahl der CPUs) auf einer 64-Bit-Maschine für den ESE-Versionsspeicher verwenden. Weitere Informationen dazu, wie der Versionsspeicher verwendet wird, finden Sie im folgenden ASKDS-Blogbeitrag von Ryan Ries: The Version Store Called and They're All Out of Buckets.

  • In Windows Server 2019 wird dies vereinfacht und wenn der NTDS-Dienst zum ersten Mal gestartet wird, wird die ESE-Versionsspeichergröße jetzt als 10% physischen RAM berechnet, mit mindestens 400 MB und maximal 4 GB. Umfassende Einzelheiten hierzu und zur Fehlerbehebung des Versionsspeichers finden Sie in einem weiteren hervorragenden Blog von Ryan Ries: Deep Dive: Änderungen am Active Directory ESE-Versionsspeicher in Server 2019.

Andere Speicherverwendung

Schließlich gibt es Code, Stapel, Heaps und verschiedene Datenstrukturen mit fester Größe (z. B. den Schemacache). Die Arbeitsspeichermenge, die LSASS verwendet, kann je nach Auslastung auf dem Computer variieren. Mit zunehmender Anzahl der ausgeführten Threads erhöht sich auch die Anzahl der Speicherstapel. LSASS verwendet durchschnittlich 100 MB bis 300 MB Arbeitsspeicher für diese festen Komponenten. Wenn eine größere Menge RAM installiert ist, kann LSASS mehr RAM und weniger virtuellen Arbeitsspeicher verwenden.

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

Für eine optimale Leistung benötigt LSASS so viel RAM wie möglich auf einem bestimmten DC. LSASS gibt den RAM frei, wenn andere Prozesse danach fragen. Die Idee besteht darin, die Leistung von LSASS zu optimieren und gleichzeitig andere Prozesse zu berücksichtigen, die auf einem Computer ausgeführt werden können. 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 stellen möglicherweise viele WMI-Abfragen aus, für die wir unten einige Details haben.

Aus diesem Grund und zur Steigerung der Leistung empfiehlt es sich, die Anzahl der Programme auf einem DC zu begrenzen oder zu minimieren. Wenn keine Speicheranforderungen vorhanden sind, verwendet LSASS diesen Speicher, 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. Dies kann ein Problem haben, das Sie beheben müssen. Sie können Microsoft-Komponenten enthalten. Stellen Sie sicher, dass Sie mit den neuesten Wartungsupdates auf dem Laufenden bleiben – Microsoft enthält Lösungen für eine übermäßige Speicherauslastung als Teil der Qualitätsupdates, was auch zu Ihrer DC-Leistung beitragen kann.

Es gibt integrierte Betriebssystemeinrichtungen, die je nach Nutzungsprofil erhebliche 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 sehen jedoch, dass Kunden DCs verwenden, um andere Dateiinhalte zu bedienen. Der SMB-Dateiserver würde dann RAM verbrauchen, um die aktiven Clients nachzuverfolgen, aber in erster Linie würde der Dateiinhalt den Betriebssystemdateicache vergrößern und mit dem ESE-Datenbankcache für RAM konkurrieren.

  • WMI-Abfragen. Überwachungslösungen machen häufig viele WMI-Abfragen. Eine einzelne Abfrage kann billig ausgeführt werden. Häufig handelt es sich um das Volumen von Aufrufen, die mehr Aufwand verursachen, insbesondere, wenn die Überwachungslösungen neue Ereignisse aus den verschiedenen Ereignisprotokollen extrahieren, die Windows verwaltet.

    Das Ereignisprotokoll, das das größte Volume erzeugt, ist in der Regel das Sicherheitsereignisprotokoll. Und dies ist auch das Ereignisprotokoll, das Sicherheitsadministratoren sammeln möchten, insbesondere von DCs.

    Der WMI-Dienst verwendet ein dynamisches Speicherzuweisungsschema, das Abfragen optimiert. Daher kann der WMI-Dienst viel Arbeitsspeicher zuweisen, wobei er erneut mit dem ESE-Datenbankcache konkurrieren kann.