Configuration Manager riktlinjer för webbplatsstorlek och prestanda

Gäller för: Konfigurationshanteraren (current branch)

Configuration Manager leder branschen i skala och prestanda. Annan dokumentation omfattar maximala skalningsgränser som stöds och maskinvaruriktlinjer för att köra platser i de största miljöstorlekarna. Den här artikeln ger kompletterande prestandavägledning för miljöer av alla storlekar. Den här vägledningen kan hjälpa dig att mer exakt uppskatta vilken maskinvara du behöver distribuera Configuration Manager.

Den här artikeln fokuserar på den största bidragsgivaren till Configuration Manager flaskhalsar för prestanda: undersystemet diskinmatning/utdata eller IOPS.

• Presenterar information och testresultat som fokuserar på IOPS
• Dokument om hur du återskapar testerna med dina egna miljöer och maskinvara
• Föreslår disk-IOPS-krav för olika storleksmiljöer

Metodik för prestandatest

Du kan distribuera Configuration Manager på många unika sätt, men det är viktigt att förstå några variabler i alla storleksdiskussioner. En variabel är funktionsintervall, till exempel en inventeringscykel. En annan variabel är antalet användare, programvarudistributioner eller andra objekt som systemet refererar till eller distribuerar. Prestandatestning tillämpar dessa variabler som en del av en belastning. Belastningen genererar objekt i en typisk takt för företagskunder som använder produktionsdistributioner i olika storleksmiljöer.

I följande avsnitt beskrivs några viktiga inställningar och konfigurationer som ska användas vid testning och modellering av bearbetningsbehov för stora företag. De här riktlinjerna hjälper dig att ange grundläggande systemprestandaförväntningar för de föreslagna maskinvarustorlekarna.

Inställningar för funktionsintervall

De flesta tester bör använda standardintervall för nyckelcyklerna i systemet. Maskinvaruinventeringstestning sker till exempel en gång i veckan med en .mof-fil som är större än standardvärdet. Vissa återkommande funktionsintervall, särskilt maskin- och programvaruinventeringscykler, kan ha betydande effekter på en miljös prestandaegenskaper. Miljöer som möjliggör aggressiva standardintervall för datainsamling behöver överdimensionerad maskinvara i direkt proportion till ökningen av aktiviteten. Anta till exempel att du har 25 000 skrivbordsklienter och vill samla in maskinvaruinventering två gånger snabbare än standardintervallet. Börja med att ändra storleken på webbplatsens maskinvara som om du hade 50 000 klienter.

Objekt

Tester bör använda det övre genomsnittet av de objekt som stora företag tenderar att använda med systemet. Typiska värden är tusentals samlingar och program som distribueras till hundratusentals användare eller system. Testerna bör köras samtidigt på alla objekt i systemet vid dessa gränser. Många kunder använder flera funktioner, men använder vanligtvis inte alla funktioner i produkten vid dessa övre gränser. Genom att testa med alla produktfunktioner får du bästa möjliga systemomfattande prestanda och ger en buffert för funktioner som vissa kunder kan använda över genomsnittet.

Massor

Tester bör också köras på större än standard genomsnittlig dagbelastning genom att göra simuleringar som genererar högsta användningskrav på systemet. Ett exempel är att simulera Patch Tuesday-distributioner för att se till att systemet snabbt kan returnera uppdateringsefterlevnadsdata under dessa dagar med hög aktivitet. Ett annat exempel är att simulera webbplatsaktivitet under ett omfattande utbrott av skadlig kod för att säkerställa att meddelanden och svar i tid är möjliga. Även om distribuerade datorer av den rekommenderade storleken kan vara underanvända en viss dag, kräver mer extrema situationer viss bearbetningsbuffert.

Konfigurationer

