Udostępnij za pośrednictwem

  • Artykuł

Wydajność programu Service Manager

 

Data opublikowania: lipiec 2016

Dotyczy: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Na wydajność funkcji i ról serwera programu System Center 2012 – Service Manager mają wpływ różne czynniki. Ogólnie rzecz biorąc, pozytywny i negatywny wpływ na wydajność w programie Service Manager można najłatwiej zauważyć w trzech obszarach:

  • Czas odpowiedzi programu Konsola programu Service Manager. 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 importowania danych przez program Service Manager 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 trwać bardzo długo, na przykład od 8 do 12 godzin w przypadku obszernej synchronizacji początkowej z programem System Center Configuration Manager. Podczas synchronizacji początkowej łącznika można spodziewać się spadku wydajności wszystkich ról serwera i procesów programu Service Manager. Jest to spowodowane sposobem sekwencyjnego wstawiania danych do bazy danych programu Service Manager, która jest bazą danych programu Microsoft SQL Server. Chociaż synchronizacji początkowej łącznika nie można przyspieszyć, można ją zaplanować i zapewnić, że zostanie ukończona przed wdrożeniem programu Service Manager w systemach produkcyjnych.

Po ukończeniu synchronizacji początkowej program Service Manager będzie synchronizować różnice, co nie ma zauważalnego wpływu na wydajność.

Wydajność przepływów 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 role serwera programu Service Manager są mocno obciążone, 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.

Bardzo duże obciążenie systemu (na przykład gdy tworzonych jest dużo nowych zdarzeń, a każde z nich generuje wiele przepływów pracy) może negatywnie wpłynąć na wydajność.

Wydajność przepływów pracy w programie System Center 2012 – Service Manager uległa poprawie w stosunku do wersji System Center Service Manager 2010, ponieważ nowy pakiet administracyjny ManagmentHostKeepAlive umożliwił zwiększenie czasu odpowiedzi przetwarzania przepływów pracy, dzięki czemu prawie wszystkie przepływy pracy są wykonywane w ciągu jednej minuty.

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. Przed utworzeniem grup należy wstępnie wypełnić bazę danych danymi z usług domenowych Active Directory (AD DS) oraz programów System Center Configuration Manager i System Center Operations Manager.

Często administratorzy tworzą grupy, aby zapewnić użytkownikom dostęp wyłącznie 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. Utworzenie grupy obejmującej wszystkich użytkowników w nieunikniony sposób będzie wpływać na wydajność, ponieważ program Service Manager często sprawdza, czy nastąpiły zmiany w grupie. To sprawdzanie jest wykonywane domyślnie co 30 sekund. W przypadku bardzo dużej grupy sprawdzanie zmian w dużym stopniu obciąża system i może znacznie wydłużyć czas reakcji.

Rozwiązanie 1: Można ręcznie określić częstotliwość sprawdzania zmian grupy przez program Service Manager, 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. Tak więc zwiększenie wartości interwału sondowania spowoduje przedłużenie czasu obliczeń celu poziomu usług i kolejek.

System_CAPS_ICON_caution.jpg Przestroga


Niepoprawne edytowanie rejestru może spowodować poważne uszkodzenia systemu. Przed wprowadzeniem zmian w rejestrze należy wykonać kopie zapasowe wszystkich ważnych danych przechowywanych na komputerze.

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

  1. Uruchom Edytor rejestru i przejdź do pozycji HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\.

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

  3. Jako jej wartość podaj interwał w milisekundach. Wynik jest mnożony przez 6. Na przykład, aby ustawić interwał wynoszący 10 minut, wpisz 600000.

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

    Uwaga


    W programie System Center 2012 R2 Service Manager nazwa usługi System Center Management została zmieniona na Microsoft Monitoring Agent.

Rozwiązanie 2: Przy użyciu skryptu Windows PowerShell można dodawać obiekty określonego typu, na przykład Użytkownicy, do roli użytkownika. Zasadniczo analityk zalogowany w tej roli ma dostęp do wszystkich obiektów typu Użytkownik. Zastosowanie tej metody pozwala wyeliminować potrzebę utworzenia bardzo dużej grupy („Wszyscy użytkownicy”) i kosztownego sprawdzania przeprowadzanego przez program Service Manager w celu ustalenia członkostwa w grupie. Na serwerze zarządzania Service Manager możesz uruchomić poniższy skrypt Windows PowerShell, aby dodać typ „user” do roli „RoleName”. Ten skrypt przykładowy należy zmodyfikować odpowiednio do danego ś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."  
}

Wydajność widoków

