Kluczowe wskaźniki wydajności serwera obiektów

Następujące kluczowe wskaźniki wydajności serwera obiektów mogą być monitorowane:

Łączny czas używany w granularce

Aby skonfigurować ten kluczowy wskaźnik wydajności, należy uruchomić serwer obiektów z włączonymi profilowaniem i uruchomić automatykę trigger_stats_report. Dane profilowania pokazują, ile czasu serwer ObjectServer wydał zapytania o profilowanie od klientów, w tym czas przeznaczony na automatyzacje zgłaszane przez działanie klienta. Plik trigger_stats.log zawiera czas, przez jaki każdy wyzwalacz był używany w ostatnim okresie profilowania. Aby zademonstrować, że serwer obiektów może przetwarzać wszystkie żądania w dostępnym czasie, czas przetwarzania musi być krótszy niż czas trwania okresu raportowania. Należy zauważyć, że trend tego kluczowego wskaźnika wydajności w czasie jest bardziej istotny niż jego wartość w danym momencie.

Wskazówka: W przypadku serwerów wieloprocesorowych czas przetwarzania żądań od klientów i automatyzacji może być większy niż okres raportowania ze względu na wielowątkowy charakter serwera obiektów.

Wykorzystanie procesora przez proces nco_objserv

Aby monitorować wykorzystanie procesora przez proces nco_objserv, należy skonfigurować agenta IBM® Tivoli® Monitoring i użyć go.

Wykorzystanie procesora przez procesy jest jedną z najważniejszych wielkości mierzonych w celu określenia wydajności. Dla serwera obiektów pod dużym obciążeniem wydajność jest najprawdopodobniej związana z wykorzystaniem procesora.

Wskazówka: Podczas rozwiązywania problemów z wydajnością, plik dziennika profilu i plik dziennika statystyk wyzwalacza są pierwszym miejscem, które należy zbadać. Ogólnie, jeśli łączny łączny czas dla obu klientów i wyzwalaczy jest spójny przez 60 sekund (domyślny okres granulacji), należy podjąć pewne działania. Różne metryki systemu operacyjnego mogą być również przydatne w identyfikacji, czy system jest pod wpływem stresu. Kluczowe wielkości mierzone to wykorzystanie procesora i wielkość procesu procesów Tivoli Netcool ® /OMNIbus .

Liczba wierszy w tabeli alerts.status

Wydajność zapytań nieopodatkowanych jest proporcjonalna do liczby wierszy w tabeli alerts.status. Zwiększa się liczba wierszy w tabeli alerts.status, więc czas potrzebny na wykonanie wszystkich zapytań i wykonanie wszystkich wyzwalaczy w tabeli alerts.status wzrasta. Dodatkowo, przechowując dane wiersza dla większości pamięci używanej przez serwer obiektów; dane z tabeli alerts.status dla większości tych danych wierszy. Liczba wierszy w tabeli alerts.status zależy od sieci i aplikacji, które są monitorowane. Jednakże liczba wierszy powinna być stabilna w ciągu kilku tygodni. Jeśli liczba wierszy w tabeli alerts.status wzrasta w ciągu tygodni, to w zależności od tempa wzrostu problem może być rozwijający się. Tabela alerts.status korzysta z większej ilości pamięci niż tabela alert.details i tabela alerts.journal. Więcej informacji na temat liczby zdarzeń w tabeli alerts.status zawiera sekcja Inne przydatne informacje.

Liczba wierszy w tabeli alerts.details

Wydajność zapytań wykonywanych przez klienty interfejsu GUI WWW w celu pobrania szczegółów alertu jest proporcjonalna do liczby pozycji w tabeli alerts.details. Im więcej wpisów znajduje się w tabeli alerts.details, tym wolniejsze stają się zapytania. Dodatkowo, przechowując dane wiersza dla większości pamięci używanej przez serwer obiektów; dane z tabeli alerts.details dla niektórych z tych danych wiersza. Każda pozycja w tabeli alerts.details zwiększa obciążenie dla wszystkich bram, które są skonfigurowane do przekazywania tych danych do innych serwerów ObjectServer lub innych aplikacji. Liczba wierszy w tabeli alerts.details zmienia się w zależności od sieci i aplikacji, które są monitorowane, dzień tygodnia, pory dnia itd. Jednakże liczba wierszy powinna być stabilna w ciągu kilku tygodni. Jeśli liczba wierszy w tabeli alerts.details jest zwiększana w czasie lub gdy zostaną wprowadzone nowe urządzenia lub pliki reguł inwentaryzacji, to w zależności od tempa wzrostu może się okazać, że problem zostanie rozwiązany. Tabela alerts.details korzysta z większej ilości pamięci niż tabela alerts.journal, ale mniej pamięci niż tabela alerts.status.

Wskazówka: Użyj funkcji nvp_add , aby przenieść dane z pozycji tabeli alerts.details do pola ExtendedAttr tabeli alerts.status. Użycie funkcji nvp_add oznacza, że liczba operacji wstawiania wykonanych przez sondę jest zmniejszana.

Więcej informacji na temat liczby zdarzeń w tabeli alerts.details zawiera sekcja Inne przydatne informacje.

Liczba wierszy w tabeli alerts.journal

