Minnesanvändningsöverväganden för AD DS-prestandajustering

I den här artikeln beskrivs några grunderna i LSASS (Local Security Authority Subsystem Service Lsass.exe), metodtips för konfiguration av LSASS och förväntningar på minnesanvändning. Den här artikeln bör användas som en guide i analysen av LSASS-prestanda och minnesanvändning på domänkontrollanter (DCs). Informationen i den här artikeln kan vara användbar om du har frågor om hur du finjusterar och konfigurerar servrar och domänkontrollanter för att optimera denna motor.

LSASS ansvarar för hanteringen av domänautentisering för lokala säkerhetsauktoriseringar (LSA) och Active Directory-hantering. LSASS hanterar autentisering för både klienten och servern, och det styr även Active Directory-motorn. LSASS ansvarar för följande komponenter:

• Lokal säkerhetsmyndighet
• NetLogon-tjänsten
• Sam-tjänsten (Security Accounts Manager)
• LSA Server-tjänsten
• SSL (Secure Sockets Layer)
• Kerberos v5-autentiseringsprotokoll
• NTLM-autentiseringsprotokoll
• Andra autentiseringspaket som läses in i LSA

Active Directory-databastjänsterna (NTDSAI.dll) fungerar med Extensible Storage Engine (ESE, ESENT.dll).

Här är en grafisk representation över LSASS-memoriesutnyttjande på en domänkontrollant.

Mängden av minne som LSASS använder på en domänkontrollant ökar i takt med Active Directory-användningen. När data efterfrågas cachelagras de i minnet. Därför är det normalt att se LSASS med en mängd minne som är större än storleken på Active Directory-databasfilen (NTDS.dit).

Som illustreras i diagrammet kan LSASS-minnesanvändning delas in i flera delar, inklusive ESE-databasbuffertcachen, ESE-versionsarkivet och andra. Resten av den här artikeln ger insikter om var och en av dessa delar.

ESE-databas-buffert-cache

Den största variabelminnesanvändningen i LSASS är ESE-databasbuffertcachen. Cachens storlek kan variera från mindre än 1 MB till storleken på hela databasen. Eftersom en större cache förbättrar prestandan försöker databasmotorn för Active Directory (ESENT) hålla cachen så stor som möjligt. Cachens storlek varierar med minnesbelastningen i datorn, men den maximala storleken på ESE-databasbuffertcachen begränsas endast av fysiskt RAM-minne som är installerat på datorn. Så länge det inte finns något annat minnestryck kan cacheminnet växa till storleken på Active Directory NTDS.dit-databasfilen. Ju mer av databasen som kan sparas i cache, desto bättre blir prestanda för DC:n.

ESE-versionsarkiv

Det finns variabelt minnesutnyttjande för ESE versionslagringsplatsen (den röda delen i diagrammet ovan). Mängden minne som används beror på om du har Windows Server 2019 eller äldre versioner av Windows.

• I Windows Server-versioner som företablerar Windows Server 2019 kan LSASS som standard använda upp till cirka 400 MB minne (beroende på antalet processorer) på en 64-bitars dator för ESE-versionsarkivet. Mer information om hur versionsarkivet används finns i följande ASKDS-blogginlägg av Ryan Ries: Version Store Called and They're All Out of Buckets ( Versionsarkivet anropas och de är helt slut på bucketar).

• I Windows Server 2019 är detta förenklat och när NTDS-tjänsten startar först beräknas ESE-versionsarkivets storlek nu som 10% fysiskt RAM-minne, med minst 400 MB och högst 4 GB. Mer information om felsökning av detta och versionsarkiv finns i en annan bra blogg från Ryan Ries: Deep Dive: Active Directory ESE Version Store Changes in Server 2019.

Annan minnesanvändning

Slutligen finns det kod, staplar, heaps och olika datastrukturer med fast storlek (till exempel schemacachen). Mängden minne som LSASS använder kan variera beroende på belastningen på datorn. I takt med att antalet trådar som körs ökar ökar även antalet minnesstackar. I genomsnitt använder LSASS 100 MB till 300 MB minne för dessa fasta komponenter. När en större mängd RAM-minne har installerats kan LSASS använda mer RAM-minne och mindre virtuellt minne.

Begränsa eller minimera antalet program på domänkontrollanten eller lägg till ytterligare RAM-minne där det är lämpligt

För optimal prestanda tar LSASS så mycket RAM-minne som möjligt på en specifik domänkontrollant. LSASS avstår från ram-minnet när andra processer ber om det. Tanken är att optimera prestanda för LSASS samtidigt som man redovisar andra processer som kan köras på en dator. Listan över program att se upp för innehåller övervakningsagenter. Vissa kunder har separata agenter för olika serverfunktioner som kan använda stora RAM-resurser. Vissa kan utfärda många WMI-frågor, för vilka vi har några detaljer nedan.

På grund av detta och för att öka prestandan är det en bra idé att begränsa eller minimera antalet program på en domänkontrollant. Om det inte finns några minnesbegäranden använder LSASS det här minnet för att cachelagras i Active Directory-databasen och får därför optimala prestanda.

När du märker att en domänkontrollant har prestandaproblem kan du även titta efter processer med betydande minnesanvändning. Dessa kan ha ett problem som du behöver felsöka. De kan innehålla Microsoft-komponenter. Se till att du håller jämna steg med de senaste underhållsuppdateringarna – Microsoft innehåller lösningar för överdriven minnesanvändning som en del av kvalitetsuppdateringarna, vilket också kan hjälpa din DC-prestanda.

Det finns inbyggda operativsystemanläggningar som kan använda betydande RAM-minne beroende på användningsprofilen:

• Filserver. Domänkontrollanter är också filservrar för SYSVOL- och Netlogon-resurser, underhåll av grupprinciper och skript för princip- och start-/inloggningsskript. Vi ser dock att kunder använder domänkontrollanter för att hantera annat filinnehåll. SMB-filservern skulle sedan använda RAM-minne för att spåra aktiva klienter, men först och främst skulle filinnehållet få OS-filcachen att växa och konkurrera med ESE-databascachen för RAM.

• WMI-frågor. Övervakningslösningar gör ofta många WMI-frågor. En enskild fråga kan vara billig att köra. Ofta är det mängden anrop som medför vissa kostnader, särskilt som övervakningslösningarna extraherar nya händelser från de olika händelseloggarna som Windows hanterar.

  Händelseloggen som producerar mest volym är vanligtvis säkerhetshändelseloggen. Och det här är också händelseloggen som säkerhetsadministratörer vill samla in, särskilt från domänkontrollanter.

  WMI-tjänsten använder ett dynamiskt minnesallokeringsschema som optimerar frågor. Därför kan WMI-tjänsten allokera mycket minne och återigen konkurrera med ESE-databascachen.