Diagnostyka sys.dm_os_wait_stats

Diagnostyka sys.dm_os_wait_stats to analiza tego widoku dynamicznego zarządzania, prezentującego statystyki oczekiwania procesów na zasoby.

Diagnostyka sys.dm_os_wait_stats: czym jest i do czego służy

Diagnostyka sys.dm_os_wait_stats to metoda obserwowania, na jakie zdarzenia oczekują zadania wykonywane przez aparat bazodanowy. Widok dynamicznego zarządzania gromadzi zagregowane informacje o oczekiwaniach, dzięki czemu można sprawdzić, czy opóźnienia wynikają z dostępu do danych, operacji wejścia i wyjścia, blokad, synchronizacji wątków, przydzielania pamięci albo innych elementów pracy instancji SQL Server. Nie jest to jednak prosty ranking „najwolniejszych zapytań”. Statystyki pokazują czas oczekiwania zebrany dla określonych typów waitów, a nie pełny opis pojedynczej operacji ani bezpośrednią przyczynę każdego problemu.

Każdy wpis zwykle obejmuje nazwę typu oczekiwania, liczbę oczekujących zadań, łączny czas oczekiwania, czas sygnału oraz dane pomocnicze zależne od wersji silnika. Czas oczekiwania można rozumieć jako okres, w którym zadanie nie mogło kontynuować pracy, ponieważ czekało na zasób lub sygnał od innego elementu. Czas sygnału pomaga odróżnić oczekiwanie na sam zasób od opóźnienia wynikającego z harmonogramowania. Właściwa interpretacja wymaga więc sprawdzenia nie tylko nazwy waita, lecz także proporcji między czasem całkowitym, czasem sygnału, liczbą wystąpień oraz obciążeniem obserwowanym w tym samym okresie.

sys.dm_os_wait_stats w kontekście technicznym i porównaniach

Największą wartość uzyskuje się wtedy, gdy statystyki oczekiwania są analizowane jako element większego obrazu. Sam wysoki czas dla jednego typu wait nie przesądza jeszcze o awarii. W systemie wykonującym dużo operacji dyskowych oczekiwania związane z odczytem mogą być naturalnym skutkiem profilu pracy. W aplikacji realizującej wiele krótkich transakcji dominować mogą oczekiwania związane z blokadami. Przy intensywnym współdzieleniu zasobów część czasu może być poświęcana na synchronizację, a nie na odczytywanie stron danych.

Przydatne jest porównanie sys.dm_os_wait_stats z innymi źródłami obserwacji. Statystyki zapytań pokazują, które instrukcje zużywają czas procesora, wykonują operacje wejścia i wyjścia albo oczekują na zasoby. Widoki dotyczące aktywnych żądań pozwalają zobaczyć stan bieżący, podczas gdy sys.dm_os_wait_stats opisuje sumy narastające od momentu uruchomienia instancji lub wyzerowania liczników. Informacje o plikach baz danych pomagają ocenić opóźnienia podsystemu dyskowego, a dane o blokadach wskazują relacje między sesją blokującą i sesją oczekującą. Zestawienie tych perspektyw ogranicza ryzyko wyciągnięcia wniosku na podstawie pojedynczej tabeli diagnostycznej.

Ważne jest również odróżnienie oczekiwań istotnych diagnostycznie od oczekiwań technicznych lub pomocniczych. Niektóre typy mogą pojawiać się często w prawidłowo działającym środowisku. Liczba wystąpień nie powinna być oceniana bez czasu trwania, udziału w całkowitym czasie oczekiwania, momentu wystąpienia oraz charakteru obciążenia. Lepsze pytanie brzmi: jakie oczekiwania wzrosły po zmianie i czy ten wzrost odpowiada odczuwalnemu spowolnieniu, niż: który wpis ma największą wartość od początku działania instancji.

Typowe problemy ujawniane przez sys.dm_os_wait_stats

Jedną z częstych grup są oczekiwania związane z operacjami wejścia i wyjścia. Mogą wskazywać na wolne odczyty, przeciążenie urządzenia, niekorzystny układ plików, dużą liczbę skanów albo zapytania wymagające dostarczenia wielu stron danych. Nie należy automatycznie uznawać, że winny jest sam dysk. Podobny obraz może powstać przez brak odpowiedniego indeksu, nieaktualne statystyki, nieefektywny predykat lub plan wykonania, który pobiera więcej danych, niż wymaga tego wynik.

Inną grupę stanowią oczekiwania blokad. W takim przypadku jedno zadanie może zatrzymywać inne, ponieważ transakcja nie zwolniła jeszcze zasobu. Analiza powinna objąć długość transakcji, kolejność modyfikowania obiektów, zakres blokowanych danych, poziom izolacji oraz moment zatwierdzania zmian. Samo zwiększenie zasobów sprzętowych nie usuwa blokady logicznej. Potrzebna może być korekta kodu aplikacji, skrócenie transakcji, zmiana sposobu pobierania danych albo uporządkowanie dostępu do obiektów.

