Dela via

System Center – Service Manager-prestanda

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

  • Service Manager-konsolens svarstider. Det här är den tid det tar från det ögonblick du vidtar någon form av åtgärd i konsolen tills den är klar.

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

  • Arbetsflödets slutförandetid. Det här är den tid det tar för arbetsflöden att automatiskt tillämpa någon form av åtgärd.

Den här artikeln beskriver hur prestanda för System Center – Service Manager-serverroller och -funktioner påverkas av olika faktorer.

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 anslutning synkroniseras initialt kan du förvänta dig försämrad prestanda för alla Service Manager-serverroller och processer under den här tiden. Detta inträffar på grund av 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 sä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 inträffar. De inkluderar att skicka e-postaviseringar, aktiveringen av nästa steg i en ändringsbegäran och processen med att automatiskt tillämpa en mall.

Överväganden för arbetsflödesprestanda omfattar följande:

  • Normalt startar och slutförs arbetsflöden inom en minut. När Service Manager-serverrollerna är under en tung arbetsbelastning slutförs inte arbetsflödena lika snabbt som normalt.

  • När du skapar nya arbetsflöden, till exempel en ny meddelandeprenumeration, läggs dessutom ytterligare belastning på systemet. När antalet nya arbetsflöden som du skapar ökar ökar också den tid det tar för varje arbetsflöde att kö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

Du bör planera för grupper och användarroller tidigt. Du bör skapa grupper sparsamt och skapa dem för minsta möjliga omfång. Sedan bör du först fylla 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 till exempel vill skapa en delmängd av incidenter, till exempel incidenter som påverkar datorer som används av personalavdelningen. I det här scenariot kanske du bara vill att specifik personal ska kunna visa eller ändra gruppen känsliga servrar. Om du sedan vill aktivera den här typen för åtkomst måste du skapa en grupp för alla användare och en grupp för känsliga datorer och sedan se till att en säkerhetsroll har åtkomst till både grupperna Alla användare och 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 sker en gång var 30:e sekund som standard. 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. Om du till exempel ändrar gruppkontrollfrekvensen från 30 sekunder till 10 minuter ökar du prestanda avsevärt. Köer och servicenivåmål är dock särskilda typer av grupper som använder samma avsökningsintervall för gruppberäkning. Om du ökar värdet för avsökningsintervallet blir det därför längre tider för beräkningar på kö- och servicenivåmål.

Försiktighet

Om registret redigeras felaktigt kan systemet skadas allvarligt. Innan du gör ändringar i registret bör du säkerhetskopiera alla värdefulla data på datorn.

Ange kontrollintervallet för gruppändring manuellt

Om du vill ange kontrollintervallet för gruppändring manuellt följer du dessa steg:

  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. För dess värde 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 System Center Management-tjänsten.

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ör ett Windows PowerShell-skript för att lägga till objekt i en användarroll

  • Ändra följande skript efter behov och kör det sedan:
#  
# 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". Den typiska objekttypen innehåller enkla referenser till en liten delmängd data som är relaterade till ett objekt. Den avancerade typen innehåller många komplexa referenser till data som är relaterade till ett objekt. Typiska typer är enkla projektioner. avancerade typer ä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 öppnar vyn, gör Service Manager en förfrågan till databasen och en stor mängd data läses. 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 endast 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. Mer information finns i det här dokumentet. 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å datorn som är värd för Service Manager-databasen.

  • Du kan uppnå bättre databasprestanda genom att separera loggfiler och datafiler till separata fysiska diskar, om möjligt. Du kan uppnå ytterligare fördelar genom att flytta tempdb till en annan fysisk RAID-enhet än servicehanterarens databas. 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å automatisk tillväxt, särskilt med små steg.

Se servicehanterarens storlekshjälpverktyg som ingår i Service Manager-jobbhjälpmedel dokumentationsuppsättning (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 prestanda 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.

Prestanda för Service Managers hanteringsserver

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

Prestanda för Service Manager-konsolen

Prestanda för Service Manager-konsolen påverkas främst av antalet 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 du har vyer som hämtar en stor mängd data behöver du ytterligare RAM-minne. 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 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 inläsning). Mängden data som lagras i informationslagret ökar med tiden. Det är viktigt att du arkiverar onödiga data. En annan faktor som påverkar datalagerprestanda är inställningen BatchSize för ETL-processer.

Du kan få bättre prestanda genom att separera loggfiler och datafiler till separata fysiska diskar. Du bör dock undvika att placera mer än en loggfil per disk. På samma sätt kan du uppnå bättre dataflöde genom att placera tempdb på en annan fysisk disk än de andra databaserna. Slutligen kan du dra nytta av att placera de olika databaserna på sina 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 den dator där informationslagrets databaser är installerade. Om du har ytterligare datakällor för informationslager från Operations Manager eller Configuration Manager bör du öka mängden RAM-minne för databaserna. Du kommer att dra nytta av mer minne på datorn 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. Du bör ha minst 8 CPU-kärnor på datorn där informationslagerdatabasen är installerad. Ytterligare kärnor hjälper både ETL- och rapportprestanda.

Prestanda kan påverkas negativt om alla databaser i systemet skapas med en mindre storlek och är inställda på automatisk tillväxt, särskilt med små steg. Se servicehanterarens storlekshjälpverktyg som ingår i Service Manager-jobbhjälpmedel dokumentationsuppsättning (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.

Prestanda för Service Manager datalagertjänst

Prestanda för datalagerservern 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 gynnas genom att ha ytterligare minne för avancerade distributionsscenarier där mer än en Service Manager-hanteringsserver infogar data i informationslagret. Om du måste avväga prestanda bör din högsta prioritet vara för minne för den dator som kör SQL Server. Du bör ha minst 8 CPU-kärnor för att förhindra prestandaproblem.

Prestanda för självbetjäningsportalen

Self-Service Portal ä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 fokuserade på typiska "måndag morgon"-scenarier, särskilt för att säkerställa att hundratals användare på måndagsmorgonen kan logga in inom ett intervall på 5 till 10 minuter och öppna incidenter med acceptabla (mindre än 4 till 5 sekunder) svarstider. Det här målet uppnåddes med den minsta maskinvara som rekommenderas i det här dokumentet.

Servicenivåmålets prestanda

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 utskalning av ytterligare maskinvara och programvara efter behov. Vi rekommenderar att du inte skapar fler än fem servicenivåmål för en typisk Service Manager-konfiguration på 50 000 datorer. Du kan eventuellt skapa fler servicenivåmål. Eftersom förhållandena varierar kraftigt från organisation till organisation kan Microsoft dock inte ge någon konkret rekommendation för antalet servicenivåmål som du inte bör överskrida. Om distributionskonfigurationen lider av dåliga prestanda till följd av antalet servicenivåmål rekommenderar vi att du skalar ut med hjälp av nästa större distributionsscenario, enligt beskrivningen i artikeln Configurations for Deployment Scenarios i den här guiden.

Nästa steg

Mer information om maskinvaru- och programvarukonfigurationer för Service Manager-distributionsscenarier finns i Rekommenderade scenarier för distributionstopologi.