Freigeben über


System Center – Service Manager Leistung

Wichtig

Diese Version von Service Manager hat das Ende des Supports erreicht. Es wird empfohlen, ein Upgrade auf Service Manager 2022 durchzuführen.

Leistung für System Center: Service Manager Serverrollen und -features werden von verschiedenen Faktoren beeinflusst. Im Allgemeinen gibt es drei Bereiche, in denen sich positive und negative Ergebnisse in Service Manager am meisten bemerkbar machen:

  • Service Manager Reaktionsfähigkeit der Konsole. Hierbei handelt es sich um die Zeitdauer von dem Moment an, in dem irgendeine Aktion in der Konsole gestartet wird, bis zu deren Abschluss.

  • Dateneinfügedauer für Connectors. So lange dauert es, bis Service Manager Daten importieren, wenn ein Connector synchronisiert wird.

  • Workflowabschlussdauer. Hierbei handelt es sich um die Zeitdauer, die von Workflows benötigt wird, um irgendeine Aktion automatisch anzuwenden.

Connectorleistung

Die anfängliche Synchronisierung des Connectors kann viel Zeit in Anspruch nehmen. Beispielsweise 8 bis 12 Stunden für eine große anfängliche Synchronisierung mit Configuration Manager. Wenn ein Connector anfänglich synchronisiert wird, können Sie davon ausgehen, dass die Leistung für alle Service Manager Serverrollen und -prozesse in dieser Zeit beeinträchtigt wird. Dies liegt daran, dass Daten sequenziell in die Service Manager Datenbank eingefügt werden, bei der es sich um eine Microsoft SQL Server-Datenbank handelt. Obwohl Sie den anfänglichen Synchronisierungsprozess des Connectors nicht ausführen können, können Sie die anfängliche Synchronisierung planen und sicherstellen, dass der Synchronisierungsprozess gut abgeschlossen ist, bevor Service Manager in Produktion gebracht wird.

Wenn die erste Synchronisierung abgeschlossen ist, Service Manager die Synchronisierung der Unterschiede fortsetzt, die keine messbaren Auswirkungen auf die Leistung haben.

Workflowleistung

Workflows sind automatisch erfolgende Prozesse. Sie umfassen u. a. den Versand von E-Mail-Benachrichtigungen, Change Request-Aktivitäten sowie die automatische Anwendung von Vorlagen.

Im Zusammenhang mit der Workflowleistung gilt Folgendes:

  • Workflows werden normalerweise innerhalb von einer Minute gestartet und beendet. Wenn sich Service Manager Serverrollen unter einer hohen Workload befinden, werden Workflows nicht so schnell wie normal abgeschlossen.

  • Zudem vergrößert sich mit jedem Workflow, den Sie erstellen (beispielsweis in Form eines neuen Benachrichtigungsabonnements), die Systemlast. Je mehr neue Workflows Sie erstellen, desto länger dauert die Ausführung der einzelnen Workflows.

Wenn das System stark ausgelastet ist, beispielsweise wenn eine große Anzahl neuer Incidents erstellt wird, von denen jeder mehrere Workflows generiert, kann dies die Systemleistung negativ beeinflussen.

Auswirkungen der Gruppen-, Warteschlangen- und Benutzerrolle auf die Leistung

Sie sollten Gruppen und Benutzerrollen früh planen. Erstellen Sie Gruppen bedarfsorientiert (d. h. so wenige Gruppen wie möglich), und beschränken Sie den Gruppenbereich auf die Mindestgröße. Anschließend sollten Sie Ihre Datenbank zunächst mit Daten aus Active Directory Domain Services (AD DS), Configuration Manager und System Center Operations Manager auffüllen, bevor Sie Ihre Gruppen erstellen.

