Rozwiązywanie problemów ze stanami szarymi agentów w programie System Center Operations Manager

W tym artykule opisano sposób rozwiązywania problemów, w których agent, serwer zarządzania lub brama są niedostępne lub wyszarane w programie System Center Operations Manager (OpsMgr).

Oryginalna wersja produktu: Microsoft System Center 2012 Operations Manager
Oryginalny numer KB: 2288515

Agent, serwer zarządzania lub brama mogą mieć jeden z następujących stanów, zgodnie z kolorem nazwy i ikony agenta w okienku Monitorowanie .

Stan	Wygląd	opis
Dobra kondycja	Zielony znacznik wyboru	Agent lub serwer zarządzania pracuje prawidłowo.
Krytyczne	Czerwony znacznik wyboru	Wystąpił problem na agencie lub serwerze zarządzania.
Nieznane	Szara nazwa agenta, szary znacznik wyboru	Obserwator usługi kondycji na serwerze zarządzania, który nadzoruje usługę kondycji na monitorowanym komputerze, nie odbiera już sygnałów pulsu od agenta. Obserwator usługi kondycji wcześniej odbierał sygnały pulsu i został zgłoszony prawidłowy stan. Oznacza to również, że serwery zarządzania nie otrzymują już żadnych informacji od agenta. Problem ten może wystąpić, jeśli komputer obsługujący agenta nie jest uruchomiony lub występują problemy z łącznością.
Nieznane	Zielony okrąg, bez znacznika wyboru	Stan odnalezionego elementu jest nieznany. Nie ma dostępnego monitora dla tego określonego odnalezionego elementu.

Przyczyny szarego stanu

Agent, serwer zarządzania lub brama mogą stać się niedostępne z następujących powodów:

• Awaria pulsu
• Nieprawidłowa konfiguracja
• Awaria przepływów pracy w systemie
• Problemy z wydajnością bazy danych lub magazynu danych programu Operations Manager
• Problemy z wydajnością serwera zarządzania lub serwera bramy
• Problemy z siecią lub uwierzytelnianiem
• Niedziałająca (nieuruchomiona) usługa kondycji

Zakres problemu

Przed rozpoczęciem rozwiązywania problemu z agentem wyszarzanym należy najpierw zrozumieć topologię programu Operations Manager, a następnie zdefiniować zakres problemu. Następujące pytania mogą pomóc w zdefiniowaniu zakresu problemu:

• Ilu agentów dotyczy problem?
• Czy agenci napotykają problem w tym samym segmencie sieci?
• Czy agenci zgłaszają ten sam serwer zarządzania?
• Jak często agenci wchodzą i pozostają w szarym stanie?
• Jak zwykle można odzyskać sprawę po tej sytuacji (na przykład ponownie uruchomić usługę kondycji agenta, wyczyścić pamięć podręczną, polegać na automatycznym odzyskiwaniu)?
• Czy alerty błędów pulsu są generowane dla tych agentów?
• Czy ten problem występuje w określonej porze dnia?
• Czy ten problem będzie się powtarzać, jeśli przełączysz tych agentów w tryb failover na inny serwer zarządzania lub bramę?
• Kiedy ten problem zaczął występować?
• Czy zostały wprowadzone jakiekolwiek zmiany w agentach, serwerach zarządzania, bramie lub grupie zarządzania?
• Czy są to systemy klastrowane systemu Windows, których dotyczy problem?
• Czy folder stanu Usługa kondycji jest wykluczony ze skanowania antywirusowego?

Strategia rozwiązywania problemów

Strategia rozwiązywania problemów będzie określana przez to, który składnik jest nieaktywny, gdzie ten składnik należy do topologii i jak powszechny jest problem. Rozważ następujące warunki:

• Jeśli agenci raportujący do określonego serwera zarządzania lub bramy są niedostępni, rozwiązywanie problemów powinno rozpocząć się na poziomie serwera zarządzania lub bramy.
• Jeśli bramy raportujące do określonego serwera zarządzania są niedostępne, rozwiązywanie problemów powinno rozpocząć się na poziomie serwera zarządzania.
• W przypadku systemów bez agentów, urządzeń sieciowych i serwerów z systemami Unix i Linux rozwiązywanie problemów powinno rozpoczynać się od agenta, serwera zarządzania lub bramy monitorujących te obiekty.
• Rozwiązywanie problemów zwykle rozpoczyna się na poziomie bezpośrednio powyżej niedostępnego składnika.

Scenariusz 1

Problem dotyczy tylko kilku agentów. Ci agenci zgłaszają się do różnych serwerów zarządzania. Agenci pozostają regularnie niedostępni. Mimo że pamięć podręczna agenta jest w stanie tymczasowo rozwiązać ten problem, problem występuje ponownie po kilku dniach.

Rozwiązanie dla scenariusza 1

Aby rozwiązać problem w tym scenariuszu, wykonaj następujące kroki:

1. Zastosuj odpowiednią poprawkę do systemów operacyjnych, których dotyczy problem.
2. Wyklucz pamięć podręczną agenta ze skanowania antywirusowego. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące wykluczeń oprogramowania antywirusowego, które odnoszą się do programu Operations Manager.
3. Zatrzymaj usługę kondycji.
4. Wyczyść pamięć podręczną agenta.
5. Uruchom usługę kondycji.

Scenariusz 2

Problem dotyczy tylko kilku agentów. Ci agenci zgłaszają się do różnych serwerów zarządzania. Agenci pozostają stale nieaktywni. Mimo że można wyczyścić pamięć podręczną agenta, nie rozwiązuje to problemu.

Rozwiązanie dla scenariusza 2

Aby rozwiązać problem w tym scenariuszu, wykonaj następujące kroki:

