Rozwiązywanie problemów ze stanami szarego agenta 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 wyszarzone 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 agenta i ikony w okienku Monitorowanie .

Przyczyny stanu szarości

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

• Awaria pulsu
• Nieprawidłowa konfiguracja
• Niepowodzenie systemowych przepływów pracy
• 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
• Usługa kondycji nie jest uruchomiona

Zakres problemu

Przed rozpoczęciem rozwiązywania problemu z wyszarzonym agentem należy najpierw zrozumieć topologię programu Operations Manager, a następnie zdefiniować zakres problemu. Poniższe pytania mogą pomóc w określeniu zakresu problemu:

• Ilu agentów dotyczy problem?
• Czy agenci napotykają problem w tym samym segmencie sieci?
• Czy agenci raportują na tym samym serwerze zarządzania?
• Jak często agenci wprowadzają i pozostają w stanie szarości?
• Jak zazwyczaj 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 dotyczące awarii pulsu są generowane dla tych agentów?
• Czy ten problem występuje o określonej porze dnia?
• Czy ten problem będzie się powtarzać w przypadku przełączenia tych agentów w tryb failover na inny serwer zarządzania lub bramę?
• Kiedy ten problem się rozpoczął?
• Czy wprowadzono jakiekolwiek zmiany w agentach, serwerach zarządzania, bramie lub grupie zarządzania?
• Czy dotyczy to agentów systemów klastrowanych systemu Windows?
• Czy folder Stan usługi kondycji jest wykluczony ze skanowania antywirusowego?

Strategia rozwiązywania problemów

Strategia rozwiązywania problemów będzie podyktowana tym, 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, którzy zgłaszają raport 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, które raportują 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 agenta, 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ącej 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 możesz wyczyścić pamięć podręczną agenta, aby pomóc w tymczasowym rozwiązaniu problemu, problem wystąpi 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ń antywirusowych związanych z programem 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. Określ, czy usługa kondycji jest włączona i jest obecnie uruchomiona na serwerze zarządzania lub bramie. Jeśli usługa kondycji przestała odpowiadać, wygeneruj zrzut ADPlus w trybie zawieszenia usługi, aby pomóc w ustaleniu przyczyny problemu. Aby uzyskać więcej informacji, zobacz Jak używać ADPlus.vbs do rozwiązywania problemów z "zawiesza się" i "awariami"

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

   Identyfikator zdarzenia: 1102
   Źródło zdarzeń: HealthService
   Opis zdarzenia:
   Nie można zainicjować reguły/monitora "%4" działającego dla wystąpienia %3 o identyfikatorze:"%2" i nie zostanie załadowany. Grupa zarządzania "%1"

   Identyfikator zdarzenia: 1103
   Źródło zdarzeń: HealthService
   Opis zdarzenia:
   Podsumowanie: %2 reguły/monitory nie powiodły się i zostały wyładowane, %3 z nich osiągnęło limit błędów, który uniemożliwia automatyczne ponowne ładowanie. Grupa zarządzania "%1". Jest to tylko zdarzenie sumaryczne. Zobacz inne zdarzenia z opisami nieobsadzone reguły/monitory.

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

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

   Identyfikator zdarzenia: 1106
   Źródło zdarzeń: HealthService
   Opis zdarzenia:
   Nie można uzyskać dostępu do profilu Uruchom jako w postaci zwykłego tekstu w przepływie pracy %4 z 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 zdarzeń: HealthService
   Opis zdarzenia:
   Konto profilu Uruchom jako w przepływie pracy "%4", na przykład "%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 zdarzeń: HealthService
   Opis zdarzenia:
   Nie można rozpoznać konta określonego w profilu Uruchom jako "%7". W szczególności konto jest używane w bezpiecznym zastąpieniu odwołania "%6". %n%n Ten warunek mógł wystąpić, ponieważ konto nie zostało skonfigurowane do dystrybucji na tym komputerze. Aby rozwiązać ten problem, musisz otworzyć określony poniżej profil Uruchom jako, zlokalizować wpis Konta określony w jego identyfikatorze SSID i w razie potrzeby rozesłać konto na ten komputer lub zmienić ustawienie w profilu, aby obiekt docelowy nie używał określonego konta. %n%nZarządzanie grupą: %1 %nUżytkuj jako profil: %7 %nNazwa właściwościSecureReferenceOverride: %6 %nSecureReferenceOverride identyfikator: %4 %nNazwa zadania: %3 %n Identyfikator zadania: %2 %n Identyfikator SSID konta konta: %5

   Identyfikator zdarzenia: 4000
   Źródło zdarzeń: HealthService
   Opis zdarzenia:
   Host monitorowania nie odpowiada lub uległ awarii. Kod stanu błędu hosta to %1.

   Identyfikator zdarzenia: 21016
   Źródło zdarzenia: Łącznik programu OpsMgr
   Opis zdarzenia:
   Program OpsMgr nie może skonfigurować kanału komunikacji dla %1 i nie ma hostów trybu failover. Komunikacja zostanie wznowiona, gdy użytkownik %1 będzie dostępny, a komunikacja z tego komputera będzie 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 to %3(%4). Sprawdź, czy istnieje łączność sieciowa, serwer jest uruchomiony i zarejestrował swój port nasłuchiwania, a żadne zapory nie blokują ruchu do miejsca docelowego.

   Identyfikator zdarzenia: 20070
   Źródło zdarzenia: Łącznik programu OpsMgr
   Opis zdarzenia:
   Łącznik Programu OpsMgr jest 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 jest autoryzowany do komunikacji 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ą zatwierdzone, 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 w razie potrzeby ponownie wydaj certyfikat%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 < ("<nazwa>") osiągnął maksymalny rozmiar <mb>. Jest prawdopodobne, że długotrwała transakcja uniemożliwia czyszczenie magazynu wersji i powoduje, że jest ona kompilowana w rozmiarze. Aktualizacje zostaną odrzucone, dopóki długotrwała transakcja nie zostanie całkowicie zatwierdzona lub wycofana. Możliwa długotrwała transakcja:
   SessionId: <wartość>
   Kontekst sesji: <wartość>
   ThreadId kontekstu sesji: <wartość>.
   Oczyszczanie: <wartość>

