sys.dm_os_wait_stats to kluczowe DMV do diagnostyki wydajności, pokazujące, na co czekają zapytania.
Co pokazuje sys.dm_os_wait_stats
sys.dm_os_wait_stats jest dynamicznym widokiem zarządzania (DMV) w aparacie Microsoft SQL Server. Zawiera zagregowane informacje o oczekiwaniach zarejestrowanych przez wątki silnika bazy danych. Wiersz odpowiada typowi oczekiwania, na przykład oczekiwaniu na operację wejścia-wyjścia, blokadę, synchronizację wewnętrzną albo dostępność zasobu. Dane pomagają ustalić, czy czas wykonywania zapytań jest ograniczany przez procesor, dyski, blokowanie transakcji, pamięć lub mechanizmy synchronizacji.
Widok nie pokazuje bezpośrednio pojedynczego zapytania, które wygenerowało oczekiwanie. Jest podsumowaniem dla instancji SQL Server, dlatego wynik trzeba zestawić z innymi źródłami, takimi jak plan wykonania, sys.dm_exec_requests, sys.dm_exec_query_stats, informacje o blokadach oraz liczniki wydajności. Sam fakt wystąpienia konkretnego typu oczekiwania nie oznacza jeszcze błędu. SQL Server podczas normalnej pracy niemal zawsze rejestruje oczekiwania, a znaczenie ma ich udział w całkowitym czasie oczekiwania, zmiana w czasie i zgodność z obserwowanym problemem.
Kolumny i interpretacja pomiarów
Najczęściej analizowane kolumny to wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms oraz signal_wait_time_ms. waiting_tasks_count określa liczbę zakończonych oczekiwań danego typu. wait_time_ms jest skumulowanym czasem oczekiwania w milisekundach, natomiast max_wait_time_ms pokazuje najdłuższe pojedyncze oczekiwanie zarejestrowane dla danego typu. signal_wait_time_ms oznacza czas, przez który zadanie po uzyskaniu wymaganego zasobu czekało jeszcze na przydzielenie czasu procesora.
Warto rozdzielić czas oczekiwania na część zasobową i sygnałową. Można to zrobić, odejmując signal_wait_time_ms od wait_time_ms. Duży udział czasu sygnałowego może wskazywać na presję procesora, zbyt dużą liczbę wykonywanych zadań lub nieefektywne plany. Z kolei dominacja czasu niesygnałowego wymaga sprawdzenia zasobu wskazanego przez typ oczekiwania. Przykładowo PAGEIOLATCH_* wiąże się z oczekiwaniem na zakończenie odczytu strony danych z pamięci masowej, LCK_M_* z oczekiwaniem na blokadę, a RESOURCE_SEMAPHORE z oczekiwaniem na przyznanie pamięci roboczej dla zapytania.
Wyników nie należy oceniać wyłącznie według największej wartości wait_time_ms. Czas może być wysoki dlatego, że instancja działała długo, a część oczekiwań jest naturalna dla danego obciążenia. Przydatniejsza jest analiza udziału poszczególnych typów w sumie oraz porównanie dwóch pomiarów wykonanych w odstępie czasu. Trzeba również uwzględnić liczbę zadań, średni czas oczekiwania i to, czy oczekiwanie występuje podczas rzeczywistego spowolnienia aplikacji.
Bezpieczne odczytywanie i zerowanie statystyk
Podstawowy odczyt można wykonać zapytaniem SELECT wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms, signal_wait_time_ms FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;. Takie zapytanie sortuje typy według skumulowanego czasu oczekiwania. W praktycznej analizie często odrzuca się oczekiwania bez istotnego wpływu na wydajność oraz typy uznawane za wewnętrzne lub związane z procesami tła. Lista oczekiwań, które należy wykluczyć, zależy od wersji SQL Server i celu pomiaru, więc nie powinno się bezrefleksyjnie stosować jednej listy do każdej instancji.
Statystyki są gromadzone od uruchomienia instancji albo od ostatniego wyzerowania odpowiednich danych. Można je wyzerować poleceniem DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);. Reset usuwa dotychczasowy punkt odniesienia, dlatego powinien być wykonany świadomie, najlepiej po zapisaniu bieżącego wyniku i odnotowaniu czasu operacji. Po wyzerowaniu trzeba odczekać odpowiednio długo, aby próbka obejmowała reprezentatywne obciążenie. Krótki pomiar wykonany tuż po restarcie lub resecie może prowadzić do błędnych wniosków.
Dostęp do DMV wymaga odpowiednich uprawnień serwerowych. W zależności od wersji SQL Server i kontekstu wykonania odczyt może wymagać uprawnienia VIEW SERVER STATE, a w nowszych wersjach część informacji może podlegać bardziej szczegółowym wymaganiom uprawnień. Diagnostyka powinna być prowadzona na kopii wyników, z oznaczeniem czasu rozpoczęcia i zakończenia pomiaru. Dzięki temu można porównywać różne okresy bez mieszania danych historycznych z bieżącym incydentem.
Znaczenie w diagnostyce instancji SQL Server
sys.dm_os_wait_stats jest punktem wyjścia do diagnozy, a nie automatycznym mechanizmem wskazującym przyczynę awarii. Jeżeli dominują oczekiwania blokad, należy sprawdzić sesje blokujące, długość transakcji i zapytania utrzymujące blokady. Przy wysokich oczekiwaniach związanych z wejściem-wyjściem trzeba porównać je z opóźnieniami plików baz danych, obciążeniem podsystemu dyskowego, rozmiarem puli buforów i wzorcami odczytów. Przy dużym czasie sygnałowym należy skorelować wynik z obciążeniem procesorów, równoległością zapytań i planami wykonania.
Ważne jest także rozróżnienie problemu lokalnego od problemu całej instancji. DMV agreguje dane na poziomie SQL Server, podczas gdy pojedyncze zapytanie może mieć inne oczekiwania niż te, które dominują w skali całego systemu. Dlatego pomiar z DMV powinien być zestawiany z czasem odpowiedzi aplikacji, historią obciążenia, aktywnymi żądaniami oraz zmianami schematu, indeksów i planów. W przypadku powtarzających się spowolnień warto wykonywać cykliczne zrzuty statystyk i analizować przyrosty między pomiarami. Taki sposób pozwala odróżnić stałą charakterystykę obciążenia od nowego problemu wydajnościowego.
Podczas diagnostyki technicznej instancji SQL Server należy zachować ostrożność przy interpretacji nazw oczekiwań, ponieważ ich obecność może wynikać z prawidłowego mechanizmu współbieżności, a nie z usterki. Trafna ocena wymaga połączenia danych z DMV z konfiguracją instancji, wersją silnika, charakterem zapytań i stanem infrastruktury. Najbardziej użyteczny jest trend oraz korelacja z konkretnym zdarzeniem: wzrostem czasu odpowiedzi, zmianą planu, przeciążeniem pamięci masowej albo pojawieniem się blokad.