1. Ustal, czy usługa kondycji jest włączona i jest obecnie uruchomiona na serwerze zarządzania, czy na bramie. Jeśli usługa kondycji przestała odpowiadać, wygeneruj zrzut usługi ADPlus w trybie zawieszenia usługi, aby pomóc w ustaleniu przyczyny problemu. Aby uzyskać więcej informacji, zobacz How to use ADPlus.vbs to troubleshoot "hangs" and "crash" (Jak rozwiązywać problemy z zawieszami się i "awariami")

2. Sprawdź dziennik zdarzeń programu Operations Manager w agencie, aby zlokalizować dowolne z następujących zdarzeń:

   Identyfikator zdarzenia: 1102
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Nie można zainicjować reguły/monitora "%4" dla wystąpienia "%3" o identyfikatorze:"%2" i nie zostaną załadowane. Grupa zarządzania „%1”

   Identyfikator zdarzenia: 1103
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Podsumowanie: %2 reguły/monitory nie powiodły się i zostały rozładowane. %3 z nich osiągnęło limit awarii, który uniemożliwia automatyczne ponowne ładowanie. Grupa zarządzania „%1”. To jest tylko zdarzenie podsumowane. Zobacz inne zdarzenia z opisami dotyczącymi usuniętych z pamięci reguł/monitorów.

   Identyfikator zdarzenia: 1104
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Nie można rozpoznać profilu Uruchom jako w przepływie pracy %4, uruchomionego dla wystąpienia "%3" o identyfikatorze:"%2". Przepływ pracy nie zostanie załadowany. Grupa zarządzania „%1”

   Identyfikator zdarzenia: 1105
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Niezgodność typów dla profilu Uruchom jako w przepływie pracy "%4", uruchomiona dla wystąpienia "%3" o identyfikatorze:"%2". Przepływ pracy nie zostanie załadowany. Grupa zarządzania „%1”

   Identyfikator zdarzenia: 1106
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Nie można uzyskać dostępu do profilu uruchomień w postaci zwykłego tekstu w przepływie pracy %4, uruchomionym na przykład "%3" o identyfikatorze:"%2". Przepływ pracy nie zostanie załadowany. Grupa zarządzania „%1”

   Identyfikator zdarzenia: 1107
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Konto dla profilu Uruchom jako w przepływie pracy "%4", uruchomione dla wystąpienia "%3" o identyfikatorze:"%2" nie jest zdefiniowane. Przepływ pracy nie zostanie załadowany. Skojarz konto z profilem. Grupa zarządzania „%1”

   Identyfikator zdarzenia: 1108
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Nie można rozpoznać konta określonego w profilu Uruchom jako %7. Konkretnie: to konto jest używane w zastąpieniu bezpiecznego odwołania „%6”. %n%n Taka sytuacja może wystąpić, jeśli nie skonfigurowano dystrybucji konta na ten komputer. W celu rozwiązania tego problemu należy otworzyć podany poniżej profil Uruchom jako, zlokalizować wpis konta określony przez jego identyfikator SSID i albo włączyć dystrybucję konta na ten komputer, albo zmienić ustawienie profilu, aby obiekt docelowy nie korzystał z określonego konta. %n%nGrupa zarządzania: %1 %nProfil Uruchom jako: %7 %nNazwa SecureReferenceOverride: %6 %nId. SecureReferenceOverride: %4 %nNazwa obiektu: %3 %nId. obiektu: %2 %nSSID konta: %5

   Identyfikator zdarzenia: 4000
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Host monitorowania nie odpowiada lub uległ awarii. Kod stanu niepowodzenia hosta: %1.

   Identyfikator zdarzenia: 21016
   Źródło zdarzenia: Łącznik programu OpsMgr
   Opis zdarzenia:
   Program OpsMgr nie może skonfigurować kanału komunikacji do %1 i nie ma hostów trybu failover. Komunikacja zostanie wznowiona, gdy użytkownik %1 jest dostępny, a komunikacja z tego komputera jest dozwolona.

   Identyfikator zdarzenia: 21006
   Źródło zdarzenia: Łącznik programu OpsMgr
   Opis zdarzenia:
   Łącznik programu OpsMgr nie może nawiązać połączenia z użytkownikiem %1:%2. Kod błędu: %3 (%4). Sprawdź, czy istnieje łączność sieciowa, serwer jest uruchomiony i zarejestrował port nasłuchiwania, a zapory nie blokują ruchu do miejsca docelowego.

   Identyfikator zdarzenia: 20070
   Źródło zdarzenia: Łącznik programu OpsMgr
   Opis zdarzenia:
   Łącznik programu OpsMgr połączony z użytkownikiem %1, ale połączenie zostało zamknięte natychmiast po uwierzytelnieniu. Najbardziej prawdopodobną przyczyną tego błędu jest to, że agent nie ma autoryzacji do komunikowania się z serwerem lub serwer nie otrzymał konfiguracji. Sprawdź dziennik zdarzeń na serwerze pod kątem obecności zdarzeń 20000, wskazując, że agenci, którzy nie są zatwierdzani, próbują nawiązać połączenie.

   Identyfikator zdarzenia: 20051
   Źródło zdarzenia: Łącznik programu OpsMgr
   Opis zdarzenia:
   Nie można załadować określonego certyfikatu, ponieważ certyfikat jest obecnie nieprawidłowy. Sprawdź, czy czas systemowy jest poprawny i ponownie wystaw certyfikat w razie potrzeby%n Prawidłowy czas rozpoczęcia certyfikatu: %1%n Prawidłowy czas zakończenia certyfikatu: %2.

   Źródło zdarzenia: ESE
   Kategoria zdarzeń: Menedżer transakcji
   Identyfikator zdarzenia: 623
   Opis: HealthService (<PID>) Magazyn wersji dla wystąpienia wystąpienia<>("<name>") osiągnął maksymalny rozmiar <wartości> Mb. Prawdopodobnie długotrwała transakcja uniemożliwia czyszczenie magazynu wersji i powoduje utworzenie go w rozmiarze. Aktualizacje zostaną odrzucone do momentu całkowitego zatwierdzenia lub wycofania długotrwałej transakcji. Możliwa długotrwała transakcja:
   SessionId: <wartość>
   Kontekst sesji: <wartość>
   Identyfikator wątku kontekstu sesji: <wartość>.
   Oczyszczanie: <wartość>