Häufig erstellen Administratoren Gruppen, um sicherzustellen, dass Benutzer nur Zugriff auf bestimmte Gruppen haben. Beispiel: Sie möchten eine Teilmenge von Incidents erstellen, die Computer betreffen, welche von den Mitarbeitern der Personalabteilung benutzt werden. Dabei sollen vielleicht nur bestimmte Mitarbeiter zur Anzeige und Bearbeitung der Gruppe „Störungsanfällige Server“ berechtigt sein. In diesem Fall müssten Sie eine Gruppe für alle Benutzer und eine weitere Gruppe für störungsanfällige Computer erstellen und anschließend dafür sorgen, dass es eine Sicherheitsrolle gibt, die Zugang zu beiden Gruppen („Alle Benutzer“ sowie „Störungsanfällige Server“) erhält. Das Erstellen einer Gruppe mit allen Benutzern führt unweigerlich zu Leistungseinbußen, da Service Manager häufig überprüft, ob Änderungen an der Gruppe vorgenommen werden. Standardmäßig erfolgt diese Prüfung alle 30 Sekunden. Für eine große Gruppe führt die Überprüfung auf die Änderungen zu einer hohen Auslastung des Systems und kann die Antwortzeit erheblich verlangsamen.

Lösung 1: Sie können manuell angeben, wie oft Service Manager Auf Gruppenänderungen überprüft, indem Sie einen Registrierungsschlüssel ändern. Wenn Sie beispielsweise die Gruppenprüfungshäufigkeit von 30 Sekunden in 10 Minuten ändern, wird sich hierdurch die Systemleistung deutlich verbessern. Warteschlangen und SLO-Ziele sind jedoch besondere Arten von Gruppen, die dasselbe Abrufintervall für die Gruppenberechnung verwenden. Das Erhöhen des Werts des Abrufintervalls führt also zu längeren Zeiten für Die Berechnung von Warteschlangen- und Dienstebenenzielen.

Achtung

Durch eine fehlerhafte Bearbeitung der Registrierung können schwerwiegende Schäden am System verursacht werden. Bevor Sie Änderungen an der Registrierung vornehmen, sollten Sie alle wichtigen Computerdaten sichern.

So legen Sie das Prüfintervall für Gruppenänderungen manuell fest

  1. Führen Sie „regedit“ aus, und navigieren Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Erstellen Sie einen neuen DWORD-Wert mit dem Namen GroupCalcPollingIntervalMilliseconds.

  3. Geben Sie als Wert das gewünschte Intervall in Millisekunden an. Das Ergebnis wird mit 6 multipliziert. Geben Sie beispielsweise 6000000 ein, um das Intervall auf 10 Minuten festzulegen.

  4. Starten Sie den System Center Management-Dienst neu.

Lösung 2: Sie können ein Windows PowerShell Skript verwenden, um Einer Benutzerrolle Objekte eines Typs wie "Benutzer" hinzuzufügen. Im Wesentlichen kann ein Analyst, der in dieser Rolle angemeldet ist, auf alle Objekte zugreifen, deren Typ "Benutzer" entspricht. Wenn Sie diese Methode verwenden, entfallen die Notwendigkeit einer großen Gruppe ("Alle Benutzer") und die teure Überprüfung, die Service Manager durchführt, um diese Gruppenmitgliedschaft zu ermitteln. Auf dem Service Manager-Verwaltungsserver können Sie das folgende Windows PowerShell-Skript ausführen, um der Rolle "RoleName" den Typ "benutzer" hinzuzufügen. Sie müssen dieses Beispielskript für Ihre Umgebung ändern.

So führen Sie ein Windows PowerShell-Skript aus, um Objekte zu einer Benutzerrolle hinzuzufügen

  • Ändern Sie das folgende Skript nach Bedarf, und führen Sie das Skript anschließend aus:
#  
# 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."  
}  

Anzeigen der Leistung

