Statystyki zapytań w czasie

Statystyki zapytań w czasie pozwalają śledzić zmianę wydajności tego samego zapytania na przestrzeni kolejnych okresów.

Jak czytać statystyki zapytań w kolejnych okresach

Statystyki zapytań w czasie służą do porównywania wykonania tego samego zapytania w różnych przedziałach czasowych. Zamiast oceniać pojedyncze uruchomienie, analizuje się serię pomiarów, na przykład z kolejnych godzin, dni albo tygodni. Dzięki temu można zauważyć, że zapytanie, które rano kończy się szybko, po południu wykonuje się znacznie dłużej. Sama informacja o średnim czasie wykonania nie wystarcza, ponieważ średnia może ukrywać pojedyncze bardzo wolne uruchomienia. Dlatego przydatne są również wartości minimalne, maksymalne, mediany oraz percentyle, takie jak P95 oznaczający czas, poniżej którego mieści się 95 procent pomiarów.

Porównanie powinno dotyczyć tego samego zapytania lub tej samej grupy zapytań, a także uwzględniać identyczne jednostki. Czas wykonania należy odróżnić od czasu oczekiwania na zasoby, czasu odczytu danych i czasu przesyłania wyniku do aplikacji. W zależności od używanego narzędzia statystyka może obejmować liczbę wykonań, liczbę zwróconych wierszy, odczyty logiczne, odczyty fizyczne, użycie procesora oraz czas oczekiwania. Dopiero zestawienie tych wartości pozwala określić, czy problem dotyczy samego planu wykonania, wzrostu ilości danych, przeciążenia systemu czy komunikacji między aplikacją a bazą danych.

Wydajność zapytania a zmiana danych i planu wykonania

Wydłużenie czasu wykonania może wynikać ze zmiany danych, nawet gdy treść zapytania pozostaje bez zmian. Po zwiększeniu tabeli silnik bazy danych może odczytywać większą liczbę stron danych, przetwarzać więcej wierszy albo wybierać inną kolejność operacji. Znaczenie mają również statystyki opisujące rozkład wartości w kolumnach. Jeżeli są nieaktualne, optymalizator może błędnie oszacować liczbę rekordów spełniających warunek i dobrać plan niepasujący do aktualnego stanu tabeli. W historii czasowej warto więc zaznaczyć moment dużego importu, usunięcia danych, zmiany indeksu lub przebudowy struktury tabeli.

Istotnym sygnałem jest zmiana planu wykonania. Plan może przejść na przykład z wyszukiwania indeksowego do skanowania całej tabeli albo zmienić sposób łączenia tabel. Nie każda zmiana oznacza błąd, ponieważ inny plan może być korzystniejszy dla większego zbioru danych. Problem pojawia się wtedy, gdy po zmianie rośnie liczba odczytów, czas procesora lub liczba przetwarzanych wierszy, a wynik zapytania pozostaje taki sam. W analizie należy porównywać plan z okresu poprawnego działania z planem z okresu spowolnienia, a nie wyciągać wniosków wyłącznie na podstawie jednego czasu wykonania.

Oddzielanie regresji od chwilowego przeciążenia

Statystyki w czasie pomagają odróżnić regresję wydajności od krótkotrwałego przeciążenia. Regresja ma zwykle charakter trwały: po określonej zmianie aplikacji, danych, indeksów albo konfiguracji czas wykonania pozostaje wyższy w kolejnych pomiarach. Chwilowe przeciążenie może natomiast wystąpić tylko w czasie kopii zapasowej, skanowania antywirusowego, aktualizacji systemu, intensywnego zapisu na dysku albo równoczesnego uruchomienia wielu procesów. Jeżeli wolne wykonania pojawiają się wyłącznie w określonych godzinach, należy zestawić historię zapytań z obciążeniem procesora, pamięci operacyjnej, dysku i sieci.

Ważna jest także liczba wykonań. Wzrost całkowitego czasu obciążenia nie musi oznaczać, że pojedyncze zapytanie działa wolniej. Aplikacja mogła zacząć wysyłać to samo zapytanie znacznie częściej, na przykład w wyniku zbyt krótkiego interwału odświeżania, braku pamięci podręcznej albo błędu w pętli. Odwrotna sytuacja również jest możliwa: średni czas pozostaje podobny, lecz liczba uruchomień spada, ponieważ część żądań kończy się błędem lub przekroczeniem limitu czasu. Dlatego raport powinien zawierać co najmniej liczbę wykonań, czas całkowity, średnią lub medianę, wartości skrajne oraz informacje o błędach i przerwanych operacjach.

Praktyczne wykorzystanie historii pomiarów na komputerze

Przy lokalnej analizie warto rozpocząć od ustalenia punktu odniesienia. Należy zapisać, kiedy zapytanie działało prawidłowo, jak długo trwało wykonanie, jaki był rozmiar danych oraz jakie procesy działały równolegle. Następnie trzeba porównać kilka pomiarów z okresu problemu, ponieważ pojedynczy wynik może być przypadkowy. Dobrą praktyką jest grupowanie zapytań według identyfikatora, znormalizowanej treści albo wzorca parametrów. Zapytania różniące się wyłącznie wartościami parametrów nie zawsze mają taki sam koszt, ponieważ rozkład danych może powodować wybór odmiennych planów wykonania.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a w przypadku problemów z lokalnym oprogramowaniem można rozpocząć diagnostykę od zebrania historii czasów wykonania, obciążenia systemu i komunikatów aplikacji. Taki materiał ułatwia rozróżnienie problemu programu od problemu sprzętowego, na przykład zbyt wolnego dysku, niewystarczającej ilości pamięci operacyjnej albo przegrzewania procesora. Sama statystyka zapytań nie wskazuje automatycznie uszkodzonego podzespołu. Jest dowodem na zmianę zachowania konkretnej operacji, który należy połączyć z logami aplikacji, stanem systemu plików, temperaturami, dostępnym miejscem na dysku i powtarzalnością objawu.