Udostępnij za pośrednictwem

System Center — wydajność Service Manager

  • Artykuł

Ważne

Ta wersja Service Manager osiągnęła koniec wsparcia technicznego. Zalecamy uaktualnienie do wersji Service Manager 2022.

Wydajność programu System Center — Service Manager role i funkcje serwera mają wpływ na różne czynniki. Ogólnie rzecz biorąc, istnieją trzy obszary, w których pozytywne i negatywne wyniki są najbardziej zauważalne w Service Manager:

  • Service Manager czasu odpowiedzi konsoli. Jest to okres od momentu zainicjowania czynności przez użytkownika do ukończenia jej przez konsolę.

  • Czas umieszczenia danych dla łączników. Jest to czas potrzebny na Service Manager importowania danych podczas synchronizacji łącznika.

  • Czas ukończenia przepływu pracy. Jest to okres, jaki trwa automatyczne zastosowanie czynności przez przepływ pracy.

Wydajność łącznika

Synchronizacja początkowa łącznika może zająć dużo czasu; na przykład od 8 do 12 godzin dla dużej synchronizacji początkowej z Configuration Manager. Początkowo łącznik synchronizuje się z wydajnością dla wszystkich Service Manager ról i procesów serwera w tym czasie. Dzieje się tak z powodu sposobu sekwencyjnego wstawiania danych do bazy danych Service Manager, która jest bazą danych microsoft SQL Server. Mimo że nie można przyspieszyć procesu synchronizacji początkowej łącznika, można zaplanować synchronizację początkową i upewnić się, że proces synchronizacji zakończy się znacznie przed wprowadzeniem Service Manager do środowiska produkcyjnego.

Po zakończeniu synchronizacji początkowej Service Manager kontynuuje synchronizowanie różnic, które nie mają mierzalnego wpływu na wydajność.

Wydajność przepływu pracy

Przepływy pracy to procesy realizowane automatycznie. Obejmują one między innymi wysyłanie wiadomości e-mail z powiadomieniami, kolejny krok aktywacji żądania zmiany i automatyczne stosowanie szablonu.

Na wydajność przepływów pracy wpływają następujące czynniki:

  • Zwykle przepływy pracy rozpoczynają się i kończą w ciągu jednej minuty. Gdy Service Manager role serwera znajdują się w dużym obciążeniu, przepływy pracy nie są wykonywane tak szybko, jak zwykle.

  • Ponadto tworzenie nowych przepływów pracy, takich jak nowa subskrypcja powiadomień, powoduje dodatkowe obciążenie systemu. Wraz ze wzrostem liczby tworzonych nowych przepływów pracy, wydłuża się czas wykonywania każdego przepływu.

Gdy system jest obciążony dużym obciążeniem — jeśli na przykład tworzona jest duża liczba nowych zdarzeń, a każde zdarzenie generuje wiele przepływów pracy — może to mieć negatywny wpływ na wydajność.

Wpływ grupy, kolejki i roli użytkownika na wydajność

Planowanie grup i ról użytkowników należy wykonać na wczesnym etapie. Grupy należy tworzyć oszczędnie i dla najmniejszego możliwego zakresu. Następnie należy najpierw wypełnić bazę danych danymi z Active Directory Domain Services (AD DS), Configuration Manager i System Center Operations Manager przed utworzeniem grup.

Administratorzy często tworzą grupy w celu zapewnienia, że użytkownicy mają dostęp tylko do określonych grup. Scenariusz może na przykład zakładać utworzenie podzbioru zdarzeń, takich jak zdarzenia mające wpływ na komputery używane przez pracowników działu kadr. W tym scenariuszu tylko określony personel ma mieć możliwość wyświetlania i modyfikowania grupy Serwery danych poufnych. Aby umożliwić dostęp tego rodzaju, trzeba by utworzyć grupę wszystkich użytkowników i grupę komputerów danych poufnych, a następnie zapewnić dostęp roli zabezpieczeń do grup Wszyscy użytkownicy i Serwery danych poufnych. Nieuchronnie utworzenie grupy zawierającej wszystkich użytkowników powoduje wpływ na wydajność, ponieważ Service Manager często sprawdza, czy istnieją zmiany w grupie. To sprawdzanie jest wykonywane domyślnie co 30 sekund. W przypadku dużej grupy sprawdzanie zmian powoduje duże obciążenie systemu i może znacznie spowolnić czas odpowiedzi.