3. Jeśli zlokalizujesz następujące określone zdarzenia, postępuj zgodnie z następującymi wytycznymi:

   • Zdarzenia 1102 i 1103: Te zdarzenia wskazują, że nie można załadować niektórych przepływów pracy. Jeśli są to podstawowe przepływy pracy systemu, te zdarzenia mogą spowodować problem. W tym przypadku skoncentruj się na rozwiązywaniu tych zdarzeń.

   • Zdarzenia 1104, 1105, 1106, 1107 i 1108: Te zdarzenia mogą powodować zdarzenia 1102 i 1103. Zazwyczaj taka sytuacja występuje z powodu błędnie 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ą biblioteki DLL lub brakującymi kluczami rejestru, możesz rozwiązać ten problem, ponownie instalając agenta. Jeśli problem będzie się powtarzać, spróbuj go rozwiązać przy użyciu następujących metod:

     • Uruchom przechwytywanie monitora procesów do momentu awarii procesu. Aby uzyskać więcej informacji, zobacz Monitor procesów w wersji 3.53.
     • Generowanie zrzutu ADPlus w trybie awarii. Aby uzyskać więcej informacji, zobacz Jak używać ADPlus.vbs do rozwiązywania problemów z "zawiesza się" i "awariami"

   • Identyfikator zdarzenia 21006: to zdarzenie wskazuje, że występują problemy z komunikacją 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 poprawnego certyfikatu. Jeśli jest używany protokół Kerberos, sprawdź, czy agent może komunikować się z usługą Active Directory. Jeśli uwierzytelnianie działa poprawnie, 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 jednoczesny ś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 i czy jakiekolwiek urządzenie między tymi dwoma składnikami próbuje zoptymalizować ruch, czy też porzuca niektóre pakiety. Aby uzyskać więcej informacji, zobacz Zbieranie danych przy użyciu monitora sieci.

   • 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, którzy raportują 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 jest monitorowany przez serwer zarządzania lub bramę. Takie obciążenia mogą obejmować urządzenia sieciowe, agentów międzyplatformowych, transakcje syntetyczne, agentów systemu Windows i komputery bez agenta.

2. Określ, czy usługa kondycji jest uruchomiona na serwerze zarządzania, czy w bramie.

3. Określ, czy serwer zarządzania jest uruchomiony w trybie konserwacji. Jeśli jest to konieczne, usuń serwer z trybu konserwacji.

4. Sprawdź dziennik zdarzeń programu Operations Manager agenta pod kątem zdarzeń wymienionych w scenariuszu 2. Jeśli istnieje identyfikator zdarzenia 21006, postępuj zgodnie z tymi samymi wytycznymi, które zostały wymienione w rozwiązaniu 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 serwerem nadrzędnym może być dowolny serwer zarządzania. (Zapoznaj się z krokiem 3 w rozwiązaniu scenariusza 2).

