Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Important
Följande är en sammanfattning av de viktigaste rekommendationerna och övervägandena för att optimera servermaskinvaran för Active Directory-arbetsbelastningar som beskrivs mer ingående i artikeln Kapacitetsplanering för Active Directory Domain Services . Läsare uppmanas starkt att granska kapacitetsplanering för Active Directory Domain Services för att få en bättre teknisk förståelse och konsekvenser av dessa rekommendationer.
Undvik att gå till disken
Active Directory cachelagrar så mycket av databasen som minne tillåter. Att hämta sidor från minnet är storleksordningar snabbare än att gå till fysiska medier, oavsett om mediet är spindle- eller SSD-baserat. Lägg till mer minne för att minimera disk-I/O.
Bästa praxis för Active Directory rekommenderar att du lägger tillräckligt med RAM-minne för att läsa in hela DIT i minnet, plus hantera operativsystemet och andra installerade program, till exempel antivirusprogram, säkerhetskopieringsprogram, övervakning och så vidare.
Begränsningar för äldre plattformar finns i Minnesanvändning av Lsass.exe process på domänkontrollanter som kör Windows Server 2003 eller Windows 2000 Server.
Använd prestandaräknaren Memory\Long-Term Average Standby Cache Lifetime (s) > med en varaktighet på 30 minuter.
Placera operativsystemet, loggarna och databasen på separata volymer. Om hela eller majoriteten av DIT kan cachelagras, när cachen har värmts upp och är i stabilt tillstånd, blir detta mindre relevant och ger lite mer flexibilitet i lagringslayouten. I scenarier där hela DIT inte kan cachelagras blir vikten av att dela upp operativsystemet, loggarna och databasen på separata volymer viktigare.
Normalt är I/O-förhållandet till DIT cirka 90% läs- och 10% skrivning. Scenarier där skriv-I/O-volymer avsevärt överstiger 10% – 20% anses vara skrivintensiva. Skrivintensiva scenarier drar inte stor nytta av Active Directory-cachen. För att garantera transaktionshållbarheten för data som skrivs till katalogen använder Active Directory inte diskcache för skrivning. I stället skriver den alla skrivåtgärder till disken innan den returnerar en lyckad slutförandestatus för en åtgärd, såvida det inte finns en uttrycklig begäran om att inte göra detta. Därför är snabb disk-I/O viktigt för prestanda för skrivåtgärder till Active Directory. Följande är maskinvarurekommendationer som kan förbättra prestanda för dessa scenarier:
RAID-maskinvarustyrenheter
Öka antalet diskar med låg latens/hög RPM som är värd för DIT- och loggfilerna
Skriva cachelagring på kontrollanten
Granska diskundersystemprestanda individuellt för varje volym. De flesta Active Directory-scenarier är främst läsbaserade, och därför är statistiken på volymen som är värd för DIT den viktigaste att inspektera. Glöm dock inte att övervaka resten av enheterna, inklusive operativsystemet och loggfilsenheterna. För att avgöra om domänkontrollanten är korrekt konfigurerad för att undvika att lagring är flaskhalsen för prestanda, refererar du till avsnittet om lagringsundersystem för standardlagringsrekommendationer. I många miljöer är filosofin att se till att det finns tillräckligt med huvudutrymme för att rymma ökningar eller toppar i belastningen. Dessa tröskelvärden är varningströsklar där utrymmet för att hantera toppar eller spikar i belastningen blir begränsat och klientens respons försämras. Sammanfattningsvis är det inte skadligt att överskrida dessa tröskelvärden på kort sikt (5 till 15 minuter några gånger om dagen), men ett system som körs med denna typ av statistik cachelagrar inte databasen helt och kan vara överbelastat och bör undersökas.
Databas ==> Instanser(lsass/NTDSA)\I/O Databasläsningar Genomsnittlig Latens < 15ms
Databas ==> Instanser(lsass/NTDSA)\I/O databasläsningar/sek < 10
Databas ==> Instanser(lsass/NTDSA)\I/O Loggskrivningar Genomsnittlig svarstid < 10ms
Database ==> Instances(lsass/NTDSA)\I/O Log Writes/sec – endast information.
För att upprätthålla datakonsekvensen måste alla ändringar skrivas till loggen. Det finns inget bra eller dåligt antal här, det är bara ett mått på hur mycket lagringen stöder.
Planera icke-kärndisk-I/O-belastningar, till exempel säkerhetskopiering och antivirusgenomsökningar, för belastningsperioder som inte är hög. Använd även säkerhetskopierings- och antiviruslösningar som stöder den lågprioriterad I/O-funktion som introducerades i Windows Server 2008 för att minska konkurrensen med I/O-behoven i Active Directory.
Överbeskatta inte processorerna
Processorer som inte har tillräckligt med lediga cykler kan orsaka långa väntetider för att köra trådar på processorn. I många miljöer är filosofin att säkerställa att det finns tillräckligt med marginal för att hantera toppar i belastningen och minimera påverkan på klientens responsivitet i dessa scenarier. Kort uttryckt är det inte dåligt att överskrida tröskelvärdena nedan på kort sikt (5 till 15 minuter några gånger om dagen), men ett system som körs med den här typen av statistik ger inget huvudutrymme för onormala belastningar och kan enkelt placeras i ett överbeskattat scenario. System som spenderar varaktiga perioder över tröskelvärdena bör undersökas för hur processorbelastningen ska minskas.
Mer information om hur du väljer en processor finns i Prestandajustering för servermaskinvara.
Lägg till maskinvara, optimera belastningen, dirigera klienter någon annanstans eller ta bort belastningen från miljön för att minska CPU-belastningen.
Använd processorinformation(_Total)\% processoranvändning < 60% prestandaräknare.
Undvik att överbelasta nätverkskortet
Precis som med processorer orsakar överdriven användning av nätverkskort långa väntetider för att den utgående trafiken ska komma igång till nätverket. Active Directory tenderar att ha små inkommande begäranden och relativt till betydligt större mängder data som returneras till klientsystemen. Skickade data överstiger märkbart mottagna data. I många miljöer är filosofin att se till att det finns tillräckligt med huvudutrymme för att rymma ökningar eller toppar i belastningen. Det här tröskelvärdet är ett varningströskelvärde där huvudutrymmet för att hantera ökningar eller toppar i belastningen blir begränsat och klientens svarstider försämras. Kort sagt är det inte dåligt att överskrida dessa tröskelvärden i det korta loppet (5 till 15 minuter några gånger om dagen), men ett system som körs kontinuerligt med den här typen av statistik är överbelastat och bör undersökas.
Mer information om hur du finjusterar nätverksundersystemet finns i Prestandajustering för nätverksundersystem.
Använd prestandaräknaren Jämför NetworkInterface(*)\Bytes Sent/Sec med NetworkInterface(*)\Nuvarande Bandbredd. Förhållandet bör vara mindre än 60% använt.