System Center – Service Manager prestanda

  • Artikel
  • 11 minuter för att läsa

Viktigt

Den här Service Manager har nått slutet av supporten, rekommenderar vi att du uppgraderar till Service Manager 2022.

Prestanda för System Center – Service Manager serverroller och funktioner påverkas av olika faktorer. Det finns i allmänhet tre områden där positiva och negativa prestanda är mest märkbara i Service Manager:

  • Service Manager svarstider i konsolen. Det här är den tid det tar från det ögonblick då du vidtar någon slags åtgärd i konsolen fram till dess att den har slutförts.

  • Datainfogningstiden för kopplingar. Det här är hur lång tid det tar Service Manager att importera data när en anslutningsapp synkroniseras.

  • Tid för slutförande av arbetsflöde. Det här är den tid det tar att tillämpa någon slags åtgärd automatiskt i arbetsflöden.

Anslutningsprestanda

Inledande synkronisering av anslutningstjänsten kan ta lång tid, till exempel 8 till 12 timmar för en stor inledande synkronisering med Configuration Manager. När en anslutningsapp synkroniseras till en början kan du förvänta dig att prestandan blir Service Manager för alla serverroller och processer under den här tiden. Detta beror på hur data infogas sekventiellt i Service Manager databasen, som är en Microsoft SQL Server databas. Även om du inte kan påskynda anslutningens inledande synkroniseringsprocess kan du planera för den första synkroniseringen och se till att synkroniseringsprocessen slutförs i stor Service Manager sätts i produktion.

När den inledande synkroniseringen är Service Manager fortfarande synkronisera skillnaderna, vilket inte har en mätbar inverkan på prestandan.

Arbetsflödesprestanda

Arbetsflöden är automatiska processer som utförs. Det kan till exempel handla om att skicka aviseringar via e-post, nästa steg i en aktivering av en ändringsbegäran eller en automatisk tillämpning av en mall.

Prestanda för arbetsflöden påverkas av följande:

  • Normalt sett startar och avslutas arbetsflöden inom en minut. När Service Manager är hårt arbetsbelastningsintensiva slutförs inte arbetsflödena lika snabbt som vanligt.

  • Systemet kan dessutom belastas ytterligare genom att du skapar nya arbetsflöden, till exempel en ny aviseringsprenumeration. När antalet nya arbetsflöden ökar, tar det också längre tid för varje enskilt arbetsflöde att slutföras.

När systemet är hårt belastat – om till exempel ett stort antal nya incidenter skapas och varje incident genererar många arbetsflöden kan prestanda påverkas negativt.

Påverkan på prestanda för grupper, köer och användarroller

Grupper och användarroller bör planeras på ett tidigt stadium. Du bör vara försiktig med att skapa grupper och välja så litet omfång för dem som möjligt. Sedan bör du först fylla i databasen med data från Active Directory Domain Services (AD DS), Configuration Manager och System Center Operations Manager innan du skapar dina grupper.

Administratörer skapar ofta grupper för att säkerställa att användarna bara har åtkomst till vissa grupper. I ett scenario kanske du vill skapa en deluppsättning med incidenter, till exempel sådana incidenter som påverkar datorer som används av personalen. I detta scenario kanske du vill att bara viss personal ska kunna visa och ändra gruppen med känsliga servrar. Därefter skulle du behöva skapa en grupp med alla användare och en grupp för de känsliga datorerna för att möjliggöra denna åtkomst, och sedan kontrollera att en säkerhetsroll har åtkomst till både gruppen Alla användare och gruppen Känsliga servrar. Att skapa en grupp som innehåller alla användare leder oundvikligen till prestandapåverkan eftersom Service Manager ofta kontrollerar om det finns ändringar i gruppen. Den här kontrollen görs som standard var 30:e sekund. När grupperna är mycket stora, belastas systemet hårt på grund av de här ändringskontrollerna, vilket kan ha stor negativ inverkan på svarstiden.

Lösning 1: Du kan manuellt ange hur ofta Service Manager söker efter gruppändringar genom att ändra en registernyckel. Genom att till exempel ändra frekvensen för gruppkontrollen från 30 sekunder till 10 minuter förbättras prestanda betydligt. Köer och servicenivåmål är särskilda grupper som använder samma avsökningsintervall för gruppberäkning. Om avsökningsintervallets värde ökar blir därmed beräkningstiden för kö- och servicenivåmål längre.

Varning

Systemet kan skadas om du redigerar registret på felaktigt sätt. Säkerhetskopiera viktig information på datorn innan du ändrar registret.

Ställa in intervallet för kontroll av gruppändringar manuellt

  1. Kör Regedit och gå till HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Skapa ett nytt DWORD-värde med namnet GroupCalcPollingInterval Milliseconds.

  3. I det här värdet anger du intervallet i millisekunder. Resultatet multipliceras med 6. Om du till exempel vill ange intervallet till 10 minuter skriver du 600000.

  4. Starta om hanteringstjänsten i System Center.

