Dela via

System Center – Service Manager prestanda

  • Artikel

Viktigt

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

Prestanda för System Center – Service Manager serverroller och funktioner påverkas av olika faktorer. I allmänhet finns det tre områden där positiv och negativ prestanda är mest märkbar i Service Manager:

  • Service Manager konsolens svarstider. 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. Så här lång tid tar det för 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 anslutningsappen 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 från början kan du förvänta dig att prestandan försämras för alla Service Manager 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 anslutningsprogrammets inledande synkroniseringsprocess kan du planera för den inledande synkroniseringen och se till att synkroniseringsprocessen slutförs i god tid innan Service Manager försätts i produktion.

När den inledande synkroniseringen är klar fortsätter Service Manager att synkronisera skillnaderna, vilket inte har någon 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 serverroller är under en tung arbetsbelastning slutförs inte arbetsflöden lika snabbt som normalt.

  • 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 grupp-, kö- och användarrollen

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 endast har åtkomst till angivna 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 resulterar oundvikligen i 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. För en stor grupp skapar kontroll av ändringarna en tung belastning på systemet, och det kan göra svarstiden betydligt långsammare.

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. Att öka värdet för avsökningsintervallet resulterar alltså i längre tider för beräkningar av kö- och servicenivåmål.

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 GroupCalcPollingIntervalMilliseconds.

  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 anger du 600000.

  4. Starta om hanteringstjänsten i System Center.

Lösning 2: Du kan använda ett Windows PowerShell skript 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 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 skript för att lägga till typen "användare" i rollen "RoleName". Du måste ändra det här exempelskriptet för din 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 planerar du 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 se visas i en vy. När du skapar en vy baserat på en avancerad objekttyp och när du öppnar vyn frågar Service Manager databasen och en stor mängd data läse. Men mycket lite av de hämtade data visas eller används.

Om du stöter på prestandaproblem med de vyer som du har definierat när du använder avancerade objekttyper i vyer växlar du till att använda vanliga typer. Du kan också skapa egna projektionstyper som bara innehåller de data som du behöver basera en vy på.

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, gruppändringskontrollintervallet 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 ha en acceptabel svarstid i vanliga scenarier.

  • Du bör ha minst 8 CPU-kärnor på den dator som är värd för 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 din 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å att växa automatiskt, särskilt med små steg.

Se Service Manager storlekshjälpverktyget som ingår i dokumentationsuppsättningen för Service Manager-jobbhjälpmedel (SM_job_aids.zip) för att få hjälp med att bedöma 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 en högpresterande databas. 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 hanteringsserverprestanda

Prestanda för Service Manager hanteringsservern påverkas främst av antalet aktiva samtidiga Service Manager-konsoler. Eftersom alla Service Manager roller interagerar 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. Du bör ha minst 4 CPU-kärnor per hanteringsserver, förutsatt att du har 10 till 12 aktiva konsoler per CPU-kärna.

Service Manager konsolprestanda

Prestanda för Service Manager-konsolen påverkas främst av antalet formulär som analytikerna 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 du har vyer som hämtar en stor mängd data behöver du ytterligare RAM-minne. Du bör ha minst en processor på 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 en överdriven resursförbrukning. Service Manager-konsolen cachelagrar aggressivt information i minnet, vilket kan bidra till den totala minnesanvändningen.

Service Manager datalagerdatabasprestanda

Datalagrets prestanda påverkas direkt av olika faktorer, inklusive antalet samtidiga Service Manager hanteringsservrar som skickar data, mängden lagrade data eller datakvarhållningsperioden, dataändringshastigheten och ETL-frekvensen (extrahering, transformering och belastning). 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 informationslagret, om möjligt. Du bör vanligtvis ha minst 8 GB RAM-minne för den dator 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 Service Manager storlekshjälpverktyget som ingår i dokumentationsuppsättningen för Service Manager-jobbhjälpmedel (SM_job_aids.zip) för att utvärdera databasens storlek och skapa databasen med en storlek som är närmare den slutliga storleken, vilket hjälper prestanda genom att minska antalet gånger som databasen måste växa automatiskt.

Service Manager innehåller 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.

serverprestanda för Service Manager informationslager

Prestanda för informationslagerservern 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. Prestanda kommer dock att ha nytta av att ha ytterligare minne för avancerade distributionsscenarier där mer än en Service Manager-hanteringsservern infogar data i informationslagret. Om du måste avväga 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.

Prestanda för självbetjäningsportalen

Self-Service-portalen är utformad för enkel åtkomst till incident- och tjänstbegäranderegistrering. Den är inte utformad för att hantera tusentals användare samtidigt.

Prestandatestning för Self-Service-portalen fokuserades specifikt på vanliga "måndag morgon"-scenarier, för att säkerställa att hundratals användare på måndag morgon kan logga in inom ett intervall på 5 till 10 minuter och öppna incidenter med acceptabla (mindre än 4 till 5 sekunder) 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 stödja 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 en utskalning av ytterligare maskinvara och programvara efter behov. Vi rekommenderar att du inte skapar fler än fem servicenivåmål för en typisk konfiguration på 50 000 datorer Service Manager. Du kan eventuellt skapa fler servicenivåmål. Men eftersom villkoren varierar mycket från organisation till organisation kan Microsoft inte ge någon konkret rekommendation för antalet servicenivåmål som du inte bör överskrida. Om distributionskonfigurationen har sämre prestanda till följd av antalet servicenivåmål rekommenderar vi att du skalar ut med nästa större distributionsscenario, enligt beskrivningen i artikeln Konfigurationer för distributionsscenarier i den här guiden.

Nästa steg