Wenn Sie Ansichten erstellen, sollten Sie möglichst "typische" Klassen im System verwenden. Die meisten Objektklassen , z. B. Incident Management, haben zwei Typen: "typisch" und "erweitert". Die Objekttyp „typical“ (typisch) umfasst einfache Verweise auf eine kleine Teilmenge von elementbezogenen Daten. Der Typ „advanced“ (erweitert) umfasst viele komplexe Verweise auf elementbezogene Daten. Typische Typen sind einfache Projektionen, erweiterte Typen sind komplexe Projektionen. Die meisten erweiterten Objekttypen werden verwendet, um verschiedene Felder in Formularen aufzufüllen, die normalerweise nicht in einer Ansicht angezeigt werden sollen. Wenn Sie eine Ansicht basierend auf einem erweiterten Objekttyp erstellen und wenn Sie die Ansicht öffnen, fragt Service Manager die Datenbank ab, und eine große Menge von Daten wird gelesen. Allerdings werden nur sehr wenige der abgerufenen Daten angezeigt oder verwendet.

Wenn Bei der Verwendung von erweiterten Objekttypen in Ansichten Leistungsprobleme mit den von Ihnen definierten Ansichten auftreten, wechseln Sie zu typischen Typen. Alternativ können Sie eigene Projektionstypen erstellen, die nur die Daten enthalten, auf denen Sie eine Ansicht basieren müssen.

Service Manager Datenbankleistung

Die Leistung der Service Manager Datenbank wird direkt durch verschiedene Faktoren beeinflusst, z. B. die Anzahl gleichzeitiger Service Manager Konsolen, die Daten lesen oder schreiben, das Gruppenänderungsüberprüfungsintervall und daten, die von Connectors eingefügt werden. Weitere Informationen hierzu finden Sie weiter hinten in diesem Dokument. Hier einige wichtige Punkte:

  • Sie sollten mindestens 8 Gigabyte (GB) RAM für den Verwaltungsserver haben, der die Service Manager Datenbank hostet, damit Sie in typischen Szenarien eine akzeptable Antwortzeit haben können.

  • Auf dem Computer, auf dem die Service Manager-Datenbank gehostet wird, sollten mindestens 8 CPU-Kerne vorhanden sein.

  • Sie können eine bessere Datenbankleistung erzielen, indem Sie Protokolldateien und Datendateien, sofern möglich, auf getrennten physischen Datenträgern speichern. Sie können weitere Vorteile erzielen, indem Sie Ihre tempdb auf ein anderes physisches RAID-Laufwerk als das der Service Manager-Datenbank verschieben. Hosten Sie Ihre Service Manager-Datenbank möglichst auf einem RAID 1+0-Plattensystem.

  • Die Leistung kann sich negativ auswirken, wenn die Service Manager Datenbank mit einer kleineren Größe erstellt wird und auf die automatische Vergrößerung festgelegt ist, insbesondere durch kleine Inkremente.

Hilfe bei der Bewertung der Größe der Datenbank finden Sie im Tool Service Manager Größenhilfsprogramm, das im Dokumentationssatz Service Manager Auftragshilfen (SM_job_aids.zip) enthalten ist, und erstellen Sie die Datenbank mit einer Größe, die näher an der endgültigen Größe liegt. Dies trägt zur Leistung bei, indem die Anzahl der Automatischen Vergrößerungen der Datenbank verringert wird.

Ebenso gelten alle anderen bewährten Methoden für eine leistungsstarke Datenbank. Wenn Sie beispielsweise ein übergeordnetes Datenträgersubsystem nutzen können, können Sie davon profitieren, die Tabellengruppen in den jeweiligen Dateigruppen aufzuteilen und sie auf ein anderes physisches Laufwerk zu verschieben.

Service Manager-Verwaltungsserverleistung

Die Leistung des Service Manager-Verwaltungsservers wird in erster Linie durch die Anzahl aktiver gleichzeitiger Service Manager Konsolen beeinflusst. Da alle Service Manager Rollen mit dem Verwaltungsserver interagieren, sollten Sie zusätzliche Verwaltungsserver hinzufügen, wenn Sie eine große Anzahl gleichzeitiger Konsolen planen. Der Verwaltungsserver sollte über 8 GB RAM verfügen. Sie sollten mindestens 4 CPU-Kerne pro Verwaltungsserver haben, vorausgesetzt, Sie verfügen über 10 bis 12 aktive Konsolen pro CPU-Kern.