Rozwiązanie 1: Możesz ręcznie określić, jak często Service Manager sprawdza zmiany grupy, modyfikując klucz rejestru. Na przykład zmiana częstotliwości sprawdzania grupy z wartości co 30 sekund na co 10 minut pozwoli na znaczną poprawę wydajności. Kolejki i docelowe poziomy usługi są jednak specjalnymi rodzajami grup, które używają tego samego interwału sondowania obliczeń grupy. Dlatego zwiększenie wartości interwału sondowania powoduje dłuższe czasy obliczeń celu kolejki i poziomu usług.

Przestroga

Niepoprawne edytowanie rejestru może spowodować poważne uszkodzenie systemu. Przed wprowadzeniem zmian w rejestrze należy wykonać kopię zapasową wszystkich cennych danych, które znajdują się na komputerze.

Aby ręcznie określić interwał sprawdzania zmian grupy

  1. Uruchom polecenie Regedit i przejdź do HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Utwórz nową wartość DWORD o nazwie GroupCalcPollingIntervalMilliseconds.

  3. Jako jej wartość podaj interwał w milisekundach. Wynik jest mnożony przez 6. Aby na przykład ustawić interwał na 10 minut, wprowadź wartość 600000.

  4. Uruchom ponownie usługę System Center Management.

Rozwiązanie 2. Do roli użytkownika można użyć skryptu Windows PowerShell, aby dodać obiekty typu, takie jak "Użytkownicy". Zasadniczo analityk, który jest zalogowany w tej roli, może uzyskać dostęp do wszystkich obiektów, które mają typ równy "Użytkownik". Jeśli używasz tej metody, eliminujesz konieczność posiadania dużej grupy ("Wszyscy użytkownicy") i kosztownego sprawdzenia, czy Service Manager wykonać w celu określenia tego członkostwa w grupie. Na serwerze zarządzania Service Manager można uruchomić następujący skrypt Windows PowerShell, aby dodać typ "użytkownik" do roli "RoleName". Musisz zmodyfikować ten przykładowy skrypt dla środowiska.

Aby uruchomić skrypt Windows PowerShell dodający obiekty do roli użytkownika

  • Zmodyfikuj odpowiednio następujący skrypt, a następnie uruchom go:
#  
# 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."  
}

Wyświetl wydajność

Podczas tworzenia widoków zaplanuj używanie "typowych" klas w systemie, jeśli jest to możliwe. Większość klas obiektów — na przykład zarządzanie zdarzeniami — ma dwa typy: "typowe" i "zaawansowane". Typowy typ obiektu zawiera proste odwołania do małego podzbioru danych związanych z elementem. Typ zaawansowany zawiera wiele złożonych odwołań do danych związanych z elementem. Typy typowe są prostymi projekcjami, natomiast typy zaawansowane to projekcje złożone. Większość zaawansowanych typów obiektów służy do wypełniania różnych pól w formularzach, które normalnie nie powinny być wyświetlane w widoku. Za każdym razem, gdy utworzysz widok na podstawie zaawansowanego typu obiektu i po otwarciu widoku, Service Manager wysyła zapytanie do bazy danych, a duża ilość danych jest odczytywana. Jednak bardzo mało pobranych danych jest wyświetlanych lub używanych.

Jeśli wystąpią problemy z wydajnością widoków zdefiniowanych podczas korzystania z zaawansowanych typów obiektów w widokach, przełącz się na typowe typy. Alternatywnie możesz utworzyć własne typy projekcji, które zawierają tylko dane potrzebne do oparcia widoku.

wydajność bazy danych Service Manager

Wydajność bazy danych Service Manager ma bezpośredni wpływ na różne czynniki, w tym liczbę współbieżnych konsol Service Manager, które odczytują lub zapisują dane, interwał sprawdzania zmian grupy i dane wstawione przez łączniki. Więcej informacji na ten temat można znaleźć w tym dokumencie. Oto kilka najważniejszych informacji:

  • W typowych scenariuszach powinien istnieć co najmniej 8 gigabajtów (GB) pamięci RAM dla serwera zarządzania, który hostuje bazę danych Service Manager, aby w typowych scenariuszach można było uzyskać akceptowalny czas odpowiedzi.

  • Na komputerze hostowym bazy danych Service Manager powinna znajdować się co najmniej 8 rdzeni procesora CPU.

  • Lepszą wydajność bazy danych można uzyskać przez umieszczenie plików dziennika i plików danych na różnych dyskach fizycznych (jeśli jest to możliwe). Możesz uzyskać dodatkowe korzyści, przenosząc bazę danych tempdb na inny fizyczny dysk RAID niż baza danych Service Manager. Jeśli to możliwe, użyj systemu dysków RAID 1+0 do hostowania bazy danych Service Manager.

  • Wydajność może mieć negatywny wpływ, jeśli baza danych Service Manager zostanie utworzona z mniejszym rozmiarem i zostanie ustawiona na automatyczne zwiększanie, zwłaszcza przez małe przyrosty.