Lösning 2: Du kan använda ett Windows PowerShell för att lägga till objekt av en typ, till exempel "Användare", i en användarroll. I princip kan en analytiker som är inloggad i den här rollen komma åt alla objekt som har en typ som är lika med "Användare". Om du använder den här metoden eliminerar du behovet av en mycket stor grupp ("Alla användare") och den dyra kontroll som Service Manager utför för att fastställa det här gruppmedlemskapet. På Service Manager-hanteringsservern kan du köra följande Windows PowerShell för att lägga till "användartypen" i rollen "RoleName". Du måste anpassa det här exempelskriptet till din egen miljö.

Köra ett Windows PowerShell-skript för att lägga till objekt till en användarroll

  • Ändra följande skript efter behov innan du kör det:
#  
# Insert a "type" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"  
#  
# Note:  This is a simple demonstration script without error checking.   
#   

# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  

$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  

$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   

# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) "User",   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
#  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  

# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  

#   
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}

Visa prestanda

När du skapar vyer bör du planera att använda "typiska" klasser i systemet när det är möjligt. De flesta objektklasser, till exempel Incidenthantering, har två typer: "typisk" och "avancerad". Objekttypen ”typisk” innehåller enkla referenser till en mindre deluppsättning med data som är relaterade till ett objekt. Objekttypen ”avancerad” innehåller många komplexa referenser till data som är relaterade till ett objekt. Objekttypen ”typisk” är enkla projektioner medan de avancerade typerna är komplexa projektioner. De flesta avancerade objekttyper används för att fylla i olika fält i formulär som du normalt inte vill visa i en vy. När du skapar en vy baserat på en avancerad objekttyp och när du öppnar vyn, Service Manager frågar databasen och en stor mängd data läses. Men mycket lite av de hämtade data visas eller används.

Om du får problem med prestanda i vyerna som du har definierat när du använder avancerade objekttyper i vyerna, bör du använda typiska objekttyper istället. En alternativ metod är att skapa egna projektionstyper som endast innehåller de data som behövs som bas för en vy.

Service Manager databasprestanda

Prestanda för Service Manager-databasen påverkas direkt av olika faktorer, inklusive antalet samtidiga Service Manager-konsoler som läser eller skriver data, intervallet för gruppändringskontrollen och data som infogas av anslutningsappar. Det här dokumentet innehåller mer information. Här är några viktiga punkter:

  • Du bör ha minst 8 GB RAM-minne för hanteringsservern som är värd för Service Manager-databasen i så att du kan få en acceptabel svarstid i vanliga scenarier.

  • Du bör ha minst 8 CPU-kärnor på den dator som är värd Service Manager databasen.

  • Du kan få bättre prestanda för databasen genom att om möjligt skilja loggfiler och datafiler åt på separata fysiska diskar. Du kan få ytterligare fördelar genom att flytta tempdb till en annan fysisk RAID-enhet än den Service Manager databasen. Använd ett RAID 1+0-disksystem som värd för Service Manager databas, om möjligt.

  • Prestanda kan påverkas negativt om Service Manager-databasen skapas med en mindre storlek och den är inställd på automatisk storleksökning, särskilt i små steg.

Se Service Manager Sizing Helper-verktyget som ingår i dokumentationsuppsättningen för Service Manager-jobbhjälp (SM_job_aids.zip) för hjälp med att utvärdera databasens storlek och skapa databasen med en storlek som är närmare den slutliga storleken. Detta hjälper prestandan genom att minska antalet gånger som databasen måste växa automatiskt.

På samma sätt gäller även alla andra metodtips för databaser med höga prestanda. Om du till exempel kan dra nytta av ett överlägset diskundersystem kan du dra nytta av att dela upp grupper av tabeller i respektive filgrupper och flytta dem till en annan fysisk enhet.

Service Manager för hanteringsservern

Prestanda för Service Manager-hanteringsservern påverkas främst av antalet aktiva samtidiga Service Manager-konsoler. Eftersom alla Service Manager samverkar med hanteringsservern bör du överväga att lägga till ytterligare hanteringsservrar om du planerar att ha ett stort antal samtidiga konsoler. Du bör ha 8 GB RAM-minne för hanteringsservern. Det bör finnas minst fyra CPU-kärnor per hanteringsserver, förutsatt att du har mellan 10 och 12 aktiva konsoler per CPU-kärna.

Service Manager konsolprestanda

Prestanda för Service Manager-konsolen påverkas främst av det antal formulär som dina analytiker vanligtvis har öppna och mängden data som hämtas av vyer. Du bör ha 4 GB RAM-minne på datorn där Service Manager-konsolen är installerad. Om det förekommer vyer som hämtar stora mängder data kommer du att behöva ytterligare RAM. Du bör ha minst en processor med 4 kärnor för den dator där Service Manager-konsolen är installerad. Eftersom Service Manager-konsolen är ett slutanvändarprogram rekommenderar vi att du startar om den om du ser för hög resursförbrukning. Konsolen Service Manager cachelagrar aggressivt information i minnet, vilket kan bidra till den totala minnesanvändningen.

