Regresje wydajności

Regresje wydajności to pogorszenie czasu wykonania zapytania po zmianie planu, danych lub konfiguracji.

Jak powstaje regresja wydajności po zmianie

Regresja wydajności oznacza sytuację, w której ten sam proces po zmianie wykonuje się dłużej, zużywa więcej zasobów albo gorzej reaguje na obciążenie niż wcześniej. W przypadku zapytania do bazy danych pogorszenie może pojawić się po zmianie planu wykonania, powiększeniu tabel, modyfikacji indeksów, aktualizacji statystyk, zmianie konfiguracji silnika lub zwiększeniu liczby jednoczesnych użytkowników. Nie musi to oznaczać błędu składni zapytania. Zapytanie może zwracać poprawne wyniki, a mimo to wykonywać niepotrzebnie dużo odczytów, sortować większy zbiór danych, czekać na blokady albo wykorzystywać procesor i pamięć w sposób mniej efektywny niż wcześniej.

Plan wykonania jest sposobem realizacji zapytania wybranym przez silnik na podstawie jego treści, dostępnych indeksów, rozmiaru danych i oszacowanej liczby pasujących wierszy. Jeżeli te oszacowania są nietrafne, silnik może wybrać niewłaściwą kolejność operacji lub metodę dostępu do danych. Przykładowo, plan oparty na odczycie dużej części tabeli może być akceptowalny dla małego zbioru danych, lecz po jego rozroście stać się źródłem opóźnień. Odwrotna sytuacja także jest możliwa: użycie indeksu nie zawsze jest korzystniejsze, gdy zapytanie zwraca znaczną część tabeli i wymaga później licznych odczytów dodatkowych.

Ślady problemu w pomiarach zapytania

Rozpoznanie regresji wymaga porównania pomiarów sprzed i po zmianie, wykonanych dla porównywalnych parametrów oraz podobnego stanu danych. Należy sprawdzić czas całkowity, czas zużyty przez procesor, liczbę odczytanych stron lub bloków, liczbę zwróconych wierszy, oczekiwania na zasoby oraz liczbę wykonanych operacji wejścia i wyjścia. Sam czas odpowiedzi nie wskazuje jeszcze przyczyny. Opóźnienie może wynikać z obciążenia dysku, braku wolnej pamięci, blokady transakcyjnej, przeciążenia procesora albo oczekiwania na połączenie, mimo że plan zapytania pozostał taki sam.

Ważne jest odróżnienie regresji stałej od problemu zależnego od danych wejściowych. To samo zapytanie może działać szybko dla jednego zakresu dat, identyfikatora lub wartości filtra, a wolno dla innego. Znaczenie mają również parametry przekazywane aplikacji, typy danych i sposób konwersji wartości. Porównanie powinno obejmować rzeczywistą liczbę przetworzonych wierszy oraz liczbę przewidywaną przez plan. Duża różnica między tymi wartościami wskazuje na problem z oszacowaniem selektywności warunku, rozkładem danych albo aktualnością informacji wykorzystywanych przez optymalizator.

Zmiany danych, indeksów i konfiguracji

Rozrost tabeli może zmienić opłacalność poszczególnych operacji. Dodanie indeksu może przyspieszyć wyszukiwanie po jednym warunku, ale jednocześnie zwiększyć koszt zapisu, aktualizacji i utrzymania struktury. Indeks o nieodpowiednim układzie kolumn może nie ograniczyć odczytu tak skutecznie, jak zakładano, zwłaszcza gdy pierwsza kolumna nie odpowiada warunkom używanym przez zapytanie. Na wydajność wpływają także nieaktualne statystyki, fragmentacja lub niekorzystny rozkład wartości. Dlatego przed zmianą należy ustalić, czy problem dotyczy jednego zapytania, całej tabeli, konkretnego indeksu czy większej części aplikacji.

Regresję może wywołać także zmiana konfiguracji środowiska: ograniczenie pamięci, inny limit równoległości, zmiana ustawień pamięci podręcznej, aktualizacja silnika, odmienny sposób kompilacji planu albo uruchomienie dodatkowego zadania w tle. Bezpośrednie wymuszenie konkretnego planu bywa rozwiązaniem tymczasowym i wymaga kontroli, ponieważ plan korzystny dla obecnych danych może stać się niekorzystny po kolejnych zmianach. Bezpieczniejsza diagnostyka polega na odtworzeniu problemu na kopii danych lub w kontrolowanym oknie, zapisaniu pomiarów bazowych, wprowadzeniu jednej zmiany i ponownym porównaniu wyników.

Sprawdzenie komputera i przywrócenie płynnego działania

Na komputerze użytkownika regresja może być widoczna jako wolniejsze uruchamianie programu, dłuższe otwieranie plików, opóźnione reakcje interfejsu lub spadek wydajności po aktualizacji. W takim przypadku trzeba rozdzielić problem aplikacji od problemu lokalnego sprzętu i systemu. Analizuje się obciążenie procesora, pamięci operacyjnej, dysku oraz aktywność procesów działających w tle. Sprawdza się również, czy zmiana konfiguracji programu, sterownika, aktualizacji systemu lub zabezpieczeń nie zwiększyła liczby operacji wykonywanych przy każdym uruchomieniu. Istotne jest porównanie zachowania na tych samych plikach i przy podobnym obciążeniu, ponieważ pojedynczy wolny start nie potwierdza jeszcze trwałej regresji.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego w ramach diagnostyki można zweryfikować zarówno stan sprzętu, jak i konfigurację systemu wpływającą na wydajność. W praktyce przydatne jest udokumentowanie momentu wystąpienia spowolnienia, ostatnich aktualizacji oraz programów, których dotyczy problem. Pozwala to porównać działanie przed i po zmianie, sprawdzić powtarzalność objawu i ustalić, czy konieczna jest korekta ustawień, aktualizacja sterownika, uporządkowanie procesów uruchamianych w tle, konserwacja podzespołów czy dalsza analiza konkretnej aplikacji.