5. Sprawdź dziennik zdarzeń programu Operations Manager pod kątem następujących zdarzeń. Te zdarzenia zazwyczaj wskazują, że problemy z wydajnością występują na serwerze zarządzania lub w SQL Server firmy Microsoft hostującym OperationsManager bazę danych lubOperationsManagerDW:

   Identyfikator zdarzenia: 2115
   Źródło zdarzeń: HealthService
   Opis zdarzenia:
   Powiązanie źródła danych w grupie zarządzania %1 opublikowało elementy w przepływie pracy, ale nie otrzymał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 zdarzeń: HealthService
   Opis zdarzenia:
   Lokalna usługa kondycji nie jest w dobrej kondycji. Przepływ zmiany stanu jednostki jest zablokowany z oczekiwaniem na potwierdzenie. %n%nZarządzanie grupą: %2 %n Identyfikator grupy zarządzania: %1

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

   Identyfikator zdarzenia: 31551
   Źródło zdarzenia: Moduły usługi kondycji
   Opis zdarzenia:
   Nie można przechowywać danych w Data Warehouse. Operacja zostanie ponowiona.%rException '%5': %6 %n%nBłędą one lub więcej przepływów pracy. %n%nNazwa przepływu pracy: %2 %nNazwa instalacji: %3 %n Identyfikator instalacji: %4 %nZarządzanie grupą: %1

   Identyfikator zdarzenia: 31552
   Źródło zdarzenia: Moduły usługi kondycji
   Opis zdarzenia:
   Nie można przechowywać danych w Data Warehouse.%rException %5: %6 %n%nDotknęło to lub więcej przepływów pracy. %n%nNazwa przepływu pracy: %2 %nNazwa instalacji: %3 %n Identyfikator instalacji: %4 %nZarządzanie grupą: %1

   Identyfikator zdarzenia: 31553
   Źródło zdarzenia: Moduły usługi kondycji
   Opis zdarzenia:
   Dane zostały zapisane w Data Warehouse obszarze przejściowym, ale przetwarzanie nie powiodło się w jednej z kolejnych operacji.%rRozumiałość %5: %6 %n%nDotknęło to co najmniej jednego przepływu pracy. %n%nNazwa przepływu pracy: %2 %nNazwa instalacji: %3 %n Identyfikator instalacji: %4 %nZarządzanie grupą: %1

   Identyfikator zdarzenia: 31557
   Źródło zdarzenia: Moduły usługi kondycji
   Opis zdarzenia:
   Nie można uzyskać informacji o stanie procesu synchronizacji z bazy danych Data Warehouse. Operacja zostanie ponowiona.%rException '%5': %6 %n%nBłędą one lub więcej przepływów pracy. %n%nNazwa przepływu pracy: %2 %nNazwa instalacji: %3 %n Identyfikator instalacji: %4 %nZarządzanie grupą: %1

6. Identyfikator zdarzenia 3155X może być również rejestrowany z powodu nieprawidłowych konfiguracji konta Uruchom jako lub brakujących uprawnień dla kont Uruchom jako.

Scenariusze 4

Wszyscy agenci, którzy raportują do określonego serwera zarządzania alternatywnego sporadycznie między stanami w dobrej kondycji i szarości. Albo wszyscy agenci w środowisku sporadycznie przełączają się między stanami w dobrej kondycji i szarości.

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, odkrycia 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 tymczasowy błąd 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 redystrybucji mp do agentów. Jeśli zmiana ma wpływ na większą bazę agentów, może to spowodować zwiększone użycie zasobów systemowych w bazie danych programu Operations Manager i serwerach programu Operations Manager.

Kluczem do rozwiązywania problemów w tych scenariuszach jest zrozumienie czasu niedostępności serwera i godziny, w której 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 aktualizacji konfiguracji (która jest spowodowana przez importowanie i odnajdywanie plików MP) typowe wąskie gardła to najpierw procesor CPU, a po drugie operacje we/wy dysku instalacyjnego programu Operations Manager. Serwer zarządzania jest odpowiedzialny za przekazywanie plików konfiguracji do agentów docelowych.

W przypadku zbierania danych operacyjnych wąskie gardła są zwykle spowodowane przez procesor CPU. Operacje we/wy dysku mogą również mieć maksymalną pojemność, ale nie jest to tak prawdopodobne. Serwer zarządzania jest odpowiedzialny za dekompresję i odszyfrowywanie przychodzących danych operacyjnych oraz wstawianie ich do operacyjnej bazy danych. Wysyła 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 zestawów ACK.