Kör testning på en rad fysiska maskinvara, Hyper-V och Azure-maskinvara, med en blandning av operativsystem som stöds och SQL Server versioner. Verifiera alltid de värsta fallen för konfigurationen som stöds. I allmänhet returnerar Hyper-V och Azure jämförbara prestandaresultat till motsvarande fysisk maskinvara när de konfigureras på liknande sätt. Aktuella serveroperativsystem tenderar att ha prestanda som är lika med eller bättre än tidigare operativsystemversioner. Alla plattformar som stöds uppfyller minimikraven, men vanligtvis ger de senaste versionerna av stödjande produkter som Windows och SQL Server ännu bättre prestanda.

Den största varianten kommer från de SQL Server versioner som används. Mer information om SQL Server versioner finns i Vilken version av SQL Server ska jag köra?.

Viktiga prestandabestämningsfaktorer

Du kan testa och mäta Configuration Manager prestanda med olika typer av inställningar, på olika sätt och i olika platsstorlekar. Följande inställningar och objekt kan påverka prestanda avsevärt. Tänk på dem när du testar och modellerar prestanda i din miljö.

Maskinvaruinventering

Om du vill testa baslinjeprestanda anger du insamling av maskinvaruinventering till en gång i veckan, med standardstorleken för .mof-filen plus cirka 20 % andra egenskaper. Aktivera inte alla egenskaper och samla bara in egenskaper som du faktiskt behöver. Var särskilt uppmärksam när du samlar in egenskaper, till exempel tillgängligt virtuellt minne, som alltid ändras för varje inventeringscykel. Om du samlar in dessa egenskaper kan det orsaka överdriven omsättning för varje inventeringscykel från varje klient.

Programvaruinventering

Om du vill testa baslinjeprestanda anger du insamling av programvaruinventering till en gång i veckan, med endast produktinformation . Insamling av många filer kan innebära en betydande belastning på inventeringsundersystemet. Undvik att ange filter som kan samla in tusentals filer på många klienter, till exempel *.exe eller *.dll.

Samlingar

Prestandatestning av baslinje kan innehålla flera tusen samlingar med olika typer av omfång, storlek, komplexitet och uppdateringsinställningar. Webbplatsprestanda är inte en direkt funktion av det omfattande antalet samlingar på en webbplats. Prestanda är också en korsprodukt av samlingarnas frågekomplexitet, fullständiga och inkrementella uppdateringar och ändringsfrekvens, beroenden mellan samlingar och antal klienter i samlingarna.

Om möjligt minimerar du samlingar som har dyra eller komplicerade dynamiska regelfrågor. För samlingar som kräver dessa typer av regler anger du lämpliga uppdateringsintervall och uppdateringstider för att minimera effekten av omvärdering av samlingen i systemet. Uppdatera till exempel vid midnatt i stället för 08:00.

Aktivering av inkrementella uppdateringar av samlingar garanterar snabba och snabba uppdateringar av samlingsmedlemskap. Men även om inkrementella uppdateringar är effektiva lägger de fortfarande belastningen på systemet. Balansera den ändringsfrekvens du förväntar dig med behovet av uppdateringar i nära realtid för medlemskap. Anta till exempel att du förväntar dig stora omsättningar i samlingsmedlemmar, men att du inte behöver medlemskapsuppdateringar i nära realtid. Det är mer effektivt och ger mindre belastning på systemet för att uppdatera samlingen med en schemalagd fullständig uppdatering vid något intervall, än för att aktivera inkrementella uppdateringar.

När du aktiverar inkrementella uppdateringar kan du minska alla schemalagda fullständiga uppdateringar i samma samlingar. De är bara en säkerhetskopieringsmetod för utvärdering, eftersom inkrementella uppdateringar bör hålla ditt samlingsmedlemskap uppdaterat nästan i realtid. Metodtips för samlingar rekommenderar ett maximalt antal samlingar för inkrementella uppdateringar, men som artikeln påpekar kan din upplevelse variera beroende på många faktorer.

