HomeKorzystając z okazji wydanego niedawno UR 10 do SCOM 2012 SP1 i możliwości aktualizacji środowiska SCOM postanowiłam przy okazji rozejrzeć się za możliwościami tuningu wydajności konsoli SCOM, tak aby widoki, dashboardy i pozostałe formy prezentacji danych monitoringowych wyświetlały się na ekranach zainteresowanych w tempie akceptowalnym i przynoszącym potencjalne korzyści z ich przeglądania 😉 .
Poniżej prezentuję zastosowane rozwiązania:
1. Czyszczenie konsolowego cache
Rozwiązanie na dobrą sprawę pozwala na uruchomienie “świeżej” wersji konsoli bez naleciałości i danych powstałych w poprzednich sesjach; pozwala również na pozbycie się błędów typu: ObjectNotFoundExceptions. Metoda przydaje się również, gdy plik cache urasta do rozmiarów zgoła nieakceptowalnych i chcemy zwolnić nieco miejsca na dysku.
Sposób wykonania został zaprezentowany w TechNetowym źródle: https://technet.microsoft.com/en-us/library/hh212884.aspx
Artykuł opisuje ponadto metody czyszczenia cache po stronie serwera zarządzającego (SCOM Management Server) oraz po stronie agenta; w obu przypadkach przyczyny czyszczenia są zgoła nieco inne niż w naszym konkretnym przypadku, niemniej jednak warto się z nimi zapoznać.
2. Stworzenie większej ilości plików TEMPDB korespondującej z ilością corów na procesorze na serwerze/klastrze SQL hostującym bazę danych.
Jest to metoda o którą potykałam się już od dłuższego czasu; tuning wydajności ma związek nie tyle z samym SCOM ile źródłem danych, z którego on korzysta; czyli SQL Server.
Polega na stworzeniu dodatkowych plików tempdb w celu rozdzielenia transakcji I/O pomiędzy poszczególne pliki oraz zapobiega blokowaniu w momencie kiedy wiele procesorów wykonuje zadania SQL jednocześnie.
Lekką zagadką dla mnie jest, ile tych plików tempdb powinno być; moje źródło mówi, że powyżej 8 corów należy utworzyć 1 plik tempdb na 2 cory procesora. Czyli jeśli mamy 16-corowy procesor, plików tempdb powinno być 12. Jeśli mamy 24-corowy procesor, plików tempdb powinno być 16, itd. Całość jest opisana w poniższym artykule: https://epmlivesupport.desk.com/customer/portal/articles/1357944-create-multiple-tempdb-files-per-cpu; mało tego został do niego dołączony skrypt tworzący pliki tempdb co by nie musieć robić tego samemu … Jeśli post trafi w ręce któregoś z guru SQL’owych będę wdzięczna za wypowiedzenie się, na ile działania arytmetyczne oraz wyznaczenie ilości plików tempdb jest poprawne …
Różnica w poprawie czasu dostępu do danych SCOM z konsoli po zastosowania rozwiązania z powyższego artykułu nie czyni z konsoli demona szybkości, ale komfort pracy zauważalnie się polepszył.
3. Czas na …MDoP! (Max Degree of Parallelism)
MDoP jest jednym z zaawansowanych właściwości serwera SQL. Domyślnie, serwer sam próbuje wykryć jaki poziom MDoP powinien zostać użyty. SQL działający na maszynie z więcej niż jednym procesorem, będzie samodzielnie próbował znaleźć najlepszy poziom zbieżności. Sam paralelizm jest w tym przypadku liczbą procesorów używanych do uruchomienia pojedynczej instrukcji dla każdego zapytania, które ma paralelny plan wykonania. By nie dublować informacji, podaję linka do źródła: http://thoughtsonopsmgr.blogspot.com/2014/12/scom-2012x-console-on-steroids-try-mdop.html.
Po zmianie poziomu paralelności konsola SCOM przyspieszyła znacząco.
Podsumowanie:
Zastosowanie kombinacji trzech powyższych metod pozwoliło na przyspieszenie dostępu do danych o prawie 50%. Największe przyspieszenie szybkości zostało zaobserwowane po zmianie domyślnej wartości MDoP na wartość mającą zastosowanie w moim środowisku SCOM. Challenge accepted 🙂
