Vanliga frågor och svar om Configuration Manager webbplatsstorlek och prestanda

Avgränsa Configuration Manager inkorgar och SQL Server filer på minst två olika volymer. Med den här separationen kan du optimera klusterallokeringsstorlekar för de olika typer av I/O som de utför.

Använd NTFS med 4K- eller 8K-allokeringsenheter för den volym som är värd för dina platsserverinkorgar. ReFS skriver 64k även för små filer. Configuration Manager har många små filer, så ReFS kan generera onödiga diskkostnader.

För diskar som innehåller SQL Server databasfiler använder du antingen NTFS- eller ReFS-formatering, med 64 000 allokeringsenheter.

Moderna matriser med SSD-enheter (Solid State Drives) och Azure Premium Storage kan ge hög IOPS på en enda volym, med få diskar. Du lägger vanligtvis till fler enheter i en matris för ytterligare lagring, inte ytterligare dataflöde. Om du använder fysiska spindelbaserade diskar kan du behöva mer IOPS än du kan generera på en enda volym. Du bör allokera 60 % av det totala rekommenderade IOPS- och diskutrymmet för .mdf-filen , 20 % för .ldf-filen och 20 % för logg- och data temp-filerna. .ldf- och temp-filerna kan alla finnas på en enda volym med 40 % (20 % + 20 %) av din allokerade IOPS.

SQL Server tidigare versioner än SQL Server 2016 skapades som standard endast en temporär datafil. Du bör skapa fler för att undvika SQL Server lås och vänta på åtkomst till en enda fil. Communityns åsikter varierar beroende på det bästa antalet temporära datafiler som ska skapas, från fyra till åtta. Testning visar liten skillnad mellan fyra och åtta, så du kan skapa fyra lika stora temporära datafiler. Tempdb-datafilerna bör vara upp till 20–25 % av storleken på din fullständiga databas.

När det går att konfigurera ställer du in RAID-styrenhetens minne på 70 % allokering för skrivåtgärder och 30 % för läsåtgärder. I allmänhet använder du en RAID 10-matriskonfiguration för platsdatabasen. RAID 1 är också acceptabelt för småskaliga platser med låga I/O-krav, eller om du använder snabba SSD:er. Med större diskmatriser konfigurerar du reservdiskar så att de automatiskt ersätter felande diskar.

Exempel: Fysisk dator med fysiska diskar

Storleksriktlinjerna för en samlokaliserad platsserver och SQL Server med 100 000 klienter är 1 200 IOPS för platsserverns inkorgar och 5 000 IOPS för SQL Server filer.

Den resulterande diskkonfigurationen kan se ut så här:

1. Innehåller inte rekommenderade reservdiskar.
2. Det här värdet kommer från Exempel på diskkonfigurationer.

Hyper-V ger liknande prestanda som en fysisk server, om maskinvaruresurser (CPU-kärnor och direktlagring) är 100 % dedikerade till den virtuella datorn (VM). Om du använder .vhd- eller .vhdx-diskfiler med fast storlek får du en minimal I/O-prestandapåverkan på 1–5 %. Om du använder dynamiskt expanderande .vhd- eller .vhdx-diskfiler orsakar det upp till 25 % I/O-prestandapåverkan för Configuration Manager arbetsbelastning. Om du behöver expandera diskar dynamiskt kompenserar du genom att lägga till ytterligare 25 % IOPS-prestanda i matrisen.

När du kör Configuration Manager-platsservern eller SQL Server inuti en virtuell dator isolerar du Hyper-V-värdoperativsystemets enheter från den virtuella datorns operativsystem och dataenheter.

Mer information om hur du optimerar virtuella datorer finns i Prestandajustering av Hyper-V-servrar.

Exempel: Hyper-V VM-baserad platsserver

Storleksriktlinjerna för en samlokaliserad platsserver och SQL Server med 150 000 klienter är 1 800 IOPS för platsserverns inkorgar och 7 400 IOPS för SQL Server filer.

Den resulterande diskkonfigurationen kan se ut så här:

1. Innehåller inte rekommenderade reservdiskar.
2. Fast storlek, genomströmning .vhdx för den virtuella datorenheten som är dedikerad till den underliggande volymen.
3. Det här värdet kommer från Exempel på diskkonfigurationer.

Börja med att läsa vanliga frågor och svar om Configuration Manager i Azure.

Virtuella IaaS-datorer (Infrastruktur som en tjänst) i Azure som utnyttjar Premium Storage-baserade diskar kan ha hög IOPS. På dessa virtuella datorer konfigurerar du ytterligare diskar för förväntade diskutrymmesbehov i stället för för ytterligare IOPS.