Liczba wierszy w tabeli alerts.journal ulega wahaniom w zależności od automatyzacji przetwarzając zdarzenia, lub użytkownika przetwarzający zdarzenia. Jednakże liczba wierszy powinna być stabilna w ciągu kilku tygodni. Jeśli liczba wierszy w tabeli alerts.journal rośnie w ciągu tygodni, to w zależności od tempa wzrostu problem może być rozwijający się. Upewnij się, że wpis jest dokonany w tabeli alerts.journal tylko wtedy, gdy wyzwalacz ma wpływ na zawartość wiersza, niezależnie od częstotliwości wyzwalacza. Użyj indykatorów, aby upewnić się, że zdarzenie nie jest niepotrzebnie ponownie przetwarzane przez ten sam wyzwalacz. Więcej informacji na temat licznika zdarzeń w tabeli alerts.journal zawiera sekcja Inne przydatne informacje.

Liczba wstawień w tabeli alerts.status w ciągu poprzednich n sekund

W przypadku tego kluczowego wskaźnika wydajności wstawienia odnoszą się do nowych wierszy i deduplikacji. Aby monitorować liczbę operacji wstawiania w tabeli alerts.status, należy włączyć grupę wyzwalaczy stats_triggers i automatykę statistics_gather. Dane zebrane przez tę grupę wyzwalaczy i automatyzację są okresowo zapisywane do tabeli master.stats, w kolumnie StatusInserts. Pomiar wydajności można uzyskać, porównując wartość kolumny StatusInserts z wartością z poprzedniego raportu. Ten kluczowy wskaźnik wydajności umożliwia identyfikowanie dużych wzrostów wprowadzanych do systemu spowodowanych przez monitorowanie nowych urządzeń lub aplikacji i może być używane do zwiększania skalowalności systemu i planowania mocy obliczeniowej. Liczba wierszy w tabeli alerts.status ulega wahaniom w zależności od sieci i aplikacji, które są monitorowane, dzień tygodnia, godzina i tak dalej. Jednakże liczba wierszy powinna być stabilna w ciągu kilku tygodni. Jeśli liczba wierszy w tabeli alerts.status wzrasta w ciągu tygodni lub zostaną wprowadzone nowe urządzenia lub pliki reguł inwentaryzacji, to w zależności od tempa wzrostu problem może się rozwijać, na przykład, błąd lub problem z plikiem reguł sondy.

Wykorzystanie pamięci procesu nco_objserv

Aby monitorować wykorzystanie pamięci przez proces nco_objserv, należy skonfigurować i użyć agenta IBM Tivoli Monitoring Agent dla Tivoli Netcool/OMNIbus. Monitoruj wykorzystanie pamięci przez proces nco_objserv, aby upewnić się, że użycie nie zbliża się do żadnych limitów pamięci, a także aby pomóc w zidentyfikowaniu ewentualnych wzrostów użycia pamięci i określić przyczynę zwiększenia. Wykorzystanie pamięci przez proces zwiększa się proporcjonalnie do zwiększenia liczby wierszy w tabeli alerts.status, tabeli alerts.details oraz tabeli alerts.journal (lub zdefiniowanych dodatkowych tabel) w celu zwiększenia liczby połączeń oraz zwiększenia wykorzystania przez klienty. Użycie pamięci powinno pozostać stabilne w czasie, a każdy wzrost powinien odpowiadać wzrostowi liczby wierszy tabeli lub dodatkowych klientów.

Liczba połączeń z serwerem obiektów

Aby monitorować liczbę połączeń z serwerem obiektów, włącz grupę wyzwalaczową stats_triggers i automatykę statistics_gather. Dane zebrane przez tę grupę wyzwalaczy i automatyzację są okresowo zapisywane do tabeli master.stats w kolumnie NumClients. Alternatywnie można uruchomić ręczny licznik liczby wierszy w tabeli catalog.connections. Do serwera obiektów może być maksymalnie 1024 połączenia. Gdy zostanie osiągnięta maksymalna liczba połączeń, odmówiono nawiązania nowych połączeń. Odmowa połączenia może skutkować tymczasową utratą dostępu do danych lub utratą danych wejściowych dla sond lub bram. Maksymalna liczba połączeń wynosi 1024. Maksymalna dozwolona liczba połączeń jest określana przez właściwość Connections serwera obiektów, z wartością domyślną wynoszącą 256. Liczba połączeń różni się w zależności od środowiska i jego użycia. Jednakże liczba ta powinna pozostać stabilna w porównaniu z upływem kilku tygodni. Jeśli liczba połączeń wzrasta w ciągu tygodni, to w zależności od tempa wzrostu, może się okazać, że problem będzie się rozwijał.

Użycie pamięci memstore

Aby monitorować pamięć memstore, sprawdź zawartość tabeli catalog.memstores. Dla każdego wiersza porównaj wartość kolumny UsedBytes z wartościami kolumny SoftLimit i kolumny HardLimit. Składnice są kontenerami, które są obsługiwane przez serwer obiektów, zawierają dane serwera obiektów i tabele w pamięci. Elementy pamięci mają skończoną wielkość, a po zapełnieniu nie pozwalają na wstawianie żadnych dalszych danych. W związku z tym należy upewnić się, że pliki pamięci nie są pełne. Korzystanie z pamięci różni się w zależności od środowiska i jego użycia. Jednakże, stosowanie powinno pozostać stabilne w porównaniu z upływem kilku tygodni. Jeśli wykorzystanie pamięci jest coraz większe w ciągu tygodni, to w zależności od tempa wzrostu, może zostać rozwiązany problem.