System Center — wydajność programu Service Manager
Wydajność ról i funkcji serwera programu System Center — Service Manager ma wpływ na różne czynniki. Ogólnie rzecz biorąc, istnieją trzy obszary, w których najbardziej zauważalna jest pozytywna i negatywna wydajność w programie Service Manager:
Czas odpowiedzi konsoli programu Service Manager. Jest to czas potrzebny od momentu podjęcia jakiejś akcji w konsoli do momentu jego ukończenia.
Czas wstawiania danych dla łączników. Tak długo trwa importowanie danych przez program Service Manager podczas synchronizacji łącznika.
Czas ukończenia przepływu pracy. Jest to czas potrzebny na automatyczne zastosowanie pewnego rodzaju akcji przez przepływy 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 programem Configuration Manager. W ramach synchronizacji łącznika początkowo można oczekiwać, że wydajność będzie cierpieć na wszystkie role i procesy serwera programu Service Manager w tym czasie. Dzieje się tak z powodu sposobu, w jaki dane są wstawiane sekwencyjnie do bazy danych programu Service Manager, która jest bazą danych programu Microsoft SQL Server. Mimo że nie można przyspieszyć początkowego procesu synchronizacji łącznika, można zaplanować synchronizację początkową i upewnić się, że proces synchronizacji zakończy się dobrze przed wprowadzeniem programu Service Manager do środowiska produkcyjnego.
Po zakończeniu synchronizacji początkowej program Service Manager kontynuuje synchronizowanie różnic, które nie mają mierzalnego wpływu na wydajność.
Wydajność przepływu pracy
Przepływy pracy to procesy automatyczne, które występują. Obejmują one wysyłanie powiadomień e-mail, następny krok aktywowania żądania zmiany i automatyczne stosowanie szablonu.
Zagadnienia dotyczące wydajności przepływu pracy obejmują następujące kwestie:
Zwykle przepływy pracy rozpoczynają się i kończą w ciągu jednej minuty. Gdy role serwera programu Service Manager znajdują się w dużym obciążeniu, przepływy pracy nie są wykonywane tak szybko, jak zwykle.
Ponadto podczas tworzenia nowych przepływów pracy, takich jak nowa subskrypcja powiadomień, dodatkowe obciążenie jest umieszczane w systemie. Wraz ze wzrostem liczby tworzonych nowych przepływów pracy zwiększa się również czas potrzebny na uruchomienie każdego przepływu pracy.
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— wydajność może mieć negatywny wpływ.
Wpływ grupy, kolejki i roli użytkownika na wydajność
Należy zaplanować wczesne planowanie grup i ról użytkowników. Należy tworzyć grupy oszczędnie i tworzyć je dla najmniejszego możliwego zakresu. Następnie przed utworzeniem grup należy najpierw wypełnić bazę danych danymi z usług domena usługi Active Directory Services (AD DS), Configuration Manager i System Center Operations Manager.
Często administratorzy tworzą grupy, aby upewnić się, że użytkownicy mają dostęp tylko do określonych grup. Na przykład w jednym scenariuszu możesz utworzyć podzbiór zdarzeń, takich jak zdarzenia wpływające na komputery używane przez personel zasobów ludzkich. W tym scenariuszu możesz chcieć, aby tylko określony personel mógł wyświetlać lub modyfikować grupę poufnych serwerów. Następnie, aby włączyć ten typ dostępu, należy utworzyć grupę dla wszystkich użytkowników i grupy dla poufnych komputerów, a następnie upewnić się, że rola zabezpieczeń ma dostęp zarówno do grup Wszyscy użytkownicy, jak i Serwery poufne. Nieuchronnie utworzenie grupy zawierającej wszystkich użytkowników powoduje wpływ na wydajność, ponieważ program Service Manager często sprawdza, czy istnieją zmiany w grupie. Ta kontrola jest wykonywana co 30 sekund, domyślnie. W przypadku dużej grupy sprawdzanie zmian powoduje duże obciążenie systemu i może znacznie spowolnić czas odpowiedzi.
Rozwiązanie 1. Można ręcznie określić, jak często program Service Manager sprawdza zmiany grupy, modyfikując klucz rejestru. Jeśli na przykład zmienisz częstotliwość sprawdzania grupy z 30 sekund na 10 minut, znacznie zwiększysz wydajność. Jednak kolejki i cele poziomu usług są 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ługi.
Uwaga
Nieprawidłowe edytowanie rejestru może spowodować poważne uszkodzenie systemu. Przed wprowadzeniem zmian w rejestrze należy wykonać kopię zapasową wszelkich wartościowych danych przechowywanych na komputerze.
Ręczne określanie interwału sprawdzania zmiany grupy
Uruchom polecenie Regedit i przejdź do HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.
Utwórz nową wartość DWORD o nazwie GroupCalcPollingIntervalMilliseconds.
Dla jego wartości określ interwał w milisekundach. Wynik jest mnożony przez 6. Na przykład aby ustawić interwał na 10 minut, wprowadź wartość 6000000.
Uruchom ponownie usługę System Center Management.
Rozwiązanie 2: Skrypt programu Windows PowerShell umożliwia dodawanie obiektów typu, takich jak "Użytkownicy", do roli użytkownika. 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 potrzebę dużej grupy ("Wszyscy użytkownicy") i kosztowne sprawdzenie, czy program Service Manager wykonuje w celu określenia członkostwa w tej grupie. Na serwerze zarządzania programu Service Manager można uruchomić następujący skrypt programu Windows PowerShell, aby dodać typ "user" do roli "RoleName". Musisz zmodyfikować ten przykładowy skrypt dla środowiska.
Uruchamianie skryptu programu Windows PowerShell w celu dodania obiektów do roli użytkownika
- W razie potrzeby zmodyfikuj 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życie "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 podzestawu danych powiązanych z elementem. Typ zaawansowany zawiera wiele złożonych odwołań do danych powiązanych z elementem. Typowe typy to proste projekcje; typy zaawansowane to złożone projekcje. Większość zaawansowanych typów obiektów służy do wypełniania różnych pól w formularzach, które zwykle nie powinny być wyświetlane w widoku. Za każdym razem, gdy utworzysz widok na podstawie zaawansowanego typu obiektu i po otwarciu widoku, program Service Manager wysyła zapytanie do bazy danych i jest odczytywana duża ilość danych. Jednak bardzo mało pobranych danych jest wyświetlanych lub używanych.
Jeśli wystąpią problemy z wydajnością z widokami zdefiniowanymi podczas korzystania z zaawansowanych typów obiektów w widokach, przełącz się do typowych typów. Alternatywnie możesz utworzyć własne typy projekcji, które zawierają tylko dane potrzebne do utworzenia widoku.
Wydajność bazy danych programu Service Manager
Wydajność bazy danych programu Service Manager ma bezpośredni wpływ na różne czynniki, w tym liczbę współbieżnych konsol programu Service Manager, które odczytują lub zapisują dane, interwał sprawdzania zmian grupy i dane wstawione przez łączniki. Więcej informacji jest dostępnych w tym dokumencie. Oto kilka kluczowych kwestii:
W typowych scenariuszach powinien istnieć co najmniej 8 gigabajtów (GB) pamięci RAM dla serwera zarządzania, w którym jest hostowana baza danych programu Service Manager.
Na komputerze hostowym bazy danych programu Service Manager powinny znajdować się co najmniej 8 rdzeni procesora CPU.
Lepszą wydajność bazy danych można osiągnąć, oddzielając pliki dziennika i pliki danych do oddzielnych dysków fizycznych, jeśli to możliwe. Możesz uzyskać dalsze korzyści, przenosząc bazę danych tempdb na inny dysk fizyczny RAID niż baza danych programu Service Manager. Jeśli to możliwe, użyj systemu dysków RAID 1+0 do hostowania bazy danych programu Service Manager.
Wydajność może mieć negatywny wpływ, jeśli baza danych programu Service Manager jest tworzona z mniejszym rozmiarem i jest ustawiona na automatyczne zwiększanie, zwłaszcza przez małe przyrosty.
Zapoznaj się z narzędziem pomocnika określania rozmiaru programu Service Manager dołączonym do zestawu dokumentacji pomocy dotyczącej zadań programu Service Manager (SM_job_aids.zip), aby uzyskać pomoc dotyczącą oceny rozmiaru bazy danych i utworzyć bazę danych o rozmiarze bliżej końcowego rozmiaru. 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 skorzystać z podziału grup tabel w odpowiednich grupach plików i przeniesienia ich na inny dysk fizyczny.
Wydajność serwera zarządzania programu Service Manager
Wydajność serwera zarządzania programu Service Manager ma wpływ głównie na liczbę aktywnych równoczesnych konsol programu Service Manager. Ponieważ wszystkie role programu Service Manager współdziałają z serwerem zarządzania, rozważ dodanie dodatkowych serwerów zarządzania, jeśli planujesz mieć dużą liczbę współbieżnych 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 programu Service Manager
Wydajność konsoli programu Service Manager ma wpływ głównie na liczbę formularzy, które zwykle mają otwarte analitycy, oraz ilość danych pobieranych przez widoki. Na komputerze, na którym zainstalowano konsolę programu Service Manager, należy 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ę programu Service Manager, należy mieć co najmniej 4-rdzeniowy procesor. Ponieważ konsola programu Service Manager jest aplikacją użytkownika końcowego, zalecamy jej ponowne uruchomienie w przypadku nadmiernego użycia zasobów. Konsola programu 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 programu Service Manager
Wydajność magazynu danych ma bezpośredni wpływ na różne czynniki, w tym liczbę współbieżnych serwerów zarządzania programu 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 zwiększa się wraz z upływem czasu. Upewnienie się, że archiwizowanie niepotrzebnych danych jest ważne. Innym czynnikiem wpływającym na wydajność magazynu danych jest ustawienie BatchSize procesów ETL.
Lepszą wydajność można osiągnąć, oddzielając pliki dziennika i pliki danych do oddzielnych dysków fizycznych. Należy jednak unikać umieszczania więcej niż jednego pliku dziennika na dysk. Podobnie można osiągnąć lepszą przepływność, umieszczając bazę danych tempdb na innym dysku fizycznym niż inne bazy danych. Ponadto możesz skorzystać, umieszczając różne bazy danych na odpowiednich dyskach fizycznych. Jeśli to możliwe, użyj systemu dysków RAID 1+0 do hostowania magazynu danych. Zazwyczaj dla komputera, 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 programu 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 uruchomionym programem SQL Server, który hostuje magazyn danych, a tym bardziej, jeśli bazy danych Datamart i Repository znajdują się na tym samym serwerze. Jeśli jednak w topologii wdrożenia jest 4000 lub mniej komputerów, wystarczy 4 GB. Na komputerze, na którym zainstalowano bazę danych magazynu danych, należy mieć co najmniej 8 rdzeni procesora CPU. Dodatkowe rdzenie ułatwią zarówno etl, jak i wydajność raportów.
Wydajność może mieć negatywny wpływ, jeśli wszystkie bazy danych w systemie są tworzone z mniejszym rozmiarem i ustawiane na automatyczne zwiększanie, zwłaszcza przez małe przyrosty. Zobacz narzędzie pomocnika określania rozmiaru programu Service Manager, które znajduje się w zestawie dokumentacji pomocy programu Service Manager (SM_job_aids.zip), aby ocenić rozmiar bazy danych i utworzyć bazę danych o rozmiarze zbliżonym do końcowego rozmiaru, co pomoże zmniejszyć wydajność przez zmniejszenie liczby przypadków automatycznego zwiększania bazy danych.
Program 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ę programu SQL Server.
Wydajność serwera magazynu danych programu Service Manager
Wydajność serwera magazynu danych ma wpływ na liczbę serwerów zarządzania programu Service Manager zarejestrowanych w magazynie danych, rozmiar wdrożenia i liczbę źródeł danych. Zazwyczaj dla serwera magazynu danych powinno być co najmniej 8 GB pamięci RAM. Jednak wydajność może przynieść korzyści dzięki dodatkowej pamięci w przypadku zaawansowanych scenariuszy wdrażania, w których więcej niż jeden serwer zarządzania programu Service Manager wstawia dane do magazynu danych. Jeśli musisz zniącić wydajność, najwyższy priorytet powinien być dla pamięci komputera z uruchomionym programem SQL Server. Aby zapobiec problemom z wydajnością, należy mieć co najmniej 8 rdzeni procesora CPU.
Wydajność portalu samoobsługowego
Portal samoobsługowy 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.
Testy wydajnościowe portalu samoobsługowego koncentrowały 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 (krótszym niż 4–5 sekund). Ten cel został osiągnięty przy użyciu minimalnego sprzętu zalecanego w tym dokumencie.
Wydajność celu poziomu usług
Nie ma określonej liczby celów poziomu usług, które obsługuje program Service Manager. 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 programu Service Manager 50 000 komputerów. Być może można utworzyć więcej celów poziomu 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 podać konkretnego zalecenia dotyczącego liczby celów poziomu usług, których nie należy przekraczać. Jeśli konfiguracja wdrożenia ma słabą 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).
Następne kroki
- Aby dowiedzieć się więcej na temat konfiguracji sprzętu i oprogramowania dla scenariuszy wdrażania programu Service Manager, zapoznaj się z tematem Zalecane scenariusze topologii wdrożenia.