Azure Storage är redundant och kräver inte flera diskar för tillgänglighet. Du kan stripe-diskar i Diskhanteraren eller Lagringsutrymmen för att ge ytterligare utrymme och prestanda.

Mer information och rekommendationer om hur du maximerar Premium Storage prestanda och kör SQL-servrar på virtuella Azure IaaS-datorer finns i:

• Optimera programprestanda

• Vägledning för diskar

Exempel: Azure-baserad platsserver

Storleksriktlinjerna för en samlokaliserad platsserver och SQL Server med 50 000 klienter är åtta kärnor, 32 GB och 1 200 IOPS för platsserverns inkorgar och 2 800 IOPS för SQL Server filer.

Den resulterande Azure-datorn kan vara en DS13v2 (åtta kärnor, 56 GB) med följande diskkonfiguration:

1. Det här värdet kommer från Exempel på diskkonfigurationer.
2. Azure-vägledningen gör det möjligt att placera TempDB på den lokala, SSD-baserade D: -enheten, eftersom den inte överskrider det tillgängliga utrymmet och tillåter ytterligare disk-I/O-distribution.

Exempel: Azure-baserad platsserver (för omedelbar prestandaökning)

Dataflödet för Azure-diskar begränsas av storleken på den virtuella datorn. Konfigurationen i föregående Azure-exempel kan begränsa framtida expansion eller ytterligare prestanda. Om du lägger till ytterligare diskar under den första distributionen av din virtuella Azure-dator kan du utöka din virtuella Azure-dator för ökad bearbetningskraft i framtiden, med minimal startinvestering. Det är mycket enklare att planera i förväg för att öka webbplatsens prestanda när kraven ändras, i stället för att senare behöva göra en mer komplicerad migrering.

Ändra diskarna i föregående Azure-exempel för att se hur IOPS ändras.

DS13v2

1. Diskar är randiga med hjälp av Lagringsutrymmen.
2. Det här värdet kommer från Exempel på diskkonfigurationer. Vm-storlek begränsar prestanda.
3. Azure-vägledningen gör det möjligt att placera TempDB på den lokala, SSD-baserade D: -enheten, eftersom den inte överskrider det tillgängliga utrymmet och tillåter ytterligare disk-I/O-distribution.

Om du behöver mer prestanda i framtiden kan du utöka den virtuella datorn till en DS14v2, vilket kommer att fördubbla cpu och minne. Den ytterligare diskbandbredd som tillåts av den virtuella datorns storlek ökar också omedelbart den tillgängliga disk-IOPS på dina tidigare konfigurerade diskar.

DS14v2

1. Diskar är randiga med hjälp av Lagringsutrymmen.
2. Det här värdet kommer från Exempel på diskkonfigurationer. Vm-storlek begränsar prestanda.
3. Azure-vägledningen gör det möjligt att placera TempDB på den lokala, SSD-baserade D: -enheten, eftersom den inte överskrider det tillgängliga utrymmet och tillåter ytterligare disk-I/O-distribution.

Båda kan fungera korrekt, förutsatt att den enskilda servern har rätt storlek eller att nätverksanslutningen är tillräcklig mellan de två servrarna.

Fjärr-SQL Server kräver start- och driftkostnaden för ytterligare en server, men är typiskt bland de flesta storskaliga kunder. Fördelarna med den här konfigurationen är:

• Ökade tillgänglighetsalternativ för webbplatser, till exempel SQL Server AlwaysOn
• Möjlighet att köra tung rapportering med mindre överhörd bearbetning till platsbearbetning
• Enklare haveriberedskap i vissa situationer
• Enklare säkerhetshantering
• Rollavgränsning för SQL Server hantering, till exempel med ett separat DBA-team

Samlokaliserade SQL Server kräver en enda server och är typisk för de flesta småskaliga kunder. Fördelarna med den här konfigurationen är:

• Lägre kostnader för datorer, licenser och underhåll
• Färre felpunkter på webbplatsen
• Bättre kontroll för att planera stilleståndstid

Som standard använder SQL Server allt tillgängligt minne på servern, vilket kan svälta operativsystemet och andra processer på datorn. För att undvika potentiella prestandaproblem är det viktigt att allokera minne till SQL Server uttryckligen. På platsservrar som är samlokaliserade med SQL Server kontrollerar du att operativsystemet har tillräckligt med RAM-minne för cachelagring av filer och andra åtgärder. Kontrollera att det finns tillräckligt med RAM-minne kvar för SMSExec och andra Configuration Manager processer. När du kör SQL Server på en fjärrserver kan du allokera större delen av minnet till SQL, men inte alla. Granska storleksriktlinjerna för inledande vägledning.

