wait_info

wait_info to zdarzenie Extended Events rejestrujące szczegóły oczekiwań wątków wykonawczych.

wait_info jako zdarzenie diagnostyczne w środowisku SQL Server

wait_info należy do zdarzeń Extended Events, czyli mechanizmu pozwalającego obserwować wybrane sytuacje występujące podczas pracy silnika bazy danych. Jego zadaniem jest rejestrowanie informacji o oczekiwaniach wątków wykonawczych. Oczekiwanie pojawia się wtedy, gdy wątek nie może kontynuować działania, ponieważ musi zaczekać na zasób, sygnał, blokadę, zakończenie operacji wejścia i wyjścia albo inną zależność sterującą kolejnością pracy.

W praktyce wait_info nie jest komunikatem o pojedynczym błędzie. Stanowi ślad diagnostyczny, który pomaga ustalić, dlaczego wykonanie zapytania, procedury lub zadania systemowego zostało na pewien czas wstrzymane. Sam fakt wystąpienia oczekiwania jest normalny, ponieważ procesor, pamięć, dyski, blokady i inne elementy środowiska są współdzielone. Znaczenie ma dopiero skala zjawiska, jego powtarzalność, czas trwania oraz relacja z obciążeniem obserwowanym przez użytkowników.

Rejestrowanie wait_info może dostarczać danych o rodzaju oczekiwania, czasie jego trwania, momencie rozpoczęcia lub zakończenia oraz kontekście wykonawczym. Zakres dostępnych pól zależy od wersji oprogramowania, konfiguracji sesji i sposobu zdefiniowania sesji Extended Events. Z tego powodu każde pole powinno być odczytywane w odniesieniu do konkretnego środowiska, a nie traktowane jako uniwersalna miara problemu.

wait_info a inne sposoby obserwacji oczekiwań

W porównaniu z ogólnymi licznikami wydajności wait_info pozwala zobaczyć pojedyncze wystąpienia lub precyzyjnie ograniczone serie zdarzeń. Liczniki zbiorcze pokazują zwykle wartości narastające albo uśrednione, natomiast zdarzenia Extended Events mogą wskazać, kiedy dane oczekiwanie wystąpiło i w jakim kontekście. Dzięki temu można powiązać opóźnienie z konkretną aktywnością, poleceniem lub okresem zwiększonego ruchu.

Nie należy jednak utożsamiać wait_info z pełnym profilem wydajności. Zdarzenie opisuje oczekiwanie, lecz nie zawsze wyjaśnia jego pierwotną przyczynę. Oczekiwanie na blokadę może wynikać z długo trwającej transakcji, ale samo zdarzenie nie musi zawierać kompletnej historii operacji, która tę transakcję rozpoczęła. Podobnie oczekiwanie związane z wejściem i wyjściem może wskazywać na presję na podsystem przechowywania danych, lecz nie rozstrzyga samoistnie, czy przyczyną jest zapytanie, plan wykonania, konfiguracja pamięci podręcznej czy ograniczenie sprzętowe.

Warto odróżnić wait_info od zdarzeń opisujących zakończenie zapytania, zmianę planu, błąd lub zakleszczenie. Każda z tych kategorii odpowiada na inne pytanie. wait_info pomaga odpowiedzieć na pytanie, na co czekał wątek i jak długo pozostawał w tym stanie. Zdarzenia dotyczące zapytań mogą natomiast wskazać, co było wykonywane, a zdarzenia blokad mogą pomóc odtworzyć zależność między sesjami. Najpewniejszy obraz uzyskuje się przez zestawienie kilku źródeł informacji, z zachowaniem wspólnego czasu obserwacji.

Istotne jest także rozróżnienie oczekiwania aktywnego od oczekiwania zakończonego. Rejestrowanie rozpoczęcia i zakończenia pozwala ocenić długość przerwy oraz sekwencję zdarzeń. Rejestrowanie wyłącznie jednego momentu może być wystarczające w prostym monitoringu, ale ogranicza możliwość dokładnego oszacowania czasu trwania. Przy projektowaniu sesji należy uwzględnić częstotliwość zdarzeń, ponieważ nadmiernie szeroki zakres filtrów może zwiększyć ilość danych i utrudnić późniejszą analizę.

wait_info przy typowych problemach z działaniem komputera

Podwyższona liczba oczekiwań może towarzyszyć spowolnieniu aplikacji bazodanowej, wydłużeniu raportów, opóźnieniom w obsłudze formularzy lub chwilowym przerwom w realizacji zadań. Nie oznacza to automatycznie uszkodzenia komputera. Przyczyną może być konkurencja o zasoby, niekorzystny plan zapytania, duża liczba równoległych operacji, zalegające blokady, przeciążenie pamięci albo problemy z podsystemem dyskowym.

Jednym z częstych przypadków jest oczekiwanie związane z blokowaniem. Wtedy jedna operacja przetrzymuje zasób potrzebny innej operacji. Analiza wait_info powinna zostać uzupełniona o identyfikację sesji blokującej, tekst wykonywanego polecenia, czas trwania transakcji oraz kolejność rozpoczęcia działań. Samo skrócenie czasu oczekiwania w konfiguracji nie usuwa źródła blokady, jeżeli problemem pozostaje niewłaściwy zakres transakcji lub brak odpowiedniego indeksu.

