Diagnostyka wydajności z XE

Diagnostyka wydajności z XE to proces analizy przyczyn spowolnień z wykorzystaniem mechanizmu Extended Events.

Zakres danych zbieranych przez Extended Events

Diagnostyka wydajności z XE oznacza analizę działania silnika Microsoft SQL Server przy użyciu mechanizmu Extended Events. Jest to wbudowana infrastruktura zdarzeń, która rejestruje wybrane punkty wykonania operacji w silniku bazy danych. Zdarzeniem może być między innymi zakończenie instrukcji T-SQL, wystąpienie błędu, oczekiwanie na zasób, zakleszczenie, zmiana stanu sesji albo przekroczenie ustalonego czasu wykonania. Samo zdarzenie nie jest jeszcze diagnozą. Stanowi obserwację, którą trzeba powiązać z konkretną instrukcją, sesją, bazą danych i warunkami pracy systemu.

Sesja Extended Events składa się z wybranych zdarzeń oraz elementów pomocniczych. Do zdarzeń można dołączyć akcje, czyli dodatkowe informacje pobierane w chwili wystąpienia zdarzenia. W diagnostyce wydajności przydatne bywają tekst instrukcji SQL, nazwa bazy danych, identyfikator sesji, nazwa hosta klienta, nazwa użytkownika, identyfikator zapytania oraz uchwyt planu wykonania. Zakres dostępnych pól i akcji zależy od konkretnego zdarzenia. Nie każda akcja może być przypisana do każdego zdarzenia, dlatego konfigurację trzeba sprawdzić w katalogu Extended Events właściwym dla SQL Server.

Sesja, filtr i miejsce zapisu zdarzeń

Wyniki obserwacji są przekazywane do celu, na przykład event_file albo ring_buffer. Cel event_file zapisuje dane do plików XEL, które można później otworzyć i analizować w SQL Server Management Studio lub odczytać funkcją sys.fn_xe_file_target_read_file. ring_buffer przechowuje dane w pamięci i jest przydatny przy krótkiej obserwacji, ale jego zawartość ma charakter nietrwały. Po restarcie instancji lub usunięciu starszych wpisów materiał diagnostyczny może nie być dostępny.

Filtr predykatu ogranicza liczbę rejestrowanych zdarzeń. Można na przykład uwzględnić tylko instrukcje trwające dłużej od określonej wartości, zdarzenia dotyczące wskazanej bazy danych albo operacje wykonywane przez konkretną sesję. Filtrowanie jest ważne, ponieważ rejestrowanie wszystkich instrukcji może wytworzyć dużą ilość danych i utrudnić odnalezienie istotnych przypadków. Zbyt wąski filtr również jest błędem: może pominąć zapytanie, które w rzeczywistości powoduje spowolnienie, lecz nie spełnia przyjętego warunku w każdej sytuacji.

Łączenie zdarzeń z przyczyną spowolnienia

Analiza nie powinna ograniczać się do sortowania zdarzeń według czasu trwania. Długie wykonanie może wynikać z oczekiwania na blokadę, odczytu danych z wolnego magazynu, dużej liczby operacji wejścia-wyjścia, kompilacji planu, ograniczeń pamięci albo niekorzystnego planu wykonania. Informacja o zakończeniu instrukcji pokazuje skutek, natomiast dodatkowe zdarzenia i dane kontekstowe pomagają ustalić mechanizm, który do tego skutku doprowadził. Szczególnie istotne jest rozróżnienie czasu procesora od czasu upływającego podczas oczekiwania.

W przypadku zakleszczenia przydatne jest zdarzenie zawierające graf konfliktu, ponieważ pozwala zobaczyć uczestniczące sesje, zasoby oraz instrukcje. Przy analizie blokowania należy zestawić identyfikator sesji, czas rozpoczęcia i zakończenia operacji oraz informacje o oczekiwaniu. Przy analizie zapytań warto porównać tekst SQL z planem wykonania i sprawdzić, czy problem występuje stale, czy tylko dla określonych parametrów lub obciążenia. Extended Events może również pomóc wykryć błędy i ostrzeżenia, które pojawiają się równocześnie ze wzrostem czasu odpowiedzi.

Praktyczne ograniczenia i bezpieczny przebieg analizy

Sesję XE należy projektować pod konkretną hipotezę diagnostyczną. Najpierw określa się objaw, następnie wybiera zdarzenia opisujące ten objaw, akcje dostarczające kontekstu oraz cel zapisu. Po uruchomieniu sesji trzeba odnotować przedział obserwacji i warunki wystąpienia problemu. Zebrane pliki XEL analizuje się pod kątem powtarzalnych zależności, a nie pojedynczego nietypowego wpisu. Jeżeli sesja ma działać po restarcie instancji, należy świadomie ustawić jej stan startowy oraz kontrolować rozmiar i rotację plików.

Do wstępnej oceny można wykorzystać również domyślną sesję system_health dostarczaną z SQL Server, ale jej zakres nie zastępuje sesji zaprojektowanej dla konkretnego spowolnienia. Diagnostyka wydajności z XE jest wiarygodna wtedy, gdy dane z sesji zostaną zestawione z planami wykonania, statystykami oczekiwań, informacjami o blokadach i obserwowanym czasem odpowiedzi. W środowisku laptopa lub komputera PC, na którym uruchomiono lokalną instancję SQL Server, analiza może obejmować także wpływ obciążenia procesora, pamięci operacyjnej i dysku na działanie silnika. Naprawa powinna wynikać z ustalonej przyczyny, a nie z samego faktu zarejestrowania zdarzenia.