Service Manager Konsolenleistung

Die Leistung der Service Manager Konsole wird in erster Linie durch die Anzahl von Formularen, die Ihre Analysten in der Regel geöffnet haben, und die Datenmenge, die von Ansichten abgerufen wird, beeinflusst. Auf dem Computer, auf dem die Service Manager Konsole installiert ist, sollten Sie über 4 GB RAM verfügen. Wenn Sie Ansichten haben, die eine große Menge an Daten abrufen, benötigen Sie zusätzlichen RAM. Sie sollten mindestens über eine 4-Kern-CPU für den Computer verfügen, auf dem die Service Manager Konsole installiert ist. Da es sich bei der Service Manager-Konsole um eine Endbenutzeranwendung handelt, wird empfohlen, sie bei übermäßigem Ressourcenverbrauch neu zu starten. Die Service Manager Konsole speichert Informationen aggressiv im Arbeitsspeicher zwischen, was zur Gesamtauslastung des Arbeitsspeichers beitragen kann.

Service Manager Data Warehouse-Datenbankleistung

Die Leistung des Data Warehouse wird direkt durch verschiedene Faktoren beeinflusst, z. B. die Anzahl gleichzeitiger Service Manager Verwaltungsserver, die Daten senden, die Menge der gespeicherten Daten oder der Zeitraum der Datenaufbewahrung, die Änderungsrate der Daten und die Häufigkeit der Extraktion, Transformation und Auslastung (ETL). Die im Data Warehouse gespeicherte Datenmenge nimmt im Laufe der Zeit immer weiter zu. Archivieren Sie daher auf jeden Fall alle nicht benötigen Daten. Ein weiterer Faktor, der die Data Warehouse-Leistung beeinflusst, ist die BatchSize-Eigenschaft von ETL-Prozessen.

Sie können eine bessere Leistung erzielen, indem Sie Protokolldateien und Datendateien auf getrennten physischen Datenträgern speichern. Allerdings sollten Sie es vermeiden, mehr als eine Protokolldatei auf einem Datenträger zu speichern. Ebenso können Sie einen besseren Durchsatz erzielen, indem Sie tempdb nicht auf demselben physischen Datenträger ablegen wie die anderen Datenbanken. Weitere Vorteile erzielen Sie, wenn Sie die verschiedenen Datenbanken ebenfalls auf eigenen physischen Datenträgern ablegen. Hosten Sie Ihr Data Warehouse möglichst auf einem RAID 1+0-Plattensystem. Auf dem Computer, auf dem die Data Warehouse-Datenbanken installiert werden, sollten grundsätzlich mindestens 8 GB RAM verfügbar sein. Wenn Sie über zusätzliche Data Warehouse-Datenquellen aus Operations Manager oder Configuration Manager verfügen, sollten Sie den ARBEITSSPEICHER für die Datenbanken erhöhen. Eine Speichererweiterung empfiehlt sich für den Computer, auf dem SQL Server ausgeführt und der zum Hosten des Data Warehouse verwendet wird, insbesondere dann, wenn sich die Datamart- und die Repositorydatenbank auf demselben Server befinden. Wenn Sie jedoch über 4.000 oder weniger Computer in Ihrer Bereitstellungstopologie verfügen, sind 4 GB ausreichend. Der Computer, auf dem die Data Warehouse-Datenbank installiert ist, sollte über mindestens 8 CPU-Kerne verfügen. Zusätzliche Kerne tragen zu einer besseren ETL- und Berichtsleistung bei.