Spotyka się również oczekiwania związane z pamięcią, kompilacją, synchronizacją i harmonogramowaniem. Wysokie wartości z tych grup mogą wskazywać na presję pamięci, częste tworzenie planów, konkurencję między zadaniami albo nierównomierne rozłożenie pracy. Wnioski powinny być potwierdzone analizą zapytań, obciążenia procesora, przydziałów pamięci, planów wykonania i historii zmian. W szczególności nie zaleca się usuwania oczekiwań z listy tylko dlatego, że ich nazwa nie jest intuicyjna. Odfiltrowanie wpisu może ukryć sygnał diagnostyczny bez usunięcia przyczyny.

Problemem bywa także interpretowanie danych narastających przez długi czas. Jeżeli instancja działała przez wiele dni, suma może odzwierciedlać dawne zdarzenia, które nie występują już obecnie. Dwa odczyty wykonane w odstępie czasu pozwalają obliczyć przyrosty. To właśnie zmiana między próbkami często lepiej opisuje aktualne obciążenie niż wartość skumulowana od uruchomienia. Resetowanie liczników może być użyteczne podczas kontrolowanego testu, ale powinno być poprzedzone zapisaniem stanu wyjściowego i odnotowaniem czasu operacji.

Praktyczne wskazówki dla analizy sys.dm_os_wait_stats

Najpierw warto ustalić ramy obserwacji: okres, rodzaj ruchu, oczekiwany poziom obciążenia oraz zmianę, po której pojawiło się spowolnienie. Następnie można wykonać kilka próbek widoku w równych odstępach i porównać przyrosty. Taki sposób pokazuje, czy dominujące oczekiwania są stałe, czy pojawiają się tylko w określonych porach. Przydatne jest prowadzenie krótkiego dziennika zawierającego czas pomiaru, najważniejsze waity, liczbę aktywnych żądań i obserwowane objawy.

Podczas interpretacji dobrze jest grupować typy oczekiwań według przyczyny, a nie analizować każdą nazwę w oderwaniu od reszty. Można osobno rozpatrywać dostęp do danych, blokady, procesor, pamięć, synchronizację i komunikację. Następnie należy przejść od grupy do konkretu: zapytania, planu, indeksu, transakcji, pliku lub ustawienia, które może tłumaczyć obserwowany wzorzec. Zmiana powinna być wprowadzana w sposób kontrolowany, a po niej powinien nastąpić kolejny pomiar. Bez porównania przed zmianą i po zmianie trudno ocenić, czy działanie przyniosło poprawę.

Warto zachować ostrożność przy zerowaniu statystyk w środowisku używanym przez wiele osób. Taka czynność wpływa na późniejszą interpretację raportów i może utrudnić porównanie z wcześniejszymi obserwacjami. Bezpieczniejszą praktyką jest zapisanie wyniku do tabeli lub pliku i wyliczanie różnic między odczytami. Przy analizie należy też uwzględnić restart instancji, przełączenie bazy, zmianę planu, wdrożenie nowej wersji aplikacji oraz nietypowy wzrost ruchu.

• Porównuje się kilka próbek, zamiast opierać wniosek na jednym odczycie.
• Oddziela się czas oczekiwania od czasu sygnału i sprawdza ich wzajemną proporcję.
• Łączy się waity z zapytaniami, planami, blokadami, statystykami plików i metrykami systemowymi.
• Dokumentuje się moment resetu liczników, restartu oraz ważnych zmian konfiguracyjnych.
• Weryfikuje się efekt każdej korekty na podstawie tego samego rodzaju obciążenia.

Kiedy zgłosić się z problemem sys.dm_os_wait_stats do serwisu

Do konsultacji warto przygotować opis objawów, czas ich występowania, przykładowe odczyty sys.dm_os_wait_stats oraz informację o zmianach wykonanych przed pojawieniem się problemu. Szczególnie pomocne są zestawienia pokazujące przyrosty oczekiwań, listę najbardziej obciążających zapytań, informacje o blokadach i porównanie okresu poprawnego działania z okresem spowolnienia. Taki materiał ułatwia oddzielenie problemu samej bazy od kłopotów aplikacji, systemu operacyjnego, pamięci masowej lub sieci.

Jeżeli analiza wskazuje na szerszy problem ze stacją roboczą, laptopem albo komputerem PC, można skorzystać z pomocy firmy Warszawskie Pogotowie Komputerowe 24/7. W ramach zgłoszenia można przedstawić wyniki pomiarów, komunikaty błędów i opis zachowania systemu, aby ułatwić dobór dalszej diagnostyki. Przydatne będzie także wskazanie, czy spowolnienie dotyczy pojedynczej aplikacji, wszystkich operacji, uruchamiania systemu, odczytu danych czy pracy urządzeń peryferyjnych.

Nie każdy wysoki wynik w widoku oznacza konieczność natychmiastowej ingerencji. Zgłoszenie staje się pilniejsze, gdy oczekiwania rosną równocześnie z wydłużeniem czasu odpowiedzi, blokowaniem użytkowników, przerwami w działaniu aplikacji, błędami odczytu lub niestabilnością sprzętu. W takiej sytuacji diagnostyka powinna objąć cały łańcuch zależności i zakończyć się wskazaniem przyczyny potwierdzonej pomiarem, a nie tylko zmianą pojedynczego parametru.