Inny przypadek dotyczy oczekiwań związanych z pamięcią i odczytem danych. Jeżeli potrzebne strony danych nie są dostępne wystarczająco szybko, zapytania mogą pozostawać w stanie oczekiwania na operację wejścia i wyjścia. Wtedy analizuje się między innymi rozmiar danych, częstotliwość odczytów, rozkład obciążenia, aktualność statystyk oraz strukturę zapytań. Niekiedy przyczyną jest jedno nieefektywne zapytanie, a nie ogólny brak wydajności całego komputera.

Warto pamiętać o oczekiwaniach krótkich i masowych. Pojedyncze, krótkie zdarzenia mogą być naturalnym elementem pracy systemu. Duża liczba podobnych zdarzeń w czasie odczuwalnego spowolnienia ma większą wartość diagnostyczną. Ocena powinna uwzględniać okres bazowy, czyli zachowanie środowiska wtedy, gdy użytkownicy nie zgłaszają problemów. Dopiero porównanie obu okresów pozwala wskazać zmianę, a nie tylko obecność oczekiwań.

wait_info w praktycznej analizie i konfiguracji

Przed uruchomieniem obserwacji warto określić pytanie diagnostyczne. Inaczej konfiguruje się sesję szukającą blokowania, inaczej analizę opóźnień dyskowych, a jeszcze inaczej badanie krótkich skoków obciążenia. Pomocne jest ograniczenie zakresu do właściwych baz, aplikacji, sesji lub typów oczekiwań, jeżeli takie filtry są dostępne. Im lepiej określony cel, tym łatwiej odróżnić dane użyteczne od szumu.

Wyniki powinny być zapisywane w sposób pozwalający zachować chronologię. Przydatne jest zestawienie czasu zdarzenia z identyfikatorem sesji, nazwą oczekiwania, czasem trwania, informacją o stanie sygnału oraz kontekstem wykonania. Następnie można grupować dane według typu oczekiwania i porównywać je z czasem trwania zapytań, aktywnością procesora, pamięcią oraz operacjami wejścia i wyjścia. Nie powinno się wyciągać wniosków wyłącznie z rankingu nazw oczekiwań.

Ważna jest kontrola wpływu samego monitoringu. Sesja Extended Events powinna rejestrować tylko te informacje, które są potrzebne do odpowiedzi na postawione pytanie. Zbyt szerokie przechwytywanie może zwiększyć rozmiar plików, utrudnić wyszukiwanie i obciążyć system w okresie intensywnej pracy. Po zakończeniu badania należy opisać zakres sesji, czas obserwacji, zastosowane filtry oraz sposób interpretacji, aby wynik dało się później odtworzyć.

Przydatne jest również zestawienie wait_info z planem wykonania i historią zmian. Jeżeli oczekiwania wzrosły po wdrożeniu nowej wersji aplikacji, zmianie indeksów albo zwiększeniu wolumenu danych, korelacja czasowa może wskazać kierunek dalszej analizy. Nie stanowi ona jednak dowodu przyczynowego. Potrzebne jest sprawdzenie powtarzalności, odtworzenie warunków oraz porównanie z okresem, w którym problem nie występował.

wait_info i moment zgłoszenia do serwisu

Do konsultacji warto przygotować godzinę wystąpienia problemu, opis objawów, nazwę używanej aplikacji oraz informację, czy spowolnienie dotyczy wszystkich operacji, czy tylko wybranych funkcji. Pomocne są również fragmenty logów i wyniki sesji Extended Events obejmujące wait_info, o ile ich przekazanie nie narusza zasad ochrony danych. Nie zaleca się usuwania plików diagnostycznych przed ich skopiowaniem, ponieważ mogą zawierać informacje potrzebne do porównania zdarzeń.

Jeżeli wraz z oczekiwaniami pojawiają się restarty, błędy odczytu, nietypowe dźwięki dysku, utrata połączenia, przegrzewanie lub niestabilne działanie systemu, potrzebna jest szersza ocena komputera. Analiza samej bazy danych może nie wykazać problemu, gdy źródło znajduje się w pamięci, nośniku danych, zasilaniu, sterownikach albo chłodzeniu. W takich sytuacjach przyjmuje się kolejność obejmującą zabezpieczenie danych, zebranie objawów, sprawdzenie stanu podzespołów i dopiero późniejszą interpretację wyników programowych.

W Warszawie pomocą w takiej diagnostyce zajmuje się Warszawskie Pogotowie Komputerowe 24/7, gdzie można przekazać opis zdarzeń wait_info wraz z informacjami o objawach komputera. Szczególnie istotne jest zgłoszenie sprawy wtedy, gdy opóźnienia powtarzają się w określonych porach, wpływają na pracę kilku użytkowników albo pojawiły się po zmianie oprogramowania i konfiguracji. Rzetelna ocena wymaga połączenia danych z monitoringu z obserwacją rzeczywistego działania urządzenia, ponieważ samo zdarzenie wait_info wskazuje miejsce oczekiwania, lecz nie zawsze wskazuje pełną przyczynę problemu.