Tworząc widoki, należy planować używanie „typowych” klas w systemie wszędzie, gdzie jest to możliwe. Większość klas obiektów, na przykład Zarządzanie zdarzeniami, ma dwa typy: „typowy” i „zaawansowany”. 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 formularzy, które zazwyczaj nie są wyświetlane w widoku. Podczas tworzenia widoku opartego na zaawansowanym typie obiektu i otwieraniu tego widoku program Service Manager przeszukuje bazę danych, co powoduje odczyt dużej ilości danych. Jednak bardzo niewiele z tych danych zostaje wyświetlonych lub użytych.

W przypadku wystąpienia problemów z wydajnością widoków, które zdefiniowano z użyciem zaawansowanych typów obiektów, należy zamiast nich użyć typów typowych. Innym rozwiązaniem jest utworzenie własnych typów projekcji zawierających tylko dane potrzebne w widoku. Aby uzyskać więcej informacji, zobacz wpis Creating Views That Use Related Property Criteria (Type Projections) : Software Views Example (Tworzenie widoków korzystających z kryteriów właściwości powiązanej (projekcji typów): przykłady widoków oprogramowania) na blogu zespołu inżynieryjnego programu SCSM.

Wydajność bazy danych programu Service Manager

Na wydajność bazy danych programu Service Manager bezpośrednio wpływa wiele czynników, w tym liczba programów Konsola programu Service Manager jednocześnie odczytujących lub zapisujących dane, interwał sprawdzania zmian grupy i dane wstawiane przez łączniki. Więcej informacji na ten temat można znaleźć w tym dokumencie. Oto kilka najważniejszych informacji:

  • Serwer zarządzania hostujący bazę danych programu Service Manager powinien mieć co najmniej 8 GB pamięci RAM, aby zapewnić akceptowalny czas odpowiedzi w typowych scenariuszach.

  • Komputer hostujący bazę danych programu Service Manager powinien być wyposażony w co najmniej 8 rdzeni procesora.

  • 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). Dodatkową poprawę może zapewnić przeniesienie bazy danych tempdb na fizyczny dysk RAID inny niż używany przez bazę danych programu Service Manager. Jeśli jest to możliwe, dla bazy danych programu Service Manager należy używać systemu dyskowego RAID 1+0.

  • Negatywny wpływ na wydajność może mieć utworzenie bazy danych programu Service Manager o małym rozmiarze i ustawienie jej automatycznego przyrostu (zwłaszcza w małych odstępach).

Zobacz narzędzie Pomocnik ustalania wielkości programu Service Manager dołączone do zestawu dokumentacji Service Manager job aids (Pomoce dotyczące zadań programu Service Manager) (SM_job_aids.zip), aby uzyskać pomoc w oszacowaniu wielkości bazy danych i utworzyć bazę danych o wielkości zbliżonej do rozmiaru końcowego. Zapewni to poprawę wydajności dzięki skróceniu czasu automatycznego przyrostu bazy danych.

W tym przypadku zastosowanie mają również wszystkie najlepsze rozwiązania dotyczące baz danych o wysokiej wydajności. Na przykład dysponując zaawansowanym podsystemem dysków, można podzielić grupy tabel w odpowiadających im grupach plików i przenieść je na różne dyski fizyczne.

Wydajność serwera zarządzania programu Service Manager

Wydajność serwera zarządzania programu Service Manager zależy główne od liczby aktywnych równolegle działających programów Konsola programu Service Manager. Ponieważ wszystkie role programu Service Manager komunikują się z serwerem zarządzania, należy rozważyć dodanie więcej serwerów zarządzania, jeśli planowane jest równoległe działanie wielu konsol. Serwer zarządzania powinien mieć 8 GB pamięci RAM. Każdy serwer zarządzania powinien dysponować co najmniej 4 rdzeniami procesora przy założeniu, że na jeden rdzeń przypada od 10 do 12 aktywnych konsol.

Wydajność konsoli programu Service Manager

Na wydajność programu Konsola programu Service Manager wpływa głównie liczba formularzy otwartych zwykle przez analityków i ilość danych pobieranych przez widoki. Komputer z zainstalowanym programem Konsola programu Service Manager powinien mieć 4 GB pamięci RAM. Jeśli używane są widoki pobierające duże ilości danych, potrzeba będzie więcej pamięci RAM. Komputer z zainstalowanym programem Konsola programu Service Manager powinien być wyposażony w procesor o co najmniej 4 rdzeniach. Ponieważ program Konsola programu Service Manager jest przeznaczony dla użytkowników końcowych, zalecamy jego ponowne uruchamianie po zauważeniu nadmiernego wykorzystania zasobów. Konsola programu Service Manager agresywnie buforuje informacje w pamięci, co wpływa na ogólne użycie pamięci.