Samlingar med endast regler för direkt medlemskap och med en begränsande samling som inte gör inkrementella uppdateringar behöver inte schemalagda fullständiga uppdateringar. Inaktivera uppdateringsscheman för dessa typer av samlingar för att förhindra onödig belastning på systemet. Om den begränsande samlingen använder inkrementella uppdateringar kan samlingar med endast regler för direkt medlemskap inte återspegla medlemskapsuppdateringar i upp till 24 timmar eller tills en schemalagd uppdatering äger rum.

Även om det inte är bästa praxis skapar vissa organisationer hundratals eller till och med tusentals samlingar som en del av olika affärsprocesser. Om du använder automatisering för att skapa samlingar är det viktigt att aktivera nödvändiga inkrementella uppdateringar korrekt. Minimera och sprida ut alla fullständiga uppdateringsscheman för att undvika frekventa platser för insamlingsutvärdering under en enda tidsperiod. Upprätta en regelbunden rensningsprocess för att ta bort oanvända samlingar, särskilt om du automatiskt skapar samlingar som du inte längre behöver efter en viss tid.

Kom ihåg att Configuration Manager skapar principer för alla objekt i dina samlingar när du riktar uppgifter som distributioner till dem. Medlemskapsändringar, antingen via schemalagd uppdatering eller inkrementella uppdateringar, kan skapa mycket mer arbete för hela systemet. De senaste aktuella grenbyggena har särskilda principoptimeringar för samlingarna Alla system och Alla användare. När du riktar in dig på hela företaget använder du de inbyggda samlingarna i stället för en klon av dessa inbyggda samlingar.

Om du vill undersöka insamlingsprestandan ännu djupare kan du visa samlingsutvärderingen i -konsolen. Mer information finns i Så här visar du samlingsutvärdering.

Identifieringsmetoder

För testning av baslinjeprestanda kör du serverbaserade identifieringsmetoder en gång i veckan och aktiverar deltaidentifiering efter behov för att hålla data uppdaterade under veckan. Testerna bör identifiera en objektkvantitet som är proportionell mot den simulerade företagsstorleken. Prestandabaslinjetestet för pulsslagsidentifiering bör också köras en gång i veckan.

Identifieringsdata är globala data. Ett vanligt prestandarelaterat problem är att felkonfigurera serverbaserade identifieringsmetoder i en hierarki, vilket orsakar dubblettidentifiering av samma resurser från flera primära platser. Konfigurera identifieringsmetoder noggrant för att optimera kommunikationen med måltjänsten, till exempel Active Directory-domänkontrollanter, samtidigt som du undviker duplicering av samma identifieringsomfång på flera primära platser.

Allmänna riktlinjer för storleksändring

Baserat på föregående metod för prestandatest ger följande tabell allmänna riktlinjer för minimikrav på maskinvara för specifika antal hanterade klienter. Dessa värden bör göra det möjligt för de flesta kunder med det angivna antalet klienter att bearbeta objekt tillräckligt snabbt för att administrera den angivna platsen. Datorkraften fortsätter att minska i pris varje år, och vissa av kraven nedan är små för moderna servermaskinvarukonfigurationer. Maskinvara som överskrider följande riktlinjer ökar proportionellt prestandan för webbplatser som kräver mer bearbetningskraft eller har särskilda produktanvändningsmönster.

Anmärkningar om allmänna riktlinjer för storleksändring

Anmärkning 1: Kärnor

Configuration Manager kör många samtidiga processer, så behöver ett visst minsta antal CPU-kärnor för olika platsstorlekar. Även om kärnorna blir snabbare varje år är det viktigt att se till att ett visst minsta antal kärnor fungerar parallellt. I allmänhet uppfyller alla processorer på servernivå som produceras efter 2015 de grundläggande prestandabehoven för kärnorna som anges i tabellen. Configuration Manager utnyttjar andra kärnor utöver rekommendationerna. När du har minsta föreslagna kärnor prioriterar du cpu-resursinvesteringar för att öka hastigheten för befintliga kärnor. Lägg inte till fler, långsammare kärnor. Till exempel har Configuration Manager bättre prestanda för nyckelbearbetningsuppgifter med 16 snabba kärnor än med 24 långsammare kärnor. Den här prestandan förutsätter att det finns tillräckligt med andra systemresurser som disk-IOPS.