Es kann sich ungünstig auf die Leistung auswirken, wenn alle Datenbanken des Systems zunächst als kleinere Datenbanken erstellt und für eine automatische Vergrößerung konfiguriert werden – insbesondere, wenn kleine Zuwachsschritte vereinbart werden. Sehen Sie sich das Tool Service Manager Größenhilfsprogramm an, das im Dokumentationssatz Service Manager Auftragshilfen (SM_job_aids.zip) enthalten ist, um die Größe der Datenbank zu bewerten und die Datenbank mit einer Größe zu erstellen, die näher an der endgültigen Größe liegt. Dadurch wird die Leistung verbessert, indem die Anzahl der Automatischen Vergrößerungen der Datenbank reduziert wird.

Service Manager umfasst integrierte Unterstützung für Dateigruppen. Sie können hiervon profitieren, indem Sie die Dateigruppen auf verschiedenen Festplattenlaufwerken platzieren. Weitere Informationen zu bewährten Methoden für Dateigruppen finden Sie in der SQL Server-Dokumentation.

Service Manager Data Warehouse-Serverleistung

Die Leistung des Data Warehouse-Servers wird durch die Anzahl Service Manager Verwaltungsserver, die für das Data Warehouse registriert sind, die Größe Ihrer Bereitstellung und die Anzahl der Datenquellen beeinflusst. Allgemein gilt, dass für den Data Warehouse-Server mindestens 8 GB RAM verfügbar sein sollten. Die Leistung profitiert jedoch von zusätzlichem Arbeitsspeicher für erweiterte Bereitstellungsszenarien, in denen mehrere Service Manager Verwaltungsserver Daten in das Data Warehouse einfügen. Wenn Sie bei der Leistung Kompromisse machen müssen, sollte der Speicher für den Computer, auf dem SQL Server ausgeführt wird, oberste Priorität haben. Um Leistungsprobleme zu vermeiden, sollten Sie über mindestens 8 CPU-Kerne verfügen.

Leistung des Self Service-Portals

Das Self-Service-Portal ist für den einfachen Zugriff auf die Einreichung von Incident- und Dienstanforderungen konzipiert. Es ist nicht für die gleichzeitige Behandlung von Tausenden von Benutzern konzipiert.

Leistungstests für das Self-Service-Portal konzentrierten sich auf typische "Montagmorgen"-Szenarien, um sicherzustellen, dass sich am Montagmorgen Hunderte von Benutzern innerhalb einer Zeitspanne von 5 bis 10 Minuten anmelden und Vorfälle mit akzeptablen (weniger als 4 bis 5 Sekunden) Reaktionszeiten öffnen können. Dieses Ziel wurde mit der in diesem Dokument empfohlenen Mindesthardwarekonfiguration erreicht.

Objektive Leistung auf Serviceebene

Es gibt keine bestimmte Anzahl von Zielen auf Servicelevel, die Service Manager unterstützt. So wird im Fall eines Unternehmens mit normalerweise wenigen Incidents eine größere Anzahl von Servicelevel-Zielpunkten unterstützt. Bei einer umfangreicheren Incidentmenge muss dagegen u. U. die Anzahl der Servicelevel-Zielpunkte reduziert werden, sofern keine entsprechende Hard- und Softwareskalierung stattfindet. Es wird empfohlen, nicht mehr als fünf Servicelevelziele für eine typische Konfiguration mit 50.000 Computern Service Manager zu erstellen. Möglicherweise können Sie weitere Servicelevel-Zielpunkte erstellen. Da die Bedingungen jedoch von organization zu organization stark variieren, kann Microsoft keine konkrete Empfehlung für die Anzahl der Ziele auf Servicelevel geben, die Sie nicht überschreiten sollten. Wenn Ihre Bereitstellungskonfiguration aufgrund der Anzahl von Servicelevelzielen unter einer schlechten Leistung leidet, empfehlen wir Ihnen, das nächstgrößere Bereitstellungsszenario zu verwenden, wie im Artikel Konfigurationen für Bereitstellungsszenarien dieses Handbuchs beschrieben.

Nächste Schritte