Przykład analizy wydajności

Aby postępować zgodnie z instrukcją wideo, otwórz przykładowy raport tutaj.

Jak interpretować raport wydajności

Używając HQbird, lub jako osobnej usługi, IBSurgeon Performance Analysis z cc.ib-aid.com, możesz wygenerować raport wydajności z logów śledzenia Firebird.

Ten raport to potężne narzędzie diagnostyczne, które dostarcza szczegółowych informacji o wykonywaniu zapytań SQL w bazach danych Firebird. Ten przewodnik wyjaśnia, jak interpretować i używać raportów śledzenia, aby systematycznie identyfikować i rozwiązywać problemy z wydajnością.

1. Struktura raportu wydajności

┌─────────────────────────────────────────┐
│         Performance Report              │
├─────────────────────────────────────────┤
│ 1. Performance Summary Graphs           │
│    ┌────────────────────────┐           │
│    │  Top queries	      │           │
│    │     Top summary	      │           │
│    │     Top frequency      │           │
│    │     Durations          │           │
│    │     Fetches  	      │           │
│    │     Reads	      │           │
│    │     Writes	      │           │
│    │  Time Series Chart     │           │
│    │     Durations          │           │
│    │     Count of queries   │           │
│    │     Fetches            │           │
│    │     Reads/Writes       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Top Queries Analysis                 │
│    ┌────────────────────────┐           │
│    │ Query Rankings         │           │
│    │                        │           │
│    │  By Duration───┐       │           │
│    │                │       │           │
│    │  By Time   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Plan   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Frequency ─┤       │           │
│    │                │       │           │
│    │  By Plan    ───┤       │           │
│    │  Frequency     │       │           │
│    │                │       │           │
│    │  By Fetches ───┤       │           │
│    │                │       │           │
│    │  By Reads   ───┤       │           │
│    │                │       │           │
│    │  By Writes  ───┘       │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Process Summary                      │
│    ┌────────────────────────┐           │
│    │ Per Process Stats      │           │
│    │ - Execution counts     │           │
│    │ - Fetches, etc	      │           │
│    │ - Duration metrics     │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Address Summary                      │
│    ┌────────────────────────┐           │
│    │Per Client Address Stats│           │
│    │ - Connection counts    │           │
│    │ - Durations  	      │           │
│    │ - Fetches,etc          │    	  │
│    │ - Process names        │ 	  │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Query Details Structure:
┌────────────────────┐
│ Query Information  │
├────────────────────┤
│ - SQL Text         │
│ - Transaction info │
│ - Execution Plan   │
│ - Duration Stats   │
│ - Resource Stats   │
│   * Fetches        │
│   * Reads          │
│   * Writes         │
│   * Marks          │
│ - Client Info      │
└────────────────────┘

Raport wydajności zapewnia hierarchiczny widok aktywności bazy danych:

1. Performance Summary Graphs

• Wizualna reprezentacja kluczowych metryk w czasie - możesz łatwo zobaczyć szczyty aktywności/obciążenia. (Dostępny jest również raport analizy minutowej w Advanced Performance Monitoring w HQbird, a jego skrócona wersja jest dostępna w narzędziu Portal - zobacz ten film, aby uzyskać szczegóły).

• Pomaga identyfikować wzorce i anomalie: porównanie wykresów z okresów o dobrej wydajności (np. zeszły tydzień/miesiąc) z problemami wydajnościowymi może pomóc w identyfikacji problemu.

2. Top Queries Analysis

• Wiele perspektyw rankingowych do kompleksowej analizy: najdłuższe zapytania, najczęstsze zapytania, najbardziej czasochłonne zapytania (grupowane według tekstu lub planu) i inne.

• Każdy wymiar ujawnia inne możliwości optymalizacji

• Szczegółowe statystyki dla każdego zapytania, w tym:

• Metryki czasu trwania (min, max, średnia, mediana)

• Zużycie zasobów (fetches, reads, writes)

• Wzorce wykonywania - liczba źródeł dla najczęstszych zapytań.

3. Process Summary

• Grupuje statystyki według procesu wykonującego

• Pomaga identyfikować problematyczne aplikacje

• Pokazuje zużycie zasobów i operacje bazy danych (połączenia, zapytania itp.) oraz metryki (fetches, reads itp.) na proces

4. Address Summary

• Grupuje statystyki według połączenia klienta

• Ujawnia rozkład obciążenia między klientami