Bramy

Brama jest powiązana zarówno z procesorem CPU, jak i powiązana we/wy. Gdy brama przekazuje dużą ilość danych, zarówno operacje procesora CPU, jak i operacji we/wy mogą wykazywać wysokie użycie. Większość użycia procesora CPU jest spowodowana dekompresją, kompresją, szyfrowaniem i odszyfrowywaniem danych przychodzących, a także transferem tych danych. Wszystkie dane odbierane przez bramę i agentów są przechowywane w stałej kolejce na dysku do odczytu i przekazywania 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 w trybie offline, a następnie musi obsługiwać zgromadzone dane agenta wygenerowane przez agentów i próbował wysłać, gdy brama była jeszcze w trybie offline.

Aby rozwiązać ten problem w tej sytuacji, zbierz następujące informacje dla 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 Stan usługi kondycji

• Czy oprogramowanie antywirusowe jest skonfigurowane do wykluczania magazynu usługi kondycji

  Uwaga

  Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące wykluczeń antywirusowych związanych z programem Operations Manager.

• Poziom RAID (0, 1, 5lub 0+11+0) dla dysku używanego przez stan usługi kondycji

• Liczba dysków używanych w systemie RAID

• Czy pamięć podręczna zapisu z użyciem baterii jest włączona na kontrolerze macierzy

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

Operacyjna baza danych (OperationsManager)

OperationsManager W przypadku bazy danych najbardziej prawdopodobnym wąskim gardłem jest tablica dysków. Jeśli macierz dysków nie ma maksymalnej pojemności we/wy, następnym najbardziej prawdopodobnym wąskim gardłem jest procesor CPU. Baza danych będzie doświadczać sporadycznych spowolnienia i burz danych operacyjnych (duża częstość występowania zdarzeń, alertów oraz danych wydajności lub zmian stanu, które utrzymują się przez stosunkowo długi czas). Krótki wybuch zazwyczaj 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 CPU jest spowodowane zmianą SQL Server. Może się to zdarzyć, gdy masz duże i złożone zapytania, duże wstawianie danych i pielęgnację dużych tabel (co domyślnie ma miejsce o północy). Zazwyczaj pielęgnacja nawet dużych zdarzeń i tabel danych wydajności nie zużywa nadmiernych zasobów procesora CPU ani dysku. Jednak pielęgnacja tabel alertów i zmian stanu może być intensywnie obciążana procesorem CPU dla dużych tabel.

Baza danych jest również powiązana z procesorem CPU, gdy obsługuje serie redystrybucji konfiguracji, które są spowodowane importowaniem plików MP lub dużą zmianą przestrzeni wystąpienia. W takich przypadkach usługa Config wysyła zapytanie do bazy danych o nową konfigurację agenta. Zwykle powoduje to skoki użycia procesora CPU w bazie danych, zanim usługa wyśle aktualizacje konfiguracji do agentów.

Magazyn danych (OperationsManagerDW)

OperationsManagerDW W przypadku bazy danych najbardziej prawdopodobnym wąskim gardłem jest tablica dysków. Zwykle dzieje się tak z powodu dużych operacji wstawiania danych. W takich przypadkach dyski są w większości zajęte wykonywaniem zapisów. Zazwyczaj dyski wykonują kilka operacji odczytu, z wyjątkiem obsługi ręcznie wygenerowanych widoków raportowania, ponieważ te zapytania są uruchamiane w magazynie danych.

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

Ogólne rozwiązywanie problemów

Aby rozwiązać ten problem w tej sytuacji, zbierz następujące informacje dla 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 SQL Server