Relationen mellan kärnor och minne är också viktig. Att ha mindre än 3–4 GB RAM per kärna minskar i allmänhet den totala bearbetningskapaciteten på dina SQL-servrar. Du behöver mer RAM-minne per kärna när SQL Server samplaceeras med platsserverkomponenterna.

Anmärkning 2: SQL Server minnesallokering

Använd det här värdet för att konfigurera Maximalt serverminne (i MB) i egenskaperna för SQL Server. Det är procentandelen av den totala mängden minne som är tillgängligt på servern.

Konfigurera inte minimi- och maxvärdena på samma sätt. Den här vägledningen är specifikt för det maximala minne som du bör tillåta SQL Server allokera.

Anmärkning 3: IOPS: Inkorgar och IOPS: SQL

Dessa värden refererar till IOPS-behoven för Configuration Manager och SQL Server logiska enheter. Kolumnen IOPS: Inkorgar visar IOPS-kraven för den logiska enheten med Configuration Manager inkorgskataloger. Kolumnen IOPS: SQL visar det totala antalet IOPS-behov för de logiska enheter som olika SQL Server filer använder. Dessa kolumner är olika eftersom de två enheterna bör ha olika formatering. Mer information och exempel på föreslagna SQL Server diskkonfigurationer och metodtips för filer, inklusive information om att dela upp filer över flera volymer, finns i vanliga frågor och svar om webbplatsstorlek och prestanda.

Båda dessa IOPS-kolumner använder data från branschstandardverktyget Diskspd. Se Så här mäter du diskprestanda för instruktioner om hur du duplicerar dessa mått. I allmänhet, när du uppfyller grundläggande processor- och minneskrav, har underlagringssystemet störst inverkan på webbplatsens prestanda, och förbättringar här ger mest återbetalning för investeringar.

Obs! 4: Lagringsutrymme krävs

Dessa verkliga värden kan skilja sig från andra dokumenterade rekommendationer. Vi tillhandahåller endast dessa siffror som en allmän riktlinje. individuella krav kan variera kraftigt. Planera noggrant för diskutrymmesbehov före platsinstallationen. Anta att en del av det här lagringsutrymmet förblir som ledigt diskutrymme för det mesta. Du kan använda det här buffertutrymmet i ett återställningsscenario eller för uppgraderingsscenarier som behöver ledigt diskutrymme för paketexpansion. Din webbplats kan kräva mer lagring för stora mängder datainsamling, längre perioder av datakvarhållning och stora mängder programdistributionsinnehåll. Du kan också lagra dessa objekt på separata volymer med lägre dataflöde.

Mäta diskprestanda

Du kan använda branschstandardverktyget Diskspd för att ge standardiserade förslag på den IOPS som Configuration Manager miljöer i olika storlekar kräver. Även om de inte är uttömmande är följande teststeg och kommandorader ett enkelt och reproducerbart sätt att beräkna servrarnas dataflöde för diskundersystemet. Du kan jämföra dina resultat med den lägsta rekommenderade IOPS i tabellen med allmänna riktlinjer för storleksändring .

Testresultat från olika typer av maskinvarukonfigurationer i labbmiljöer finns i Exempel på diskkonfigurationer. Du kan använda data för en grov startpunkt när du utformar underlagringssystemet för en ny miljö från grunden.

Så här testar du disk-IOPS

1. Ladda ned diskspd-verktyget.

2. Kontrollera att du har minst 100 GB ledigt diskutrymme. Inaktivera appar som kan störa eller orsaka extra belastning på disken, till exempel aktiv antivirusgenomsökning av katalogen, SQL eller SMSExec.