3. Jeśli znajdziesz następujące konkretne zdarzenia, postępuj zgodnie z poniższymi wytycznymi:

   • Zdarzenia 1102 i 1103: te zdarzenia wskazują, że niektóre przepływy pracy nie zostały załadowane. Jeśli są to podstawowe przepływy pracy systemu, te zdarzenia mogą powodować problem. W takim przypadku skoncentruj się na rozwiązaniu problemów dotyczących tych zdarzeń.

   • Zdarzenia 1104, 1105, 1106, 1107 i 1108: te zdarzenia mogą spowodować wystąpienie zdarzeń 1102 i 1103. Zazwyczaj dzieje się tak z powodu nieprawidłowo skonfigurowanych kont Uruchom jako. Na przykład konta Uruchom jako są skonfigurowane do użycia z niewłaściwą klasą lub nie są skonfigurowane do dystrybucji do agenta.

   • Zdarzenie 4000: To zdarzenie wskazuje, że proces Monitoringhost.exe uległ awarii. Jeśli ten problem jest spowodowany niezgodnością bibliotek DLL lub brakującymi kluczami rejestru, może być możliwe rozwiązanie problemu przez ponowne zainstalowanie agenta. Jeśli problem będzie się powtarzać, spróbuj go rozwiązać, korzystając z następujących metod:

     • Uruchamianie przechwytywania monitora procesów do momentu awarii procesu. Aby uzyskać więcej informacji, zobacz Process Monitor w wersji 3.53.
     • Generowanie zrzutu usługi ADPlus w trybie awarii. Aby uzyskać więcej informacji, zobacz How to use ADPlus.vbs to troubleshoot "hangs" and "crash" (Jak rozwiązywać problemy z zawieszami się i "awariami")

   • Identyfikator zdarzenia 21006: To zdarzenie wskazuje, że problemy z komunikacją istnieją między agentem a serwerem zarządzania. Jeśli agent używa certyfikatu do wzajemnego uwierzytelniania, sprawdź, czy certyfikat nie wygasł i czy agent używa odpowiedniego certyfikatu. Jeśli używany jest protokół Kerberos, sprawdź, czy agent może komunikować się z usługą Active Directory. Jeśli uwierzytelnianie działa prawidłowo, może to oznaczać, że pakiety z agenta nie docierają do serwera zarządzania lub bramy. Spróbuj ustanowić telnet do portu 5723 z agenta do serwera zarządzania. Ponadto uruchom równoczesny ślad sieci między agentem a serwerem zarządzania podczas odtwarzania błędów komunikacji. Może to pomóc w ustaleniu, czy pakiety docierają do serwera zarządzania, oraz czy jakiekolwiek urządzenie między dwoma składnikami próbuje zoptymalizować ruch, czy porzuca niektóre pakiety. Aby uzyskać więcej informacji, zobacz Zbieranie danych przy użyciu usługi Network Monitor.

   • Identyfikator zdarzenia 623: to zdarzenie zwykle występuje w dużym środowisku programu Operations Manager, w którym serwer zarządzania lub komputer agenta zarządza wieloma przepływami pracy. Aby uzyskać więcej informacji, zobacz Co najmniej jeden serwer zarządzania i ich urządzenia zarządzane są wygaszone w konsoli programu Operations Manager.

Scenariusz 3

Wszyscy agenci raportujący do określonego serwera zarządzania lub bramy są niedostępni.

Rozwiązanie dla scenariusza 3

Aby rozwiązać problem w tym scenariuszu, wykonaj następujące kroki:

1. Spróbuj określić, jakiego rodzaju obciążenia monitoruje serwer zarządzania lub brama. Takie obciążenia mogą obejmować urządzenia sieciowe, agentów międzyplatformowych, transakcje syntetyczne, agentów systemu Windows i komputerów bez agentów.

2. Ustal, czy usługa kondycji jest uruchomiona na serwerze zarządzania, czy na bramie.

3. Ustal, czy serwer zarządzania działa w trybie konserwacji. Jeśli jest to konieczne, usuń serwer z trybu konserwacji.

4. Sprawdź dziennik zdarzeń programu Operations Manager w agencie pod kątem dowolnego zdarzenia wymienionego w scenariuszu 2. Jeśli istnieje zdarzenie o identyfikatorze 21006, postępuj zgodnie z tymi samymi wytycznymi, które zostały wymienione w temacie Rozwiązanie dla scenariusza 2. Ponadto w tym przypadku to zdarzenie wskazuje, że serwer zarządzania lub brama nie mogą komunikować się z serwerem nadrzędnym. W przypadku bramy serwer nadrzędny może być dowolnym serwerem zarządzania. (Zapoznaj się z krokiem 3 w sekcji Rozwiązanie dla scenariusza 2.)

5. Sprawdź dziennik zdarzeń programu Operations Manager pod kątem następujących zdarzeń. Te zdarzenia zwykle wskazują, że na serwerze zarządzania lub w programie Microsoft SQL Server, który hostuje OperationsManager bazę danych lub OperationsManagerDW , występują problemy z wydajnością:

   Identyfikator zdarzenia: 2115
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Źródło danych powiązania w grupie zarządzania %1 opublikowało elementy w przepływie pracy, ale nie odebrało odpowiedzi w ciągu %5 sekund. Wskazuje to na problem z wydajnością lub funkcjonalnością przepływu pracy.%n Identyfikator przepływu pracy: %2%n Wystąpienie: %3%n Identyfikator wystąpienia: %4%n

   Identyfikator zdarzenia: 5300
   Źródło zdarzenia: HealthService
   Opis zdarzenia:
   Lokalna usługa kondycji nie jest w dobrej kondycji. Przepływ zmiany stanu jednostki jest wstrzymany z oczekującym potwierdzeniem. %n%n%nGrupa zarządzania: %2 %n Identyfikator grupy zarządzania: %1

   Identyfikator zdarzenia: 4506
   Źródło zdarzenia: HealthService
   Opis zdarzenia: Operations Manager
   Dane zostały porzucone z powodu zbyt dużej ilości zaległych danych w regule %2 uruchomionej dla wystąpienia "%3" o identyfikatorze:"%4" w grupie zarządzania %1.

   Identyfikator zdarzenia: 31551
   Źródło zdarzenia: moduły Usługa kondycji
   Opis zdarzenia:
   Nie można przechowywać danych w magazynie danych. Operacja zostanie ponowiona.%rException %5: %6 %n%nOne lub więcej przepływów pracy miało na to wpływ. %n%nNazwa przepływu pracy: %2 %nNazwa wystąpienia: %3 %n Identyfikator wystąpienia: %4 %nGrupa zarządzania: %1

   Identyfikator zdarzenia: 31552
   Źródło zdarzenia: moduły Usługa kondycji
   Opis zdarzenia:
   Nie można zapisać danych w magazynie danych.%rException %5: %6 %n%nOne lub więcej przepływów pracy miało na to wpływ. %n%nNazwa przepływu pracy: %2 %nNazwa wystąpienia: %3 %n Identyfikator wystąpienia: %4 %nGrupa zarządzania: %1

   Identyfikator zdarzenia: 31553
   Źródło zdarzenia: moduły Usługa kondycji
   Opis zdarzenia:
   Dane zostały zapisane w obszarze przejściowym magazynu danych, ale przetwarzanie nie powiodło się w ramach jednej z kolejnych operacji.%rException %5: %6 %n%nOne lub więcej przepływów pracy miało na to wpływ. %n%nNazwa przepływu pracy: %2 %nNazwa wystąpienia: %3 %n Identyfikator wystąpienia: %4 %nGrupa zarządzania: %1

   Identyfikator zdarzenia: 31557
   Źródło zdarzenia: moduły Usługa kondycji
   Opis zdarzenia:
   Nie można uzyskać informacji o stanie procesu synchronizacji z bazy danych magazynu danych. Operacja zostanie ponowiona.%rException %5: %6 %n%nOne lub więcej przepływów pracy miało na to wpływ. %n%nNazwa przepływu pracy: %2 %nNazwa wystąpienia: %3 %n Identyfikator wystąpienia: %4 %nGrupa zarządzania: %1

6. Zdarzenie o identyfikatorze 3155X może być również rejestrowane z powodu nieprawidłowych konfiguracji konta Uruchom jako lub brak uprawnień dla kont Uruchom jako.

Uwaga 16.

Aby rozwiązać problemy z wydajnością serwera zarządzania lub bramy i wydajnością programu SQL Server, zobacz sekcję Rozwiązanie dla scenariusza 4 .

Scenariusz 4

Wszyscy agenci, którzy zgłaszają się do określonego serwera zarządzania, sporadycznie między stanami w dobrej kondycji i szarości. Lub, wszystkich agentów w środowisku alternatywnie sporadycznie między stanami zdrowymi i szarymi.

Rozwiązanie dla scenariusza 4

Aby rozwiązać ten problem, najpierw określ przyczynę problemu. Typowe przyczyny niedostępności serwera tymczasowego obejmują następujące elementy:

• Serwer nadrzędny agentów jest tymczasowo w trybie offline.
• Agenci zalewają serwer zarządzania danymi operacyjnymi, takimi jak alerty, stany, odnajdywanie itd. Może to spowodować zwiększone wykorzystanie zasobów systemowych w bazie danych programu Operations Manager i na serwerach programu Operations Manager.
• Awarie sieci spowodowały tymczasową awarię komunikacji między serwerem nadrzędnym a agentami.
• Wystąpiły zmiany pakietu administracyjnego (MP). W konsoli programu Operations Manager te zmiany wymagają konfiguracji programu Operations Manager i ponownej dystrybucji mp agentów. Jeśli zmiana wpłynie na większą bazę agentów, może to spowodować zwiększone użycie zasobów systemowych na serwerach bazy danych programu Operations Manager i programu Operations Manager.

Kluczem do rozwiązywania problemów w tych scenariuszach jest zrozumienie czasu niedostępności serwera i godziny dnia, w którym wystąpił. Pomoże to szybko zawęzić zakres problemu.

Rozwiązywanie problemów z wydajnością serwera zarządzania i bramy

Serwer zarządzania

Podczas serii aktualizacji konfiguracji (spowodowanej importem i odnajdywaniem mp) typowe wąskie gardła to, najpierw procesor CPU i drugi dysk instalacyjny programu Operations Manager. Serwer zarządzania odpowiada za przekazywanie plików konfiguracji do agentów docelowych.

W przypadku zbierania danych operacyjnych wąskie gardła są zwykle spowodowane przez procesor. Pojemność operacji we/wy dysku może również osiągnąć wartość maksymalną, ale jest to mniej prawdopodobne. Serwer zarządzania odpowiada za dekompresowanie i odszyfrowywanie przychodzących danych operacyjnych oraz wstawianie ich do operacyjnej bazy danych. Wysyła on również potwierdzenia (ACK) z powrotem do agentów lub bram po odebraniu danych operacyjnych i używa kolejkowania dysków do tymczasowego przechowywania tych wychodzących elementów ACK.

Brama

Brama jest powiązana zarówno z procesorem, jak i we/wy. Gdy brama przekazuje dużą ilość danych, operacje procesora CPU i operacji we/wy mogą wskazywać wysokie użycie. Większość użycia procesora CPU jest spowodowana dekompresacją, kompresją, szyfrowaniem i odszyfrowywaniem danych przychodzących, a także przez transfer tych danych. Wszystkie dane odbierane przez bramę i agentów są przechowywane w trwałej kolejce na dysku, które mają być odczytywane i przekazywane do serwera zarządzania przez usługę kondycji bramy. Może to spowodować duże użycie dysku. To użycie może być znaczące, gdy brama jest tymczasowo przełączona w tryb offline i musi obsługiwać skumulowane dane agenta wygenerowane przez agentów i próbowały wysłać, gdy brama była nadal w trybie offline.

Aby rozwiązać ten problem związany z taką sytuacją, zbierz następujące informacje dotyczące każdego serwera zarządzania lub bramy, których dotyczy problem:

• Dokładna wersja, wydanie i numer kompilacji systemu Windows

• Liczba procesorów

• Ilość pamięci RAM

• Dysk zawierający folder stanu Usługa kondycji

• Czy oprogramowanie antywirusowe jest skonfigurowane do wykluczania magazynu Usługa kondycji

  Uwaga 16.

  Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące wykluczeń oprogramowania antywirusowego, które odnoszą się do programu Operations Manager.

• Poziom RAID (0, 1, 50+1 lub 1+0) dla dysku używanego przez stan Usługa kondycji

• Liczba dysków używanych na potrzeby macierzy RAID

• Czy pamięć podręczna zapisu z obsługą baterii jest włączona na kontrolerze macierzy

Rozwiązywanie problemów z wydajnością programu SQL Server

Operacyjna baza danych (OperationsManager)

W przypadku bazy danych OperationsManager najbardziej prawdopodobnym wąskim gardłem jest macierz dyskowa. Jeśli macierz dyskowa nie ma maksymalnej pojemności we/wy, następnym najbardziej prawdopodobnym wąskim gardłem jest procesor. Baza danych będzie doświadczać okazjonalnych spowolnień i nadmiaru danych operacyjnych (duża częstość występowania zmian stanu lub danych wydajności zdarzeń, alertów i wydajności, które utrzymują się przez stosunkowo długi czas). Krótki wzrost zwykle nie powoduje znacznego opóźnienia przez dłuższy czas.

Podczas wstawiania danych operacyjnych dyski bazy danych są używane głównie do zapisu. Użycie procesora jest spowodowane przez zmiany w programie SQL Server. Taka sytuacja może wystąpić, gdy masz duże i złożone zapytania, wstawiasz dużo danych i przeprowadzasz pielęgnację dużych tabel (co domyślnie odbywa się o północy). Zazwyczaj pielęgnacja nawet dużych zdarzeń i tabel danych wydajności nie powoduje nadmiernego użycia zasobów procesora lub dysku. Natomiast pielęgnacja tabel zmian alertów i stanów może stanowić duże obciążenie procesora w przypadku dużych tabel.

Baza danych jest również powiązana z procesorem, gdy obsługuje wzrosty zasięgu ponownego dystrybuowania konfiguracji, które są spowodowane importami pakietów administracyjnych lub dużą zmianą miejsca w wystąpieniu. W takich przypadkach usługa konfiguracji wysyła zapytanie do bazy danych pod kątem nowej konfiguracji agenta. Zwykle powoduje to wzrosty użycia procesora w bazie danych, zanim usługa wyśle aktualizacje konfiguracji do agentów.

Magazyn danych (OperationsManagerDW)

W przypadku bazy danych OperationsManagerDW najbardziej prawdopodobnym wąskim gardłem jest macierz dyskowa. Taka sytuacja zwykle występuje z powodu wstawiania dużej ilości danych operacyjnych. W takich przypadkach dyski są głównie zajęte wykonywaniem operacji zapisu. Przeważnie dyski wykonują kilka operacji odczytu, z wyjątkiem obsługi ręcznie generowanych widoków raportowania, ponieważ te uruchamiają zapytania w magazynie danych.

Użycie procesora jest spowodowane przez zmiany w programie SQL Server. Skoki użycia procesora mogą wystąpić podczas intensywnego partycjonowania (gdy tabele stają się duże, a następnie są partycjonowane), generowania złożonych raportów i dużych liczb alertów w bazie danych, z którymi magazyn danych musi stale się synchronizować.

Ogólne wskazówki dotyczące rozwiązywania problemów

Aby rozwiązać ten problem związany z taką sytuacją, zbierz następujące informacje dotyczące każdego serwera zarządzania lub bramy, których dotyczy problem:

• Dokładna wersja, wydanie i numer kompilacji systemu Windows

• Liczba procesorów

• Ilość pamięci RAM

• Ilość pamięci przydzielonej do programu SQL Server

• Czy program SQL Server jest 32-bitowy i czy została włączona funkcja AWE

  Większość tych informacji można znaleźć w programie SQL Server Management Studio lub SQL Server Enterprise Manager. W tym celu otwórz okno Właściwości serwera, a następnie wybierz kartę Ogólne i Pamięć. Karta Ogólne zawiera wersję programu SQL Server, wersję systemu Windows, platformę, ilość pamięci RAM i liczbę procesorów. Karta Pamięć zawiera pamięć przydzieloną do programu SQL Server. W programie Microsoft SQL Server 2008 karta Pamięć zawiera również opcję AWE.

  Jeśli system operacyjny jest 32-bitowy, a rozmiar pamięć RAM to minimum 4 GB, sprawdź, czy przełączniki /pae lub /3gb istnieją w pliku Boot.ini. Konfiguracja tych opcji może być niepoprawna, jeśli serwer został pierwotnie zainstalowany z 4 GB lub mniej pamięci RAM, a pamięć RAM została później uaktualniona.

  W przypadku serwerów 32-bitowych, które mają 4 GB pamięci RAM, przełącznik /3gb w pliku Boot.ini zwiększa ilość pamięci, którą program SQL Server może adresować (z 2 GB do 3 GB). W przypadku serwerów 32-bitowych, które mają 4 GB pamięci RAM, przełącznik /3gb w pliku Boot.ini może ograniczyć ilość pamięci, którą SQL Server może adresować. W przypadku tych systemów dodaj przełącznik /pae do pliku Boot.ini, a następnie włącz funkcję AWE w programie SQL Server.

  W systemie z wieloma procesorami sprawdź ustawienie Maksymalny stopień równoległości (MAXDOP) . W programie SQL Server 2008 ta opcja znajduje się na karcie Zaawansowane w oknie dialogowym Właściwości serwera.

  Wartość domyślna to 0, co oznacza, że będą używane wszystkie dostępne procesory. Ustawienie 0 jest odpowiednie dla serwerów z maksymalnie ośmioma procesorami. W przypadku serwerów, które mają więcej niż osiem procesorów, czas potrzebny programowi SQL Server do koordynowania użycia wszystkich procesorów może zmniejszać produktywność pracy. Dlatego serwery, które mają więcej niż osiem procesorów, zazwyczaj powinny mieć maksymalny stopień równoległości ustawiony na wartość 8. W tym celu uruchom następujące polecenie w analizatorze zapytań SQL:

  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  

• Litery dysku zawierające magazyn danych, bazy danych programu Operations Manager i pliki tempdb

• Określa, czy oprogramowanie antywirusowe jest skonfigurowane do wykluczania plików danych i dzienników SQL (skanowanie plików bazy danych SQL Server za pomocą oprogramowania antywirusowego może obniżyć wydajność).

• Ilość wolnego miejsca na dyskach zawierających magazyn danych, bazę danych programu Operations Manager i pliki Tempdb

• Typ magazynu (SAN lub lokalny)

• Poziom RAID (0, 1, 5, 0+1 lub 1+0) dla dysków używanych przez program SQL Server

• Jeśli jest używany magazyn SAN: liczba jednostek dyskowych LUN używanych przez program SQL Server

• Jeśli konwertowany pakiet administracyjny programu Exchange 2007 jest używany lub kiedykolwiek był używany: liczba wierszy w tabeli w LocalizedText bazie danych programu Operations Manager i w EventPublisher tabeli w bazie danych magazynu danych

  Aby określić ilości w wierszach, uruchom następujące polecenia:

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

Liczniki służące do identyfikowania wykorzystania pamięci

Nazwa licznika wydajności	opis
Wystąpienie> MSSQL$<: Menedżer: oczekiwana długość życia strony	Jak długo strona będzie utrwalana w puli buforów. Jeśli ta wartość wynosi mniej niż 300 sekund, może to oznaczać, że serwer potrzebuje więcej pamięci. Może to również wynikać z fragmentacji indeksu.
Wystąpienie> MSSQL$<: Menedżer: Zapisy z opóźnieniem na sekundę	Składnik zapisywania z opóźnieniem zwalnia miejsce w buforze, przenosząc strony na dysk. Ogólnie rzecz biorąc, wartość nie powinna stale przekraczać 20 zapisów na sekundę. W idealnym przypadku byłaby ona bliska zeru.
Pamięć: dostępna pamięć (MB)	Wartości poniżej 100 MB mogą wskazywać na nadmierne wykorzystanie pamięci. Nadmierne wykorzystanie pamięci jest wyraźnie zauważalne, gdy ta ilość jest mniejsza niż 10 MB.
Proces: bajty prywatne: _Suma	Jest to ilość pamięci (fizyczna i strony) używanej przez wszystkie połączone procesy.
Proces: zestaw roboczy: _Suma	Jest to ilość pamięci fizycznej używanej przez wszystkie połączone procesy. Jeśli wartość tego licznika jest znacznie poniżej wartości parametru Process: Private Bytes: _Total, oznacza to, że procesy są zbyt mocno stronicowane. Różnica większa niż 10% ma prawdopodobnie duże znaczenie.

Liczniki służące do identyfikowania nadmiernego wykorzystania dysku

Przechwyć te liczniki dysków fizycznych dla wszystkich dysków z plikami danych lub dzienników SQL:

• Procent czasu bezczynności: Jaki czas bezczynności dysku jest zgłaszany. Wszystkie wartości poniżej 50 procent mogą wskazywać na wąskie gardło dysku.

• Średnia długość kolejki dysku: ta wartość nie powinna przekraczać dwukrotności liczby jednostek dyskowych w jednostce LUN. Jeśli na przykład jednostka LUN ma 25 jednostek dyskowych, akceptowalna jest wartość 50. Jeśli jednak jednostka LUN ma 10 jednostek dyskowych, wartość 25 jest zbyt wysoka. Można zastosować następujące wzory zależnie od poziomu macierzy RAID i liczby dysków w konfiguracji RAID:

  • RAID 0: wszystkie dyski działają w zestawie RAID 0

  • Średnia długość< kolejki dysku = # (dyski w tablicy) *2

  • RAID 1: połowa dysków wykonuje pracę; dlatego tylko połowę z nich można wliczać do kolejki dysku

  • Średnia długość< kolejki dysku = # (dyski w tablicy/2) *2

  • RAID 10: połowa dysków wykonuje pracę; dlatego tylko połowę z nich można wliczać do kolejki dysku

  • Średnia długość< kolejki dysku = # (dyski w tablicy/2) *2

  • RAID 5: wszystkie dyski działają w zestawie RAID 5

  • Średnia długość< kolejki dysku = # dyski w tablicy *2

  • Średnia liczba sekund pracy dysku/transfer: liczba sekund potrzebnych do ukończenia jednej operacji we/wy na dysku

  • Średnia liczba sekund pracy dysku/odczyt: średni czas w sekundach potrzebny na odczyt danych z dysku

  • Średnia liczba sekund pracy dysku/zapis: średni czas w sekundach potrzebny na zapis danych na dysku

    Ostatnie trzy liczniki na tej liście powinny stale mieć wartości około 0,020 (20 ms) lub mniej i nigdy nie powinny przekraczać 0,050 (50 ms). Poniższe progi zostały udokumentowane w przewodniku rozwiązywania problemów z wydajnością programu SQL Server:

    • Mniej niż 10 ms: bardzo dobrze
    • Od 10 do 20 ms: w porządku
    • Od 20 do 50 ms: powolne działanie, wymaga uwagi
    • Więcej niż 50 ms: poważne wąskie gardło operacji we/wy

  • Bajty dysku/s: liczba bajtów transferowanych na dysk lub z dysku na sekundę

  • Transfery dyskowe/s: liczba operacji we/wy na sekundę (IOPS)

  Gdy czas bezczynności jest niski (10 procent lub mniej), oznacza to, że dysk jest w pełni wykorzystywany. W takim przypadku ostatnie dwa liczniki na tej liście (Bajty dysku/s i Transfery dyskowe/s) stanowią dobry wskaźnik maksymalnej przepływności dysku odpowiednio w bajtach i operacjach we/wy na sekundę. Przepływność dysku SAN jest bardzo zmienna zależnie od liczby jednostek dyskowych, szybkości dysków i szybkości kanału. Najlepszym rozwiązaniem jest sprawdzenie u dostawcy sieci SAN, ile bajtów i operacji we/wy na sekundę powinien obsługiwać dysk. Jeśli % czasu bezczynności jest niski, a wartości tych dwóch liczników nie spełniają oczekiwanej przepływności dysku, poproś dostawcę rozwiązania SAN o pomoc w rozwiązywaniu problemów.

Przewodnik rozwiązywania problemów z wydajnością programu SQL Server zawiera bardziej szczegółowe informacje na temat rozwiązywania problemów z wydajności programu SQL Server.

Liczniki wydajności programu Operations Manager

W poniższych sekcjach opisano liczniki wydajności, których można użyć do monitorowania i rozwiązywania problemów z wydajnością programu Operations Manager.

Rola serwera bramy

Ogólne liczniki wydajności

Te liczniki wskazują ogólną wydajność bramy:

Nazwa licznika wydajności
Procesor (_Total)\% czasu procesora
Pamięć\% zatwierdzonych bajtów w użyciu
Karta sieciowa(*)\Bajty łącznie/s
Dysk logiczny(*)\% czas bezczynności
Dysk logiczny(*)\Średnia długość kolejki dysku

Ogólne liczniki wydajności procesu w programie Operations Manager

Te liczniki wskazują ogólną wydajność procesów programu Operations Manager w bramie:

Nazwa licznika wydajności	opis
Process(HealthService)\% Czas procesora
Proces (HealthService)\Bajty prywatne	W zależności od liczby agentów, których zarządza ta brama, ta liczba może się różnić i może być kilkaset megabajtów
Proces (Usługa kondycji)\Liczba wątków
Proces (Usługa kondycji)\Bajty wirtualne
Proces (Usługa kondycji)\Zestaw roboczy
Process(MonitoringHost*)\% Czas procesora
Proces (MonitoringHost*)\Bajty prywatne
Proces (Host monitorowania*)\Liczba wątków
Proces (Host monitorowania*)\Bajty wirtualne
Proces (Host monitorowania*)\Zestaw roboczy

Liczniki wydajności specyficzne dla programu Operations Manager

Te liczniki to liczniki specyficzne dla programu Operations Manager, które wskazują wydajność określonych aspektów programu Operations Manager w bramie:

Nazwa licznika wydajności	Opis
Usługa kondycji\Liczba przepływów pracy
Grupy zarządzania usługami kondycji(*)\Aktywne przekazywanie plików	Liczba transferów plików, które obsługuje ta brama. Reprezentuje ona liczbę plików pakietów administracyjnych przekazywanych do agentów. Jeśli ta wartość pozostaje na wysokim poziomie przez długi czas, a w danym momencie nie importuje się zbyt wielu pakietów administracyjnych, te warunki mogą spowodować problem, który wpłynie na transfer plików.
Grupy zarządzania usługi kondycji(*)\Procent wykorzystania kolejki wysyłania	Rozmiar kolejki trwałej. Jeśli ta wartość pozostaje wyższa niż 10 przez długi czas i nie spada, oznacza to, że trwa tworzenie kopii zapasowej kolejki. Ten warunek jest spowodowany przeciążonym systemem programu Operations Manager, ponieważ serwer zarządzania lub baza danych jest zbyt zajęta lub jest w trybie offline.
Łącznik programu OpsMgr\Bajty odebrane	Liczba bajtów sieci odebranych przez bramę — czyli liczbę bajtów przychodzących przed dekompresją.
Łącznik programu OpsMgr\Bajty przesłane	Liczba bajtów sieci wysyłanych przez bramę — czyli liczba bajtów wychodzących po kompresji.
Łącznik programu OpsMgr\Bajty odbierane	Liczba bajtów danych odebranych przez bramę — czyli ilość danych przychodzących po dekompresji.
Łącznik programu OpsMgr\Bajty przesyłane	Liczba bajtów danych wysyłanych przez bramę — czyli ilość danych wychodzących przed kompresją.
Łącznik programu OpsMgr\Otwarte połączenia	Liczba otwartych połączeń w bramie. Ta liczba powinna być taka sama jak liczba agentów lub serwerów zarządzania, które są bezpośrednio połączone z bramą.

Rola serwera zarządzania

Ogólne liczniki wydajności

Te liczniki wskazują ogólną wydajność serwera zarządzania:

Nazwa licznika wydajności
Procesor (_Total)\% czasu procesora
Pamięć\% zatwierdzonych bajtów w użyciu
Karta sieciowa(*)\Bajty łącznie/s
Dysk logiczny(*)\% czas bezczynności
Dysk logiczny(*)\Średnia długość kolejki dysku

Ogólne liczniki wydajności procesu w programie Operations Manager

Te liczniki wskazują ogólną wydajność procesów programu Operations Manager na serwerze zarządzania:

Nazwa licznika wydajności	opis
Process(HealthService)\% Czas procesora
Proces (HealthService)\Bajty prywatne	W zależności od liczby agentów, których zarządza ten serwer zarządzania, ta liczba być różna i wynosić kilkaset megabajtów.
Proces (Usługa kondycji)\Liczba wątków
Proces (Usługa kondycji)\Bajty wirtualne
Proces (Usługa kondycji)\Zestaw roboczy
Process(MonitoringHost*)\% Czas procesora
Proces (MonitoringHost*)\Bajty prywatne
Proces (Host monitorowania*)\Liczba wątków
Proces (Host monitorowania*)\Bajty wirtualne
Proces (Host monitorowania*)\Zestaw roboczy

Liczniki wydajności specyficzne dla programu Operations Manager

Te liczniki to liczniki specyficzne dla programu Operations Manager, które wskazują wydajność określonych aspektów programu Operations Manager na serwerze zarządzania:

Nazwa licznika wydajności	Opis
Usługa kondycji\Liczba przepływów pracy	Liczba przepływów pracy uruchomionych na tym serwerze zarządzania.
Grupy zarządzania usługami kondycji(*)\Aktywne przekazywanie plików	Liczba transferów plików, które obsługuje ten serwer zarządzania. Reprezentuje ona liczbę plików pakietów administracyjnych przekazywanych do agentów. Jeśli ta wartość pozostaje na wysokim poziomie przez długi czas, a w danym momencie nie importuje się zbyt wielu pakietów administracyjnych, te warunki mogą spowodować problem, który wpłynie na transfer plików.
Grupy zarządzania usługi kondycji(*)\Procent wykorzystania kolejki wysyłania	Rozmiar kolejki trwałej. Jeśli ta wartość pozostaje wyższa niż 10 przez długi czas i nie spada, oznacza to, że trwa tworzenie kopii zapasowej kolejki. Ten warunek jest spowodowany przeciążeniem systemu programu Operations Manager, wynikającym z tego, że system ten (na przykład główny serwer zarządzania) jest zbyt zajęty lub działa w trybie offline.
Grupy zarządzania usługami kondycji(*)\Wskaźnik porzucania elementów powiązanego źródła danych	Liczba elementów danych porzuconych przez serwer zarządzania dla akcji zapisu zbierania danych bazy danych lub magazynu danych. Jeśli ta wartość licznika nie 0jest , serwer zarządzania lub baza danych jest przeciążona, ponieważ nie może obsłużyć przychodzącego elementu danych wystarczająco szybko lub ponieważ występuje pęknięcie elementu danych. Porzucone elementy danych będą ponownie wysyłane przez agentów. Po zakończeniu przeciążenia lub awarii te elementy danych zostaną wstawione do bazy danych lub magazynu danych.
Grupy zarządzania usługami kondycji(*)\Wskaźnik elementów przychodzących powiązanego źródła danych	Liczba elementów danych odebranych przez serwer zarządzania dla akcji zapisu zbierania danych bazy danych lub magazynu danych.
Grupy zarządzania usługami kondycji(*)\Wskaźnik publikowania elementów powiązanego źródła danych	Liczba elementów danych zapisanych przez serwer zarządzania w bazie danych lub magazynie danych dla akcji zapisu zbierania danych bazy danych lub magazynu danych.
Łącznik programu OpsMgr\Bajty odebrane	Liczba bajtów sieciowych odebranych przez serwer zarządzania — czyli rozmiar bajtów przychodzących przed dekompresją.
Łącznik programu OpsMgr\Bajty przesłane	Liczba bajtów sieciowych wysłanych przez serwer zarządzania — czyli rozmiar bajtów wychodzących po kompresji.
Łącznik programu OpsMgr\Bajty odbierane	Liczba bajtów danych odebranych przez serwer zarządzania — czyli rozmiar danych przychodzących po dekompresie.
Łącznik programu OpsMgr\Bajty przesyłane	Liczba bajtów danych wysyłanych przez serwer zarządzania — czyli rozmiar danych wychodzących przed kompresją.
Łącznik programu OpsMgr\Otwarte połączenia	Liczba połączeń otwartych na serwerze zarządzania. Powinna być ona taka sama jak liczba agentów na głównym serwerze zarządzania, które są z nim bezpośrednio połączone.
Moduły akcji zapisu w bazie danych programu OpsMgr(*)\Średni rozmiar partii	Liczba elementów danych lub partii odbieranych przez moduły akcji zapisu bazy danych. Jeśli ta liczba wynosi 5000, następuje wzrost liczby elementów danych.
Moduły akcji zapisu w bazie danych programu OpsMgr(*)\Średni czas przetwarzania	Liczba sekund, przez które moduły akcji zapisu bazy danych muszą wstawić partię do bazy danych. Jeśli ta liczba jest często większa niż 60, występuje problem z wydajnością wstawiania bazy danych.
Moduł zapisu w magazynie danych programu OpsMgr(*)\Średni czas przetwarzania partii, ms	Liczba milisekund akcji zapisu magazynu danych w celu wstawienia partii elementów danych do magazynu danych.
Moduł zapisu w magazynie danych programu OpsMgr(*)\Średni rozmiar partii	Średnia liczba elementów danych lub partii odebranych przez moduły akcji zapisu magazynu danych.
Moduł zapisu w magazynie danych programu OpsMgr(*)\Partie/s	Liczba partii odbieranych przez moduły akcji zapisu magazynu danych na sekundę.
Moduł zapisu w magazynie danych programu OpsMgr(*)\Elementy danych/s	Liczba elementów danych odbieranych przez moduły akcji zapisu magazynu danych na sekundę.
Moduł zapisu w magazynie danych programu OpsMgr(*)\Liczba porzuconych elementów danych	Liczba elementów danych porzucanych przez moduły akcji zapisu magazynu danych na sekundę.
Moduł zapisu w magazynie danych programu OpsMgr(*)\Całkowita liczba błędów	Liczba błędów, które wystąpiły w module akcji zapisu w magazynie danych.