• Czy SQL Server jest 32-bitowa i czy jest włączona usługa AWE

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

  Jeśli system operacyjny jest 32-bitowy, a pamięć RAM wynosi co najmniej 4 GB, sprawdź, czy /pae przełączniki lub /3gb istnieją w Boot.ini. Plik. Te opcje można skonfigurować niepoprawnie, jeśli serwer został pierwotnie zainstalowany przez 4 GB lub mniej pamięci RAM i jeśli pamięć RAM została później uaktualniona.

  W przypadku serwerów 32-bitowych, które mają 4 GB pamięci RAM, /3gb przełącznik w Boot.ini zwiększa ilość pamięci, którą może zająć SQL Server (z 2 GB do 3 GB). W przypadku serwerów 32-bitowych, które mają więcej niż 4 GB pamięci RAM, /3gb przełącznik w Boot.ini może faktycznie ograniczyć ilość pamięci, którą może rozwiązać SQL Server. W przypadku tych systemów dodaj /pae przełącznik do Boot.ini, a następnie włącz usługę AWE w SQL Server.

  W systemie z wieloma procesorami sprawdź ustawienie Max Degree of Parallelism (MAXDOP ). W SQL Server 2008 r. ta opcja znajduje się na karcie Zaawansowane w oknie dialogowym Właściwości serwera.

  Wartość domyślna to 0, co oznacza, że zostaną użyte wszystkie dostępne procesory. Ustawienie 0 jest odpowiednie dla serwerów, które mają co najmniej osiem procesorów. W przypadku serwerów, które mają więcej niż osiem procesorów, czas potrzebny SQL Server koordynowania użycia wszystkich procesorów może przynosić efekt przeciwny do zamierzonego. W związku z tym w przypadku serwerów, które mają więcej niż osiem procesorów, na ogół należy ustawić maksymalny stopień równoległości 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 dysków zawierające pliki magazynu danych, bazy danych programu Operations Manager i bazy danych Tempdb

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

• Ilość wolnego miejsca na dyskach zawierających pliki magazynu danych, bazy danych programu Operations Manager i bazy danych Tempdb

• Typ magazynu (sieć SAN lub lokalna)

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

• Jeśli jest używany magazyn SIECI SAN: liczba wrzecion w każdej jednostce LUN używanej przez SQL Server

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

  Aby określić kwoty wierszy, uruchom następujące polecenia:

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

Liczniki identyfikujące obciążenie pamięcią

Liczniki do identyfikowania ciśnienia dysku

Przechwyć te liczniki dysków fizycznych dla wszystkich dysków zawierających dane SQL lub pliki dziennika:

• % czasu bezczynności: ile czasu bezczynności dysku jest zgłaszane. Wszystko poniżej 50 procent może wskazywać na wąskie gardło dysku.

• Średnia długość kolejki dysku: ta wartość nie powinna przekraczać dwukrotnie większej liczby wrzecion w jednostce LUN. Jeśli na przykład jednostka LUN ma 25 wrzecion, dopuszczalna jest wartość 50. Jeśli jednak jednostka LUN ma 10 wrzecion, wartość 25 jest zbyt wysoka. W konfiguracji RAID można użyć następujących formuł na podstawie poziomu RAID i liczby dysków:

  • 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ę; W związku z tym tylko połowa z nich może być zliczona do kolejki dysków

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

  • RAID 10: połowa dysków "wykonuje pracę"; W związku z tym tylko połowa z nich może być zliczona do kolejki dysków

  • Ś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 dysku/transfer: liczba sekund potrzebnych do ukończenia jednego we/wy dysku

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

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

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

    • Mniej niż 10 ms: bardzo dobry
    • Od 10 do 20 ms: ok
    • Od 20 do 50 ms: wolno, wymaga uwagi
    • Większe niż 50 ms: poważne wąskie gardło we/wy

  • Bajty dysku na sekundę: liczba bajtów przesyłanych do lub z dysku na sekundę

  • Transfery dysków na sekundę: liczba operacji wejściowych i wyjściowych na sekundę (IOPS)

  Gdy % czasu bezczynności jest niski (10 procent lub mniej), oznacza to, że dysk jest w pełni wykorzystany. W takim przypadku dwa ostatnie liczniki na tej liście (bajty dysków/s i transfery dysków/s) zapewniają dobre wskazanie maksymalnej przepływności dysku odpowiednio w bajtach i we/wy na sekundę. Przepływność dysku SAN jest bardzo zmienna, w zależności od liczby wrzecion, prędkości dysków i prędkości kanału. Najlepszym rozwiązaniem jest skontaktowanie się z dostawcą sieci SAN, aby dowiedzieć się, ile bajtów i liczby operacji we/wy na sekundę dysk powinien obsługiwać. Jeśli procent czasu bezczynności jest niski, a wartości tych dwóch liczników nie spełniają oczekiwanej przepływności dysku, skontaktuj się z dostawcą sieci SAN, aby rozwiązać problemy.

SQL Server przewodnik rozwiązywania problemów z wydajnością zapewnia dokładniejszy wgląd w rozwiązywanie problemów z wydajnością SQL Server.

Liczniki wydajności programu Operations Manager

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

Rola serwera bramy

Ogólne liczniki wydajności

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

Ogólne liczniki wydajności procesu programu Operations Manager

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

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 bramie:

Rola serwera zarządzania

Ogólne liczniki wydajności

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

Ogólne liczniki wydajności procesu programu Operations Manager

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

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: