Windows Performance Monitor (PerfMon)

Windows Performance Monitor pozwala śledzić liczniki wydajności SQL Server na poziomie systemu operacyjnego.

Windows Performance Monitor i liczniki SQL Server

Windows Performance Monitor, uruchamiany poleceniem perfmon.exe i często nazywany PerfMon, jest składnikiem systemu Windows służącym do rejestrowania oraz obserwowania liczników wydajności. W przypadku SQL Server pozwala zestawić obciążenie silnika bazy z parametrami systemu operacyjnego, takimi jak czas procesora, wykorzystanie pamięci, aktywność dysków i długość kolejek wejścia-wyjścia. Narzędzie nie zastępuje diagnostyki wykonywanej wewnątrz SQL Server, ale pokazuje, czy problem widoczny w bazie ma związek z zasobami systemowymi.

Liczniki są pogrupowane w obiekty wydajności. Dla instancji SQL Server dostępne są między innymi obiekty SQLServer:Buffer Manager, SQLServer:SQL Statistics, SQLServer:General Statistics, SQLServer:Wait Statistics oraz SQLServer:Databases. Nazwa obiektu może zawierać numer wersji lub nazwę instancji, zależnie od zainstalowanego SQL Server i sposobu jego konfiguracji. Przed rozpoczęciem pomiaru należy sprawdzić, jakie obiekty oraz wystąpienia są faktycznie dostępne na danym komputerze.

Jak odczytywać pomiar procesora, pamięci i dysku

Do podstawowej oceny obciążenia SQL Server można dodać licznik Processor(_Total)\% Processor Time, który pokazuje zajętość procesora widzianą przez system Windows. Wysoka wartość tego licznika nie dowodzi sama w sobie, że SQL Server jest przyczyną problemu. Trzeba porównać ją z licznikami procesu SQL Server, obciążeniem poszczególnych rdzeni, czasem trwania zapytań oraz rodzajem wykonywanej pracy. Krótkie skoki mogą być normalne, natomiast długotrwałe wysokie użycie procesora wymaga korelacji z aktywnością instancji.

W obiekcie SQLServer:Buffer Manager przydatny jest licznik Page life expectancy, który określa, jak długo strony danych pozostają w pamięci podręcznej bufora. Spadek tej wartości może wskazywać na presję pamięci, lecz nie powinien być interpretowany jako samodzielny próg awarii. W SQL Server 2016 i nowszych wartość tego licznika jest raportowana dla węzłów NUMA, dlatego analiza całej instancji powinna uwzględniać poszczególne wystąpienia licznika. W tym samym obiekcie można obserwować między innymi Buffer cache hit ratio, który opisuje udział odczytów obsłużonych z pamięci podręcznej.

Dla magazynu danych istotne są liczniki dysków, na przykład PhysicalDisk(*)\Avg. Disk sec/Read, PhysicalDisk(*)\Avg. Disk sec/Write oraz PhysicalDisk(*)\Disk Transfers/sec. Pokazują one opóźnienie i intensywność operacji wejścia-wyjścia na poziomie systemu Windows. Wynik trzeba odnosić do konkretnego woluminu przechowującego pliki danych, dziennik transakcji lub pliki tempdb. Sam wysoki transfer nie musi oznaczać problemu, a niskie obciążenie dysku nie wyklucza oczekiwania SQL Server na inną część infrastruktury.

Konfiguracja Data Collector Set i zapis próby

Jednorazowy podgląd w narzędziu Performance Monitor jest użyteczny przy obserwacji bieżącego zdarzenia, ale do analizy okresowej lepiej utworzyć zestaw modułów zbierających dane, czyli Data Collector Set. W konsoli należy wskazać liczniki, ustawić interwał próbkowania, określić katalog zapisu oraz zdefiniować czas rozpoczęcia i zakończenia rejestracji. Pliki dziennika mogą być zapisywane w formacie binarnym BLG albo jako tekst CSV. Format BLG zachowuje strukturę typową dla dzienników PerfMon, natomiast CSV ułatwia dalszą analizę tabelaryczną.

Interwał pomiaru powinien odpowiadać badanemu zjawisku. Przy krótkich skokach obciążenia zbyt długi interwał może pominąć istotne zdarzenie, a bardzo krótki interwał zwiększa liczbę próbek i rozmiar pliku. Warto rozpocząć rejestrację przed spodziewanym problemem i zakończyć ją po ustąpieniu objawów. Należy także zapisać godzinę wystąpienia błędu, nazwę instancji SQL Server, badany wolumin oraz wykonywaną operację, ponieważ bez tych informacji trudno powiązać próbki PerfMon z konkretnym zdarzeniem w SQL Server.

Do automatycznego sprawdzenia dostępnych liczników można użyć polecenia typeperf -qx, które wyświetla zainstalowane obiekty i liczniki wydajności. Przykładowe pobranie bieżącej wartości licznika systemowego może wykonać polecenie typeperf "\Processor(_Total)\% Processor Time" -sc 10. Parametr -sc 10 ogranicza pomiar do dziesięciu próbek. Nazwy liczników zależnych od instancji SQL Server należy dopasować do listy zwróconej przez konkretny komputer, ponieważ nie każda instalacja ma identyczny zestaw wystąpień.

Wykorzystanie PerfMon w diagnostyce stacji roboczej i serwera

Raport z Performance Monitor powinien być oceniany razem z czasem odpowiedzi SQL Server, błędami systemu Windows, dziennikiem zdarzeń oraz informacjami o obciążeniu konkretnej instancji. Jeżeli rośnie opóźnienie odczytu plików danych i jednocześnie pojawiają się oczekiwania związane z wejściem-wyjściem, można podejrzewać ograniczenie warstwy dyskowej. Jeżeli obciążenie procesora jest wysokie, ale dyski pozostają mało aktywne, dalsza analiza powinna objąć zapytania i zadania zużywające czas CPU. Jeżeli spada dostępność pamięci, należy sprawdzić presję pamięci oraz rozmiar i charakter obciążenia, zamiast wyciągać wniosek wyłącznie z jednego licznika.

Na komputerze używanym do pracy z SQL Server PerfMon pomaga oddzielić problem aplikacji od problemu zasobów Windows. Rejestrowanie danych w czasie pozwala ustalić, czy spowolnienie występuje stale, tylko podczas kopii zapasowej, przy określonych zapytaniach albo po przekroczeniu dostępnej pamięci. Podczas diagnostyki trzeba unikać nadmiernej liczby liczników i zapisywać tylko te, które odpowiadają postawionej hipotezie. Po zakończeniu pomiaru należy porównać okres problemu z okresem referencyjnym, używając tej samej konfiguracji liczników i tego samego interwału.

Prawidłowo zebrane dane z Windows Performance Monitor mogą pomóc w wykryciu przeciążenia procesora, presji pamięci, opóźnień dysku lub nietypowej aktywności SQL Server. Sam PerfMon nie naprawia przyczyny, lecz dostarcza mierzalnych danych potrzebnych do dalszej decyzji serwisowej. W praktyce diagnostyka powinna obejmować także sprawdzenie konfiguracji systemu, stanu nośnika, sterowników oraz logów SQL Server, aby nie przypisywać całego problemu jednemu wskaźnikowi.