Overwegingen voor geheugengebruik voor het afstemmen van AD DS-prestaties

In dit artikel worden enkele basisbeginselen van de LSASS (Local Security Authority Subsystem Service, ook wel het Lsass.exe-proces genoemd), aanbevolen procedures voor de configuratie van LSASS en verwachtingen voor geheugengebruik beschreven. Dit artikel moet worden gebruikt als richtlijn bij de analyse van LSASS-prestaties en geheugengebruik op domeincontrollers (DC's). De informatie in dit artikel kan nuttig zijn als u vragen hebt over het afstemmen en configureren van servers en DC's om deze engine te optimaliseren.

LSASS is verantwoordelijk voor het beheer van LSA-domeinverificatie (Local Security Authority) en Active Directory-beheer. LSASS verwerkt verificatie voor zowel de client als de server, en beheert ook de Active Directory-engine. LSASS is verantwoordelijk voor de volgende onderdelen:

• Lokale beveiligingsautoriteit
• NetLogon-service
• SAM-service (Security Accounts Manager)
• LSA-serverservice
• Secure Sockets Layer (SSL)
• Kerberos v5-verificatieprotocol
• NTLM-verificatieprotocol
• Andere verificatiepakketten die in LSA worden geladen

De Active Directory-databaseservices (NTDSAI.dll) werken met de Extensible Storage Engine (ESE, ESENT.dll).

Hier volgt een visueel diagram van het LSASS-geheugengebruik op een DC:

De hoeveelheid geheugen die LSASS op een DC gebruikt, neemt toe in overeenstemming met het Active Directory-gebruik. Wanneer gegevens worden opgevraagd, worden deze in de cache opgeslagen in het geheugen. Als gevolg hiervan is het normaal om LSASS te zien met behulp van een hoeveelheid geheugen die groter is dan de grootte van het Active Directory-databasebestand (NTDS.dit).

Zoals u in het diagram kunt zien, kan het geheugengebruik van LSASS worden onderverdeeld in verschillende onderdelen, waaronder de cache van de ESE-databasebuffer, het ESE-versiearchief en andere. De rest van dit artikel biedt inzicht in elk van deze onderdelen.

ESE-databasebuffercache

Het grootste variabele geheugengebruik in LSASS is de ESE-databasebuffercache. De grootte van de cache kan variëren van minder dan 1 MB tot de grootte van de hele database. Omdat een grotere cache de prestaties verbetert, probeert de database-engine voor Active Directory (ESENT) de cache zo groot mogelijk te houden. Hoewel de grootte van de cache varieert met geheugendruk op de computer, wordt de maximale grootte van de ESE-databasebuffercache alleen beperkt door fysiek RAM-geheugen dat op de computer is geïnstalleerd. Zolang er geen andere geheugenbelasting is, kan de cache toenemen tot de grootte van het Active Directory NTDS.dit-databasebestand. Hoe meer van de database in de cache kan worden opgeslagen, hoe beter de prestaties van de domeincontroller zijn.

ESE-versieopslag

Er is variabel geheugengebruik door de ESE-versiestore (het rode deel in het bovenstaande diagram). De hoeveelheid geheugen die wordt gebruikt, is afhankelijk van of u Windows Server 2019 of oudere versies van Windows hebt.

• In Windows Server-versies vóór Windows Server 2019 kan LSASS standaard ongeveer 400 MB geheugen gebruiken (afhankelijk van het aantal CPU's) op een 64-bits computer voor het ESE-versiearchief. Zie de volgende ASKDS-blogpost van Ryan Ries: The Version Store Called and They're All Out of Buckets voor meer informatie over hoe het versiearchief wordt gebruikt.

• In Windows Server 2019 is dit vereenvoudigd en wanneer de NTDS-service voor het eerst wordt gestart, wordt de grootte van het ESE-versiearchief nu berekend als 10% fysieke RAM, met minimaal 400 MB en maximaal 4 GB. Zie een andere geweldige blog van Ryan Ries: Deep Dive: Active Directory ESE Version Store Changes in Server 2019 voor meer informatie over dit probleem en het oplossen van problemen met de versieopslag.

Ander geheugengebruik

Ten slotte zijn er code, stacks, heaps en verschillende gegevensstructuren met een vaste grootte (bijvoorbeeld de schemacache). De hoeveelheid geheugen die door LSASS wordt gebruikt, kan variëren, afhankelijk van de belasting van de computer. Naarmate het aantal actieve threads toeneemt, wordt ook het aantal geheugenstacks verhoogd. LSASS gebruikt gemiddeld 100 MB tot 300 MB geheugen voor deze vaste onderdelen. Wanneer een grotere hoeveelheid RAM is geïnstalleerd, kan LSASS meer RAM en minder virtueel geheugen gebruiken.

Beperk of minimaliseer het aantal programma's op uw domeincontroller OF voeg waar nodig extra RAM-geheugen toe

Voor optimale prestaties neemt LSASS zoveel mogelijk RAM-geheugen op een bepaalde DC. LSASS geeft dat RAM-geheugen vrij als andere processen ernaar vragen. Het idee is om de prestaties van LSASS te optimaliseren terwijl nog steeds rekening wordt houdt met andere processen die op een computer kunnen worden uitgevoerd. De lijst met programma's waarvoor u moet letten, omvat bewakingsagents. Sommige klanten hebben afzonderlijke agents voor verschillende serverfuncties die aanzienlijke RAM-resources kunnen verbruiken. Sommige kunnen veel WMI-query's uitgeven, waarvoor we hieronder enkele details hebben.

Als gevolg hiervan en om de prestaties te verbeteren, is het een goede gewoonte om het aantal programma's op een DC te beperken of te minimaliseren. Als er geen geheugenaanvragen zijn, gebruikt LSASS dit geheugen om de Active Directory-database in de cache te plaatsen en daarom optimale prestaties te behalen.

Wanneer u merkt dat een DC prestatieproblemen heeft, moet u ook letten op processen met aanzienlijk geheugengebruik. Dit kan een probleem hebben dat u moet oplossen. Ze kunnen Microsoft-onderdelen bevatten. Zorg ervoor dat u op de hoogte blijft van recente onderhoudsupdates. Microsoft bevat oplossingen voor overmatig geheugengebruik als onderdeel van de kwaliteitsupdates, die ook uw DC-prestaties kunnen helpen.

Er zijn ingebouwde besturingssysteemfaciliteiten die aanzienlijk RAM-geheugen kunnen verbruiken, afhankelijk van het gebruiksprofiel:

• Bestandsserver. DC's zijn ook bestandsservers voor SYSVOL- en Netlogon-shares, die groepsbeleid en scripts voor beleidsuitvoering en opstart-/aanmeldingsscripts bedienen. We zien echter dat klanten DC's gebruiken om andere bestandsinhoud te onderhouden. De SMB-bestandsserver zou vervolgens RAM verbruiken om de actieve clients bij te houden, maar vooral de bestandsinhoud zou de bestandscache van het besturingssysteem laten groeien en concurreren met de ESE-databasecache voor RAM.

• WMI-query's. Bewakingsoplossingen maken vaak veel WMI-query's. Een afzonderlijke query kan goedkoop zijn om uit te voeren. Vaak is het het volume aan aanroepen dat enige overhead met zich meebrengt, met name omdat de bewakingsoplossingen nieuwe gebeurtenissen extraheren uit de verschillende gebeurtenislogboeken die door Windows worden beheerd.

  Het gebeurtenislogboek dat het meeste volume produceert, is doorgaans het gebeurtenislogboek van de beveiliging. En dit is ook het gebeurtenislogboek dat beveiligingsbeheerders willen verzamelen, met name van DC's.

  De WMI-service maakt gebruik van een dynamisch toewijzingsschema voor geheugen waarmee query's worden geoptimaliseerd. Daarom kan de WMI-service veel geheugen toewijzen, opnieuw concurreren met de ESE-databasecache.