Service Manager databasprestanda för informationslager

Informationslagrets prestanda påverkas direkt av olika faktorer, inklusive antalet samtidiga Service Manager-hanteringsservrar som skickar data, mängden lagrade data eller datakvarhållningsperioden, ändringstakten och frekvensen för extrahering, transformering och inläsning (ETL). Mängden data som lagras i datalagret ökar med tiden. Det är viktigt att du arkiverar onödiga data. En annan faktor som påverkar datalagrets prestanda är BatchSize-inställningen i ETL-processer.

Du kan få bättre prestanda genom att skilja loggfiler och datafiler åt på separata fysiska diskar. I vilket fall bör du undvika att placera mer än en loggfil på varje disk. Du kan också få bättre genomströmning genom att lägga tempdatabasen på en annan fysisk disk än övriga databaser. Slutligen kan du förbättra prestanda genom att placera olika databaser på deras respektive fysiska diskar. Använd ett RAID 1+0-disksystem som värd för ditt informationslager, om möjligt. Du bör vanligtvis ha minst 8 GB RAM-minne för datorn där informationslagerdatabaserna är installerade. Om du har ytterligare informationslagerdatakällor från Operations Manager eller Configuration Manager bör du öka mängden RAM-minne för databaserna. Du kan dra nytta av mer minne på den dator som kör SQL Server som är värd för informationslagret och ännu mer om databaserna Datamart och Repository finns på samma server. Men om du har 4 000 eller färre datorer i distributionstopologin räcker det med 4 GB. Det bör finnas minst 8 CPU-kärnor på datorn där datalagerdatabasen är installerad. Ytterligare kärnor ökar prestanda både för ETL och rapporter.

Prestanda kan påverkas negativt om alla databaser i systemet skapas med liten storlek och ställs in för automatisk storleksökning, särskilt i små steg. Se verktyget Service Manager Sizing Helper som ingår i dokumentationsuppsättningen för Service Manager-jobbhjälp (SM_job_aids.zip) för att utvärdera databasens storlek och skapa databasen med en storlek som ligger närmare den slutliga storleken, vilket hjälper prestandan genom att minska antalet gånger som databasen måste växa automatiskt.

Service Manager har inbyggt stöd för filgrupper. Du kan dra nytta av detta genom att placera filgrupperna på separata hårddiskar. Mer information om metodtips för filgrupper finns i SQL Server dokumentationen.

Service Manager serverprestanda för informationslager

Informationslagerserverns prestanda påverkas av antalet Service Manager-hanteringsservrar som är registrerade i informationslagret, storleken på distributionen och antalet datakällor. Du bör vanligtvis ha minst 8 GB RAM-minne för informationslagerservern. Prestandan kan dock dra nytta av ytterligare minne för avancerade distributionsscenarier där mer än Service Manager en hanteringsserver infogar data i informationslagret. Om du måste avse prestanda bör din högsta prioritet vara minne för den dator som kör SQL Server. Det bör minst finnas 8 CPU-kärnor för att undvika prestandaproblem.

Portalprestanda för självbetjäning

Portalen Self-Service är utformad för enkel åtkomst till incident- och tjänstbegärande. Den är inte utformad för att hantera tusentals användare på samma gång.

Prestandatestning för Self-Service-portalen fokuserade specifikt på typiska scenarier på "måndag morgon" för att säkerställa att hundratals användare kan logga in inom ett intervall på 5 till 10 minuter och öppna incidenter med godtagbara (mindre än 4 till 5 sekunders) svarstider. Målet uppnåddes med minimikraven på maskinvara som rekommenderas i det här dokumentet.

Prestanda för servicenivåmål

Det finns inget specifikt antal servicenivåmål som Service Manager stöder. Om en organisation till exempel vanligtvis har få incidenter kan den ha stöd för fler servicenivåmål än vad den annars skulle kunna göra. En större incidentvolym kan dock kräva antingen färre servicenivåmål eller utskalning av ytterligare maskin- och programvara efter behov. Vi rekommenderar att du inte skapar fler än fem servicenivåmål för en typisk 50 000-Service Manager konfiguration. Du kan eventuellt skapa fler servicenivåmål. Men eftersom villkoren varierar mycket från organisation till organisation kan Microsoft inte ge en konkret rekommendation för antalet servicenivåmål som du inte bör överskrida. Om distributionskonfigurationen drabbas av dåliga prestanda på grund av antalet servicenivåmål rekommenderar vi att du skalar ut med hjälp av nästa större distributionsscenario, enligt beskrivningen i artikeln Konfigurationer för distributionsscenarier i den här guiden.

Nästa steg