3. Kör Diskspd från en upphöjd kommandotolk.

   Kör verktyget två gånger i följd för den volym som du vill testa. Det första testet med en storlek på 64 000 med slumpmässiga skrivåtgärder i en minut. Det här testet validerar inläsning av kontrollantcache och diskutrymmesallokering, om volymen expanderas dynamiskt. Ignorera resultatet av det första testet. Det andra testet bör omedelbart följa det första testet och utföra samma belastning i fem minuter.

   Använd till exempel följande specifika kommandorader för att testa G: volymen.

   DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat
   
   del G:\\test\testfile.dat
   
   DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.dat
   

4. Granska utdata från det andra testet för att hitta det totala antalet IOPS i kolumnen I/O per s . I följande exempel är det totala antalet IOPS 3929,18.

   Total IO
   | thread |  bytes      |  I/Os   |  MB/s  | I/O per s | AvgLat | LatStdDev |
   |--------|-------------|---------|--------|-----------|--------|-----------|
   |   1    |  9651814400 |  147275 |  30.68 |    490.92 | 16.294 | 10.210    |
   |   2    |  9676652544 |  147654 |  30.76 |    492.18 | 16.252 |  9.998    |
   |   3    |  9638248448 |  147068 |  30.64 |    490.23 | 16.317 | 10.295    |
   |   4    |  9686089728 |  147798 |  30.79 |    492.66 | 16.236 | 10.072    |
   |   5    |  9590931456 |  146346 |  30.49 |    487.82 | 16.398 | 10.384    |
   |   6    |  9677242368 |  147663 |  30.76 |    492.21 | 16.251 | 10.067    |
   |   7    |  9637330944 |  147054 |  30.64 |    490.18 | 16.319 | 10.249    |
   |   8    |  9692577792 |  147897 |  30.81 |    492.99 | 16.225 | 10.125    |
   | Total: | 77250887680 | 1178755 | 245.57 |   3929.18 | 16.286 | 10.176    |
   

Exempel på diskkonfigurationer

Följande tabeller visar resultat från körningen av teststegen i Så här mäter du diskprestanda med olika testlabbkonfigurationer. Använd dessa data för en grov startpunkt när du utformar underlagringssystemet för en ny miljö från grunden.

Fysiska datorer och Hyper-V

Maskinvaran förbättras alltid. Förvänta dig att nyare generationer av maskinvara och olika maskinvarukombinationer, till exempel SSD och SAN, överskrider de prestanda som anges nedan. Dessa resultat är en grundläggande utgångspunkt att tänka på när du utformar en server eller diskuterar med din maskinvaruleverantör.

I följande tabell visas testresultaten för olika diskundersystem, inklusive spindle- och SSD-baserade hårddiskar, i olika testlabbkonfigurationer. Alla konfigurationer formaterar diskarna med 64k-kluster och ansluter dem till en diskkontrollant i företagsklass. Förutom antalet RAID-matrisdiskar har de minst en extra disk.

I följande tabell visas de specifika enheter som används i det här exemplet. Den här informationen är inte en rekommendation för någon specifik maskinvarumodell eller tillverkare.

Prestanda för Azure-datorer och diskar

Prestanda för Azure-diskar beror på flera faktorer, till exempel storleken på den virtuella Azure-datorn och antalet och typen av diskar som används. Azure lägger också ständigt till nya datortyper och diskhastigheter som skiljer sig från följande diagram. Mer information om Configuration Manager som körs i Azure och mer information om hur du förstår disk-I/O i Azure finns i Configuration Manager på vanliga frågor och svar om Azure.

Alla diskar är formaterade NTFS 64k klusterstorlek, och rader med mer än en disk konfigureras som randiga volymer via Windows Disk Management-verktyget.

Mer information om tillgängliga diskar finns i Välj en disktyp för virtuella Azure IaaS-datorer.

Se även

• Vanliga frågor och svar om webbplatsstorlek och prestanda
• vanliga frågor och svar om Configuration Manager i Azure
• Storleks- och skalningsnummer
• Rekommenderad maskinvara