Wydajność bazy danych magazynu danych programu Service Manager

Na wydajność magazynu danych bezpośredni wpływ ma wiele czynników, w tym liczba serwerów zarządzania programu Service Manager równolegle wysyłających dane, ilość przechowywanych danych lub okres przechowywania danych, szybkość zmian danych oraz częstotliwość operacji wyodrębniania, transformacji 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 jest to możliwe, dla magazynu danych należy używać systemu dyskowego RAID 1+0. Komputer, na którym są zainstalowane bazy danych magazynu danych, powinien mieć co najmniej 8 GB pamięci RAM. W przypadku korzystania z dodatkowych źródeł danych magazynu danych z programów Operations Manager lub Configuration Manager należy zwiększyć ilość pamięci RAM dla baz danych. Korzystne będzie wyposażenie w większą ilość pamięci komputera, na którym działa program SQL Server obsługujący magazyn danych, zwłaszcza jeśli bazy danych składnicy danych i repozytorium znajdują się na tym samym serwerze. Jeśli jednak topologia wdrożenia obejmuje 4000 komputerów lub mniej, 4 GB pamięci będą wystarczające. 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). Zobacz narzędzie Pomocnik ustalania wielkości programu Service Manager dołączone do zestawu dokumentacji Service Manager job aids (Pomoce dotyczące zadań programu Service Manager) (SM_job_aids.zip), aby oszacować wielkość bazy danych i utworzyć bazę danych o wielkości zbliżonej do rozmiaru końcowego, co poprawi wydajność przez skrócenie czasu automatycznego przyrostu bazy danych.

Service Manager ma wbudowaną funkcję obsługi grup plików. Można to wykorzystać przez umieszczenie grup plików na różnych dyskach twardych. Aby uzyskać więcej informacji na temat najlepszych rozwiązań dotyczących grup plików, zobacz dokumentację programu SQL Server.

Wydajność serwera magazynu danych programu Service Manager

Na wydajność serwera magazynu danych ma wpływ liczba serwerów zarządzania programu Service Manager zarejestrowanych w magazynie danych, wielkość wdrożenia i liczba źródeł danych. Serwer magazynu danych powinien mieć zwykle co najmniej 8 GB pamięci RAM. Jednak zastosowanie większej ilości pamięci będzie miało korzystny wpływ na wydajność w zaawansowanych scenariuszach wdrożenia, gdzie więcej niż jeden serwer zarządzania programu Service Manager wstawia dane do magazynu danych. Jeśli konieczny jest kompromis, najwyższy priorytet powinna mieć pamięć komputera, na którym działa program 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 samoobsługowy został zaprojektowany w celu zapewnienia łatwego dostępu do zgłaszania zdarzeń i żądań obsługi. Nie jest on przystosowany do obsługiwania tysięcy użytkowników jednocześnie.

Wydajność programu Portal samoobsługowy testowano pod kątem typowych scenariuszy „poniedziałkowego poranka”, a dokładniej w celu zapewnienia, że w poniedziałek rano setki użytkowników będą mogły zalogować się w 5–10 minutowym przedziale czasu i otworzyć zdarzenia o akceptowalnych (krótszych niż 4-5 sekund) czasach reakcji. Ten cel osiągnięto z przy minimalnych wymaganiach sprzętowych zalecanych w tym dokumencie.

Wydajność celu poziomu usług

Nie jest określona żadna liczba celów poziomu usług obsługiwanych przez program Service Manager. Na przykład, jeśli w organizacji zwykle występuje niewiele zdarzeń, program może obsługiwać więcej celów poziomu usług niż w innej sytuacji. Jednak duża liczba zdarzeń może wymusić odpowiednio zastosowanie mniejszej liczby celów poziomu usług albo skalowanie w poziomie dodatkowego sprzętu i oprogramowania. Zalecamy utworzenie nie więcej niż pięciu celów poziomu usług w przypadku typowej konfiguracji programu Service Manager obejmującej 50 000 komputerów. Utworzenie większej liczby celów poziomu usług może być możliwe. Jednak ponieważ warunki w różnych organizacjach znacznie się różnią, firma Microsoft nie może przedstawić konkretnych zaleceń dotyczących liczby celów poziomu usług, których nie należały przekraczać. Jeśli wydajność konfiguracji wdrożenia jest niska z uwagi na liczbę celów poziomu usług, zalecamy skalowanie w poziomie z użyciem następnego pod względem wielkości scenariusza wdrożenia, zgodnie z opisem w sekcji Konfiguracje scenariuszy wdrażania niniejszego przewodnika.