Aby uzyskać pomoc dotyczącą oceny rozmiaru bazy danych, zapoznaj się z Service Manager narzędziem pomocnika, które znajduje się w zestawie pomocy Service Manager zadań (SM_job_aids.zip), aby uzyskać pomoc dotyczącą oceny rozmiaru bazy danych i utwórz bazę danych o rozmiarze zbliżonym do rozmiaru końcowego. Pomoże to zwiększyć wydajność, zmniejszając liczbę prób automatycznego zwiększania bazy danych.

Podobnie wszystkie inne najlepsze rozwiązania dotyczące bazy danych o wysokiej wydajności również mają zastosowanie. Jeśli na przykład możesz skorzystać z doskonałego podsystemu dysków, możesz podzielić grupy tabel w odpowiednich grupach plików i przenieść je na inny dysk fizyczny.

wydajność serwera zarządzania Service Manager

Wydajność serwera zarządzania Service Manager ma wpływ głównie na liczbę aktywnych równoczesnych konsol Service Manager. Ponieważ wszystkie role Service Manager współdziałają z serwerem zarządzania, rozważ dodanie dodatkowych serwerów zarządzania, jeśli planujesz mieć dużą liczbę równoczesnych konsol. Serwer zarządzania powinien mieć 8 GB pamięci RAM. Należy mieć co najmniej 4 rdzenie procesora CPU na serwer zarządzania, przy założeniu, że masz od 10 do 12 aktywnych konsol na rdzeń procesora CPU.

wydajność konsoli Service Manager

Wydajność konsoli Service Manager ma wpływ głównie na liczbę formularzy, które analitycy zwykle mają otwarte, oraz ilość danych pobieranych przez widoki. Na komputerze, na którym jest zainstalowana konsola Service Manager, powinna mieć 4 GB pamięci RAM. Jeśli masz widoki pobierające dużą ilość danych, potrzebujesz dodatkowej pamięci RAM. Na komputerze, na którym zainstalowano konsolę Service Manager, należy mieć co najmniej 4-rdzeniowy procesor CPU. Ponieważ konsola Service Manager jest aplikacją użytkownika końcowego, zalecamy jej ponowne uruchomienie w przypadku wystąpienia nadmiernego użycia zasobów. Konsola Service Manager agresywnie buforuje informacje w pamięci, co może przyczynić się do ogólnego użycia pamięci.

wydajność bazy danych magazynu danych Service Manager

Wydajność magazynu danych ma bezpośredni wpływ na różne czynniki, w tym liczbę współbieżnych serwerów zarządzania Service Manager wysyłających dane, ilość przechowywanych danych lub okres przechowywania danych, szybkość zmian danych oraz częstotliwość wyodrębniania, przekształcania i ładowania (ETL). Ilość danych przechowywanych w magazynie danych rośnie z czasem. Ważne jest zapewnienie archiwizacji niepotrzebnych danych. Innym czynnikiem wpływającym na wydajność magazynu danych jest ustawienie BatchSize procesów ETL.

Lepszą wydajność można uzyskać przez umieszczenie plików dziennika i plików danych na różnych dyskach fizycznych. Należy jednak unikać umieszczania więcej niż jednego pliku dziennika na jednym dysku. Podobnie lepszą przepustowość można uzyskać dzięki umieszczeniu bazy tempdb na innym dysku fizycznym niż pozostałe bazy danych. Można też umieścić różne bazy danych na różnych dyskach fizycznych. Jeśli to możliwe, użyj systemu dysków RAID 1+0 do hostowania magazynu danych. Na komputerze, na którym są zainstalowane bazy danych magazynu danych, należy mieć co najmniej 8 GB pamięci RAM. Jeśli masz dodatkowe źródła danych magazynu danych z programu Operations Manager lub Configuration Manager, należy zwiększyć ilość pamięci RAM dla baz danych. Będziesz korzystać z większej ilości pamięci na komputerze z systemem SQL Server hostujących magazyn danych, a nawet bardziej, jeśli bazy danych Datamart i Repository znajdują się na tym samym serwerze. Jeśli jednak masz 4000 lub mniej komputerów w topologii wdrożenia, wystarczy 4 GB. Komputer, na którym zainstalowana jest baza danych magazynu danych, powinien być wyposażony w procesor o co najmniej 8 rdzeniach. Dodatkowe rdzenie poprawią wydajność operacji ETL i generowania raportów.