• Pomaga identyfikować problemy specyficzne dla połączeń

Każda sekcja wspiera analizę wydajności na różnych poziomach:

• Wzorce ogólnosystemowe (Graphs) - zobacz, kiedy i gdzie występują problemy ogólnie.

• Najbardziej zauważalny wpływ zapytań (Top Queries) - zidentyfikuj zapytania, które należy zoptymalizować w pierwszej kolejności.

• Problemy na poziomie aplikacji (Process Summary) - zidentyfikuj aplikacje, które powodują problemy z wydajnością.

• Problemy na poziomie klienta (Address Summary) - zidentyfikuj adresy IP (stacje robocze, komputery klientów) z największym przepływem zapytań.

2. Analiza Time Summary i Plan-Summary

Zaleca się rozpoczęcie analizy sytuacji wydajnościowej od sekcji Summary. Kliknij tutaj, aby otworzyć sekcję Plan-Summary w przykładowym raporcie.

Time Summary agreguje całkowity czas wykonania dla każdego unikalnego wzorca instrukcji SQL.

Pomyśl o tym jak o raporcie “centrum kosztów”, który pokazuje, które zapytania zużywają najwięcej zasobów bazy danych w czasie.

Jeśli zapytania nie są sparametryzowane, tj. jawnie zawierają wartości parametrów w tekście SQL zamiast symbolu zastępczego parametru (:myparam1), konieczne jest użycie sekcji "Plan-Summary" w celu identyfikacji zapytań o najwyższej częstotliwości.
Przykład zapytania niesparametryzowanego: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Przykład zapytania sparametryzowanego: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Każde zapytanie w sekcji Summary ma nagłówek z następującymi kluczowymi częściami:

• Summary: Procent całkowitego czasu, pokazuje, jaką część całkowitego czasu bazy danych zużywa zapytanie.

• Frequency: Ile razy pojawia się wzorzec zapytania

• Fetch, Read, Write: Metryki zasobów

Na przykład, jeśli jest

Summary: 19.08% (3920272 of 20541791 ms)

To mówi nam, że ten wzorzec zapytania zużywa prawie 20% całkowitego czasu bazy danych - znacząca część, która wymaga natychmiastowej uwagi.

Poniżej nagłówka w sekcji Plan-Summary zobaczymy plan wykonania SQL, który został użyty do grupowania zapytań, w Time-Summary będzie to tekst samego zapytania.

Ponieważ wzorzec zapytania reprezentuje więcej niż jedno konkretne zapytanie, informacje specyficzne dla połączenia pochodzą z pierwszego zapytania odpowiadającego wzorcowi:

Na powyższym zrzucie ekranu widać nagłówek przykładowej instrukcji dla wzorca, składa się on z nazwy aplikacji, która uruchomiła to SQL, ID połączenia i ID transakcji, a także adresu IP i szczegółów transakcji.

Poniżej znajduje się plan (dla Time-Summary, dla Plan-Summary jest pomijany, ponieważ jest już pokazany na początku), wartości parametrów (w kolejności występowania) oraz statystyki per tabela:

Pamiętaj, że w Plan-Summary grupujemy SQL przy użyciu planów wykonania, co oznacza, że tylko plan jest stały dla wzorca, a w Time-Summary grupujemy przy użyciu tekstu instrukcji SQL, a inne rzeczy (wartości parametrów, czasy wykonania itp.) mogą się różnić. Użyj tych informacji jako przykładu wzorca wykonania (w 99% przypadków wystarczy to do odtworzenia problemu).

Poniżej mamy indywidualny wykres z wykonaniami tego konkretnego zapytania. Jak widać, to zapytanie zostało uruchomione w okresie wysokiego obciążenia, który zauważyliśmy na wykresie przeglądowym.

Na końcu mamy bardzo ważną kolekcję statystyk dla WSZYSTKICH zapytań odpowiadających wzorcowi oraz listę adresów pochodzenia:

W tych statystykach możemy zobaczyć minimum, maksimum, średnią i medianę czasów wykonania, te same statystyki dla fetches, reads, writes i marks (operacje flush pamięci podręcznej).

2.1. Jak używać Time Summary:

• Najpierw zidentyfikuj zapytania zużywające nieproporcjonalną ilość czasu (są to top 3 tej sekcji - #1, 2, 3)

• Porównaj zużycie czasu z częstotliwością

• Zobacz średni czas wykonania (całkowity czas / częstotliwość) na dole sekcji zapytania (patrz poniżej)

• Szukaj wzorców, gdzie:

• Wysoki czas + niska częstotliwość = Nieefektywne pojedyncze zapytania

• Wysoki czas + wysoka częstotliwość = Potencjalnie nieefektywne, ale intensywnie używane zapytania

3. Analiza częstotliwości: Frequency i Plan-Frequency

Użyj analizy częstotliwości, aby zrozumieć, jak często wykonywane są zapytania. Pomyśl o tym jak o liczeniu, ile razy dana droga jest używana w godzinach szczytu.

Jeśli zapytania nie są sparametryzowane, tj. jawnie zawierają wartości parametrów w tekście SQL zamiast symbolu zastępczego parametru (:myparam1), konieczne jest użycie sekcji "Plan-Summary" w celu identyfikacji zapytań o najwyższej częstotliwości.
Przykład zapytania niesparametryzowanego: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Przykład zapytania sparametryzowanego: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Zrozumienie wpływu częstotliwości

Reprezentacja wzorca zapytania Frequency jest bardzo podobna do Plan/Time Summary:

Zapytania o wysokiej częstotliwości są jak ruchliwe skrzyżowania - nawet jeśli każde auto (zapytanie) porusza się szybko, sama liczba może powodować zatory. Wpływa to na:

• Połączenia z bazą danych (jak miejsca parkingowe - ograniczone liczbowo)

• Przepustowość sieci (jak przepustowość drogi)

• Użycie CPU (jak przeciążeni kontrolerzy ruchu)

• Wydajność pamięci podręcznej (jak konieczność wielokrotnego dostępu do tych samych informacji)

Aby oszacować wpływ zapytań o wysokiej częstotliwości, zbierz ślad z progiem parametru = 0.

3.2. Kategorie wpływu częstotliwości

3.3. Przykładowa analiza

Przyjrzyjmy się rzeczywistemu przypadkowi z naszego raportu śledzenia:

Częstotliwość: 4 428 wykonań (24,43% całości)
Wpływ: Krytyczny - duża liczba zapytań do tabeli SALES
Przyczyna źródłowa: Powtarzające się sprawdzanie sald klientów
Priorytet optymalizacji: Wysoki

Wyjaśnienie: To zapytanie jest wykonywane tysiące razy, podobnie jak
ruchliwe skrzyżowanie. Nawet jeśli każde wykonanie może być szybkie,
skumulowany wpływ jest znaczący. Aplikacja może sprawdzać salda
częściej niż to konieczne.

4. Analiza statystyk najczęstszych zapytań w sekcjach xx-Summary i Frequency

Podczas analizy raportów śledzenia Firebird, każde grupowanie zapytań zawiera szczegółowe statystyki zbiorcze, które dostarczają kluczowych informacji o wzorcach wydajności. Rozłóżmy każdy wskaźnik i zrozumiemy jego znaczenie dla optymalizacji bazy danych.

4.1. Analiza statystyk zbiorczych

Przyjrzyjmy się przykładowemu zestawowi statystyk:

Razem: 4428 elementów:
Czasy trwania: min: 351; max: 3919; avg: 457.70; mediana: 455.00; suma: 2026710 (20,29%);
Pobrania: min: 7135; max: 7168; avg: 7146.86; mediana: 7147.00; suma: 31646289 (0,75%);
Zapisy: min: 0; max: 0; avg: 0.00; mediana: 0.00; suma: 0 (0,00%);
Odczyty: min: 0; max: 6995; avg: 3.13; mediana: 0.00; suma: 13856 (8,22%);
Znaczniki: min: 0; max: 0; avg: 0.00; mediana: 0.00; suma: 0 (0,00%);
Z 1 unikalnych adresów: TCPv6:::1 (4428)

4.2. Analiza liczby wykonań

4.2.1. Całkowita liczba elementów

Razem: 4428 elementów

To liczba reprezentująca, ile razy ten konkretny wzorzec zapytania został wykonany w okresie śledzenia.

Zrozumienie tej liczby pomaga:

• Obliczyć zużycie zasobów na wykonanie

• Określić, czy buforowanie zapytań może być korzystne (lub po prostu wykonywać je rzadziej)

Wysoka liczba wykonań może wskazywać na możliwości:

• Implementacji przygotowanych zapytań (i sparametryzowanych) - to samo zapytanie z tą samą częstotliwością, gdy jest sparametryzowane i przygotowane do powtarzalnego wykonywania, będzie wymagać mniej zasobów

• Dodania buforowania wyników - buforowanie wartości wynikowej do wykorzystania podczas długiej operacji lub nawet dłużej, na czas sesji użytkownika, może zmniejszyć konieczność częstego wykonywania zapytania

• Grupowania operacji - rozważ wykonanie zapytania w celu zwrócenia lub przetworzenia wielu rekordów naraz, co wyeliminuje narzut związany z wykonywaniem zapytania (przygotowanie, transmisja sieciowa itp.).

4.3. Metryki czasu trwania

4.3.1. Przykład składników czasu trwania

Czasy trwania: min: 351; max: 3919; avg: 457.70; mediana: 455.00; suma: 2026710 (20,29%);

4.3.2. Analiza czasu trwania

• Bliska mediana i średnia (457,70 vs 455,00 ms) sugerują spójną wydajność

• Stosunek max/min (~11x) wskazuje na pewną zmienność

• 20,29% całkowitego czasu jest znaczące - czy to zapytanie znajduje się w pierwszej trójce w sekcji Frequency lub Plan-Frequency? (tak, jest.)

4.4. Metryki zużycia zasobów

4.4.1. Operacje pobierania

Pobrania: min: 7135; max: 7168; avg: 7146.86; mediana: 7147.00; suma: 31646289 (0,75%);

Pobrania reprezentują pobieranie wierszy:

• Spójne liczby pobrań (różnica min/max tylko 33) sugerują stabilne zestawy wyników

• Stosunkowo wysokie liczby pobrań (>7000 na wykonanie) mogą wskazywać na:

• Potrzebę ograniczenia zestawu wyników i/lub paginacji, jeśli zwracanych jest wiele rekordów.

• Potencjał optymalizacji zapytania - szczególnie ma sens, jeśli zapytanie znajduje się w pierwszej trójce sekcji Frequency/Plan-Frequency.

4.5. Operacje odczytu

Odczyty: min: 0; max: 6995; avg: 3.13; mediana: 0.00; suma: 13856 (8,22%);

Odczytu fizyczne wskazują na dostęp do dysku:

• Zerowa mediana z niezerowym maksimum sugeruje sporadyczne braki w pamięci podręcznej

• 8,22% wszystkich odczytów wskazuje na umiarkowany wpływ I/O

• Duża różnica między min (0) a max (6995) sugeruje zmienną skuteczność pamięci podręcznej.

4.6. Operacje zapisu

Zapisy: min: 0; max: 0; avg: 0.00; mediana: 0.00; suma: 0 (0,00%);

Jeśli zapytanie nie wykonuje żadnych zapisów, zwykle jest to operacja tylko do odczytu.

4.7. Operacje znaczników

Znaczniki: min: 0; max: 0; avg: 0.00; mediana: 0.00; suma: 0 (0,00%);

Operacje znaczników dotyczą zarządzania pamięcią podręczną stron danych:

• Zerowe znaczniki wskazują, że żadna strona danych nie została oznaczona do zapisu, co jest typowe dla prostych zapytań SELECT

• Niezerowe operacje znaczników z pamięcią podręczną

4.8. Analiza połączeń klientów

Z 1 unikalnych adresów: TCPv6:::1 (4428)

To pokazuje rozkład źródeł zapytań:

• Pojedynczy adres klienta sugeruje zapytanie specyficzne dla aplikacji

• Połączenie lokalne (::1 to IPv6 localhost)

• Wszystkie 4428 wykonań z tego samego źródła

4.9. Wykorzystanie tych metryk do optymalizacji

4.9.1. Analiza wzorców wydajności

Spójność wykonań

• Porównaj czasy trwania min/max

• Szukaj wartości odstających w zużyciu zasobów

• Sprawdź medianę vs średnią pod kątem zmienności

Wzorce zużycia zasobów

• Wysokie pobrania → Przejrzyj rozmiar zestawu wyników

• Wysokie odczyty → Sprawdź pokrycie indeksów

• Wysokie znaczniki → Zbadaj rywalizację o blokady

Analiza wpływu klientów

• Wielu klientów → Rozmiar puli połączeń

• Pojedynczy klient → Optymalizacja aplikacji

4.9.2. Priorytety optymalizacji

Na podstawie tych metryk, ustal priorytety:

• Rozmiar zestawu wyników

• 7000 pobrań na wykonanie

• Rozważ dodanie LIMIT/OFFSET

• Przejrzyj listę kolumn SELECT

Strategia buforowania

• Częste wykonywanie (4428 razy)

• Spójny rozmiar wyników

• Brak operacji zapisu

Prawdopodobnie to zapytanie może być wykonywane rzadziej.

Użycie indeksów

• Zmienne liczby odczytów

• Zerowa mediana odczytów, ale wysokie maksimum

• Przejrzyj pokrycie indeksów

5. Praktyczne zastosowanie

Dla tego konkretnego przykładu:

Ulepszenia krótkoterminowe:

• Zaimplementuj buforowanie wyników (wysoka liczba wykonań, spójne pobrania)

• Przejrzyj rozmiar zestawu wyników (>7000 pobrań na wykonanie)

Optymalizacja średnioterminowa:

• Przeanalizuj wzorce użycia indeksów

• Rozważ użycie przygotowanych zapytań

• Przejrzyj logikę aplikacji pod kątem częstotliwości wykonywania

Rozważania długoterminowe:

• Monitoruj wzorce wykonywania w czasie

• Zaplanuj strategię konserwacji indeksów

• Rozważ zmiany we wzorcach dostępu do danych

6. Analiza czasu trwania

Analiza czasu trwania bada, jak długo trwa wykonanie poszczególnych zapytań. Pomyśl o czasie trwania jak o stoperze mierzącym każde zapytanie - im dłużej trwa zapytanie, tym bardziej prawdopodobne, że spowoduje problemy z wydajnością.

6.1. Zrozumienie metryk czasu trwania

Metryki czasu trwania są kluczowe, ponieważ bezpośrednio wpływają na doświadczenia użytkowników, tj. użytkownicy twierdzą, że “system jest wolny”. Tak jak klienci frustrują się czekając w długiej kolejce, użytkownicy frustrują się, gdy zapytania trwają zbyt długo. Długo działające zapytania powodują:

• Złe doświadczenia użytkownika, gdy ekrany ładują się zbyt długo

• Zasoby systemu zajęte przez dłuższy czas

• Inne zapytania czekające w kolejce za wolnymi

• Potencjalne problemy z limitami czasu w aplikacjach

6.2. Kategorie wpływu

6.3. Przykładowa analiza

Czas trwania: 77 793ms
Wpływ: Krytyczny - pojedyncze zapytanie zużywające 77,7 sekundy
Przyczyna źródłowa: Złożona agregacja w PRC_COLLECT_RANKCATEGORY
Priorytet optymalizacji: Natychmiastowy

Wyjaśnienie: To zapytanie zajmuje ponad minutę, co jest jak
całkowite zatrzymanie ruchu. Procedura składowana prawdopodobnie
przetwarza zbyt dużo danych lub używa nieefektywnych algorytmów.

7. Strategia wdrożenia

Pomyśl o optymalizacji jak o ulepszaniu systemu transportowego - musisz zidentyfikować problemy, zaplanować rozwiązania i ostrożnie wdrożyć zmiany.

7.1. Macierz priorytetów

Ta macierz pomaga zdecydować, co wymaga uwagi w pierwszej kolejności, jak triaż problemów drogowych w mieście:

7.2. Proces optymalizacji krok po kroku

1. Zidentyfikuj krytyczne zapytania

• Szukaj największych korków (wolne zapytania)

• Znajdź najbardziej ruchliwe skrzyżowania (zapytania o wysokiej częstotliwości)

• Wykryj nieefektywne trasy (wysokie zużycie zasobów)

2. Przeanalizuj plany wykonania

• Zbadaj obecne trasy (użycie indeksów)

• Przeanalizuj wzorce ruchu (metody łączenia)

• Sprawdź wąskie gardła (operacje sortowania)

3. Wdróż optymalizacje

• Zbuduj nowe drogi (indeksy)

• Przeprojektuj trasy (restrukturyzacja zapytań)

• Dodaj skróty (buforowanie)

4. Zweryfikuj ulepszenia

• Zmierz nowy przepływ ruchu (nowy raport śledzenia)

• Porównaj metryki przed/po

• Udokumentuj, co zadziałało

Skontaktuj się z IBSurgeon w razie jakichkolwiek pytań

Zapraszamy do kontaktu z nami w razie jakichkolwiek pytań: [email protected].