SQL Server minnesallokering ska avrundas till hela GB. När RAM-minnet ökar till stora mängder kan du också låta SQL Server ha en högre procentandel. När till exempel 256 GB eller mer RAM är tillgängligt kan du konfigurera SQL Server för upp till 95 %, eftersom det fortfarande bevarar mycket minne för operativsystemet. Att övervaka sidfilen är ett bra sätt att se till att det finns tillräckligt med minne för operativsystemet och alla Configuration Manager processer.

Du kan stöta på problem med minneskonkurrering om det finns fler än 16 fysiska kärnor och inte tillräckligt med RAM-minne på SQL Server. Arbetsbelastningen Configuration Manager fungerar bättre när minst 3–4 GB RAM-minne per kärna är tillgängligt för SQL. När du lägger till kärnor i SQL Server bör du öka RAM-minnet i proportionella mängder.

I allmänhet har tillgänglighetsgrupper försumbar effekt på systemets prestanda när det finns tillräckligt med nätverk mellan replikservrarna. Du kan snabbt öka databasloggens .ldf-fil i en miljö med upptagen tillgänglighetsgrupp. Loggfilsutrymmet frigörs dock automatiskt efter en lyckad databassäkerhetskopia. Lägg till ett SQL Server jobb för Configuration Manager-databasen för att utföra en säkerhetskopia, till exempel var 24:e timme, och en .ldf-säkerhetskopiering var sjätte timme. Mer information om tillgänglighetsgrupper och Configuration Manager, inklusive mer om SQL Server säkerhetskopieringsstrategier, finns i Förbereda för användning av en SQL Server AlwaysOn-tillgänglighetsgrupp.

SQL Server komprimering rekommenderas inte för Configuration Manager-databasen. Även om det inte finns några funktionella problem med att aktivera komprimering på en Configuration Manager databas, visar testresultaten inte mycket storleksbesparingar jämfört med den potentiella betydande prestandapåverkan på systemet.

Alla hemligheter i Configuration Manager-databasen lagras redan på ett säkert sätt, men om du lägger till SQL Server kryptering kan du lägga till ytterligare ett säkerhetslager. Det finns inga funktionella problem med att aktivera kryptering i databasen, men det kan uppstå en prestandaförsämring på upp till 25 %. Kryptera därför med försiktighet, särskilt i storskaliga miljöer. Kom också ihåg att uppdatera dina säkerhetskopierings- och återställningsplaner så att du kan återställa krypterade data.

Information om versioner av SQL som stöds finns i Stöd för SQL Server versioner. Ur prestandasynpunkt uppfyller alla versioner av SQL Server nödvändiga prestandakriterier. Men SQL Server 2016 eller senare tenderar att överträffa SQL Server 2014 i vissa aspekter av Configuration Manager arbetsbelastningen. Dessutom förbättrar körningen SQL Server 2014 på kompatibilitetsnivån SQL Server 2012 (110) prestanda i allmänhet. Vid installationen ställs Configuration Manager databaser som körs på SQL Server 2014 in på kompatibilitetsnivå 110. SQL Server 2016 eller senare är inställt på den SQL Server versionens standardkompatibilitetsnivå, till exempel 130 för SQL Server 2016. Om du uppgraderar SQL Server på plats uppdateras inte kompatibilitetsnivåerna förrän du installerar nästa större Configuration Manager aktuella grenversionen.

Om du ser ovanliga timeouter eller långsamhet i vissa SQL-frågor på SQL Server 2016 eller senare, till exempel när du använder RBAC i Admin Console, kan du prova att ändra SQL Server kompatibilitetsnivå på Configuration Manager-databasen till 110. Körs på SQL Server kompatibilitetsnivå 110 på SQL Server 2014 och nyare versioner av SQL Server stöds fullt ut. Mer information finns i tidsgränsen för SQL-frågor eller konsolen är långsam för vissa Configuration Manager databasfrågor.

Från och med januari 2018 bör du undvika följande SQL Server versioner på grund av olika kända prestandarelaterade eller andra potentiella problem:

• SQL Server 2012 SP3 CU1 till CU5
• SQL Server 2014 SP1 CU6 till SP2 CU2
• SQL Server 2016 RTM till CU3, SP1 CU3 till CU5