Negatywny wpływ na wydajność może mieć utworzenie wszystkich baz danych w systemie o małym rozmiarze i ustawienie ich automatycznego przyrostu (zwłaszcza w małych odstępach). Zapoznaj się z narzędziem pomocnika określania rozmiaru Service Manager, które znajduje się w zestawie dokumentacji pomocy zadań Service Manager (SM_job_aids.zip), aby ocenić rozmiar bazy danych i utworzyć bazę danych o rozmiarze bliżej końcowego rozmiaru, co pomoże zwiększyć wydajność przez zmniejszenie liczby przypadków automatycznego zwiększania bazy danych.

Service Manager obejmuje wbudowaną obsługę grup plików. Można z tego skorzystać, umieszczając grupy plików na oddzielnych dyskach twardych. Aby uzyskać więcej informacji na temat najlepszych rozwiązań dotyczących grupy plików, zobacz dokumentację SQL Server.

wydajność serwera magazynu danych Service Manager

Wydajność serwera magazynu danych ma wpływ na liczbę serwerów zarządzania Service Manager zarejestrowanych w magazynie danych, rozmiar wdrożenia i liczbę źródeł danych. Zazwyczaj dla serwera magazynu danych powinno istnieć co najmniej 8 GB pamięci RAM. Jednak wydajność przyniesie korzyści dzięki dodatkowej pamięci dla zaawansowanych scenariuszy wdrażania, w których więcej niż jeden serwer zarządzania Service Manager wstawia dane do magazynu danych. Jeśli musisz wymienić wydajność, najwyższy priorytet powinien być dla pamięci dla komputera z systemem SQL Server. Aby uniknąć problemów z wydajnością, serwer powinien być wyposażony w co najmniej 8 rdzeni procesora.

Wydajność portalu samoobsługowego

Portal Self-Service jest przeznaczony do łatwego dostępu do zgłoszenia zdarzeń i żądań obsługi. Nie jest przeznaczony do obsługi tysięcy użytkowników jednocześnie.

Testowanie wydajności dla portalu Self-Service koncentruje się na typowych scenariuszach "poniedziałek rano", aby upewnić się, że w poniedziałek rano setki użytkowników mogą zalogować się w ciągu od 5 do 10 minut i otwarte zdarzenia z akceptowalnym czasem odpowiedzi (mniej niż 4 do 5 sekund). Ten cel osiągnięto z przy minimalnych wymaganiach sprzętowych zalecanych w tym dokumencie.

Wydajność celu poziomu usług

Nie ma określonej liczby celów poziomu usług, które Service Manager obsługuje. Jeśli na przykład organizacja zwykle ma kilka zdarzeń, może obsługiwać więcej celów na poziomie usług, niż w przeciwnym razie może być w stanie. Jednak większy wolumen zdarzeń może wymagać mniejszej liczby celów poziomu usług lub skalowania w poziomie dodatkowego sprzętu i oprogramowania zgodnie z potrzebami. Zalecamy utworzenie nie więcej niż pięciu celów poziomu usług dla typowej konfiguracji 50 000 komputerów Service Manager. Być może można utworzyć więcej celów na poziomie usług. Jednak ze względu na to, że warunki różnią się znacznie w zależności od organizacji, firma Microsoft nie może przedstawić konkretnego zalecenia dla liczby celów poziomu usług, których nie należy przekraczać. Jeśli konfiguracja wdrożenia cierpi na niską wydajność w wyniku liczby celów poziomu usług, zalecamy skalowanie w poziomie przy użyciu następnego większego scenariusza wdrażania, zgodnie z opisem w artykule Configurations for Deployment Scenarios (Konfiguracje scenariuszy wdrażania ) tego przewodnika.

Następne kroki