Ja, uppdatera index så ofta som en gång i veckan och statistik så ofta som en gång om dagen för att förbättra SQL Server prestanda. Skript från tredje part och ytterligare information som är tillgänglig från Configuration Manager och SQL Server communities kan hjälpa dig att optimera dessa uppgifter.

På stora webbplatser kan vissa SQL Server tabeller, till exempel CI_CurrentComplianceStatusDetails, HinvChangeLog, vara stora, beroende på dina användningsmönster. Du kan behöva minska eller ändra underhållsmetoden för dem en i taget.

SQL Server Express har inga betydande prestandakonsekvenser på sekundära platser, och det är tillräckligt för de flesta kunder. Det är också enkelt att distribuera och hantera och är den rekommenderade konfigurationen för nästan alla kunder i alla storlekar.

Det finns en situation där en fullständig SQL Server installation kan behövas. Om du har ett stort antal distributionsplatser och paket eller källor i din miljö kan du överskrida storleksgränsen på 10 GB på SQL Server Express. Om antalet paket gånger antalet distributionsplatser är mer än 4 000 000, till exempel 2 000 DP:er med 2 000 innehållsdelar, bör du överväga att använda fullständiga SQL Server på dina sekundära platser.

Att lämna inställningen på 0 (använd alla tillgängliga processorer) är optimal för övergripande bearbetningsprestanda i de flesta fall.

Många Configuration Manager administratörer följer riktlinjerna i Rekommendationer och riktlinjer för konfigurationsalternativet "maximal grad av parallellitet" i SQL Server. På de flesta moderna stora maskinvara leder den här vägledningen till en rekommenderad maxinställning på åtta. Men om du kör många mindre frågor jämfört med antalet processorer kan det hjälpa att ange ett högre antal. Att begränsa dig själv till åtta är inte nödvändigtvis den bästa inställningen på större webbplatser när fler kärnor är tillgängliga.

På SQL-servrar med fler än åtta kärnor börjar du med inställningen 0 och gör bara ändringar om du får prestandaproblem eller överdriven låsning. Om du behöver ändra MaxDOP eftersom du stöter på prestandaproblem vid 0 börjar du med ett nytt värde som är minst större än eller lika med det minsta rekommenderade antalet kärnor för webbplatsens SQL Server storlek. Att gå lägre än det här värdet har nästan alltid negativa prestandakonsekvenser. Till exempel behöver en fjärransluten SQL Server för en 100 000 klientplats minst 12 kärnor. Om din SQL Server har 16 kärnor börjar du testa maxDOP-inställningen med värdet 12.

Var försiktig när du inaktiverar antivirusskydd på alla system. I miljöer med hög volym och säker miljö rekommenderar vi att du inaktiverar aktiv övervakning för optimal prestanda.

Mer information om rekommenderade antivirusundantag finns i Rekommenderade antivirusundantag för Configuration Manager 2012 och Current Branch Site Servers, platssystem och klienter.

Om du ändrar några viktiga IIS-inställningar, till exempel WsusPool Queue Length och WsusPool Private Memory Limit, kan du förbättra WSUS-prestanda, även på mindre installationer. Mer information finns i Rekommenderad maskinvara.

Kontrollera också att du har de senaste uppdateringarna installerade för operativsystemet som kör WSUS:

• Windows Server 2012: Alla kumulativa uppdateringar som inte är "endast säkerhet" som släpptes oktober 2017 eller senare. (KB4041690)
• Windows Server 2012 R2: Alla kumulativa uppdateringar som inte är "endast säkerhet" släpptes augusti 2017 eller senare. (KB4039871)
• Window Server 2016: alla kumulativa uppdateringar som inte är "endast säkerhet" släpptes augusti 2017 eller senare. (KB4039396)

Se Den fullständiga guiden för att Microsoft WSUS- och Configuration Manager SUP-underhåll.

Traditionell övervakning av serverprestanda fungerar effektivt för allmänna Configuration Manager. Du kan också använda de olika System Center Operations Manager-hanteringspaketen för Configuration Manager, SQL Server och Windows Server för att övervaka servrarnas grundläggande hälsotillstånd. Du kan också direkt övervaka räknare för Windows Performance Monitor (PerfMon) Configuration Manager tillhandahåller. Övervaka kvarvarande uppgifter i de olika inkorgarna för tidiga varningstecken på potentiella problem med webbplatsprestanda eller kvarvarande uppgifter.

Se även

• Riktlinjer för webbplatsstorlek och prestanda
• vanliga frågor och svar om Configuration Manager i Azure