Příklad analýzy výkonu

Pro postupování podle video instrukcí otevřete příklad reportu zde.

Jak interpretovat report o výkonu

Pomocí HQbird, nebo jako samostatné služby IBSurgeon Performance Analysis z cc.ib-aid.com, můžete vygenerovat report o výkonu z Firebird trace logů.

Tento report je výkonný diagnostický nástroj, který poskytuje podrobné informace o provádění SQL dotazů v databázích Firebird. Tento průvodce vysvětluje, jak interpretovat a používat trace reporty k systematické identifikaci a řešení výkonnostních problémů.

1. Struktura reportu o výkonu

┌─────────────────────────────────────────┐
│         Report o výkonu                 │
├─────────────────────────────────────────┤
│ 1. Souhrnné grafy výkonu                │
│    ┌────────────────────────┐           │
│    │  Nejlepší dotazy       │           │
│    │     Top souhrn         │           │
│    │     Top frekvence      │           │
│    │     Doby trvání        │           │
│    │     Fetch operace      │           │
│    │     Čtení              │           │
│    │     Zápisy             │           │
│    │  Časový graf           │           │
│    │     Doby trvání        │           │
│    │     Počet dotazů       │           │
│    │     Fetch operace      │           │
│    │     Čtení/Zápisy       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Analýza nejlepších dotazů            │
│    ┌────────────────────────┐           │
│    │ Žebříčky dotazů        │           │
│    │                        │           │
│    │  Podle doby trvání───┐ │           │
│    │                      │ │           │
│    │  Podle času   ───────┤ │           │
│    │  Souhrn             │ │           │
│    │                      │ │           │
│    │  Podle plánu  ───────┤ │           │
│    │  Souhrn             │ │           │
│    │                      │ │           │
│    │  Podle frekvence ────┤ │           │
│    │                      │ │           │
│    │  Podle plánu  ───────┤ │           │
│    │  Frekvence          │ │           │
│    │                      │ │           │
│    │  Podle fetch ────────┤ │           │
│    │                      │ │           │
│    │  Podle čtení  ───────┤ │           │
│    │                      │ │           │
│    │  Podle zápisů ───────┘ │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Souhrn procesů                       │
│    ┌────────────────────────┐           │
│    │ Statistiky per proces  │           │
│    │ - Počty provedení      │           │
│    │ - Fetch operace, atd.  │           │
│    │ - Metriky doby trvání  │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Souhrn adres                         │
│    ┌────────────────────────┐           │
│    │Statistiky per adresa    │           │
│    │ klienta                │           │
│    │ - Počty připojení      │           │
│    │ - Doby trvání          │           │
│    │ - Fetch operace, atd.  │           │
│    │ - Názvy procesů        │           │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Struktura detailů dotazu:
┌────────────────────┐
│ Informace o dotazu │
├────────────────────┤
│ - Text SQL         │
│ - Info o transakci │
│ - Plán provedení   │
│ - Statistiky doby  │
│ - Statistiky zdrojů│
│   * Fetch operace  │
│   * Čtení          │
│   * Zápisy         │
│   * Označení       │
│ - Info o klientovi │
└────────────────────┘

Report o výkonu poskytuje hierarchický pohled na aktivitu databáze:

1. Souhrnné grafy výkonu

• Vizuální reprezentace klíčových metrik v čase - snadno uvidíte špičky aktivity/zátěže. (K dispozici je také report s minutovou analýzou v Advanced Performance Monitoring v HQbird, zkrácená verze je dostupná na Portálovém nástroji - podrobnosti viz toto video).

• Pomáhá identifikovat vzorce a anomálie: porovnání grafik z období s dobrým výkonem (např. minulý týden/měsíc) s výkonnostními problémy může pomoci identifikovat problém.

2. Analýza nejlepších dotazů

• Více pohledů na pořadí pro komplexní analýzu: nejdelší dotazy, nejčastější dotazy, časově nejnáročnější dotazy (seskupené podle textu nebo plánu) a další.

• Každá dimenze odhaluje různé optimalizační příležitosti

• Podrobné statistiky pro každý dotaz včetně:

• Metriky doby trvání (min, max, průměr, medián)

• Spotřeba zdrojů (fetch operace, čtení, zápisy)

• Vzorce provedení - počet zdrojů pro nejlepší dotazy.

3. Souhrn procesů

• Seskupuje statistiky podle provádějícího procesu

• Pomáhá identifikovat problematické aplikace

• Ukazuje spotřebu zdrojů a databázové operace (připojení, dotazy atd.) a metriky (fetch operace, čtení atd.) per proces

4. Souhrn adres

• Seskupuje statistiky podle připojení klienta

• Odhaluje rozložení zátěže mezi klienty

• Pomáhá identifikovat problémy specifické pro připojení

Každá sekce podporuje analýzu výkonu na různých úrovních:

• Systémové vzorce (Grafy) - zjistěte, kdy a kde se problémy obecně vyskytují.

• Nejvýraznější dopad dotazů (Nejlepší dotazy) - identifikujte dotazy, které by měly být optimalizovány jako první.

• Problémy na úrovni aplikací (Souhrn procesů) - identifikujte aplikace, které způsobují výkonnostní problémy.

• Problémy na úrovni klientů (Souhrn adres) - identifikujte IP adresy (pracovní stanice, klientské počítače) s největším tokem dotazů.

2. Analýza časového souhrnu a souhrnu plánů

Doporučuje se začít analýzu situace s výkonem sekcemi Souhrn. Klikněte zde pro otevření sekce Souhrn plánů v příkladovém reportu.

Časový souhrn agreguje celkovou dobu provedení pro každý jedinečný vzor SQL příkazu.

Představte si to jako report “nákladového střediska”, který ukazuje, které dotazy spotřebovávají nejvíce databázových zdrojů v průběhu času.

Pokud dotazy nejsou parametrizované, tj. explicitně obsahují hodnoty parametrů v textu SQL místo zástupného symbolu parametru (:myparam1), je nutné použít sekci "Souhrn plánů" k identifikaci dotazů s nejvyšší frekvencí.
Příklad neparametrizovaného dotazu: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Příklad parametrizovaného dotazu: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Každý dotaz v sekci Souhrn má hlavičku s následujícími klíčovými částmi:

• Souhrn: Procento celkového času, ukazuje, jakou část celkového času databáze dotaz spotřebovává.

• Frekvence: Kolikrát se vzor dotazu vyskytuje

• Fetch, Čtení, Zápis: metriky zdrojů

Například, pokud je zde

Souhrn: 19.08% (3920272 z 20541791 ms)

To nám říká, že tento vzor dotazu spotřebovává téměř 20% celkového času databáze - významná část, která si zaslouží okamžitou pozornost.

Pod hlavičkou v sekci Souhrn plánů uvidíme plán provedení SQL, který byl použit pro seskupení dotazů, v Časovém souhrnu to bude text samotného dotazu.

Protože vzor dotazu představuje více než jeden konkrétní dotaz, informace specifické pro připojení jsou převzaty z prvního dotazu, který odpovídá vzoru:

Na výše uvedeném snímku obrazovky vidíte hlavičku příkladového příkazu pro vzor, skládá se z názvu aplikace, která spustila tento SQL, ID připojení a ID transakce, stejně jako IP adresy a podrobností o transakci.

Níže následuje plán (pro Časový souhrn; pro Souhrn plánů je přeskočen, protože je již zobrazen na začátku), hodnoty parametrů (v pořadí výskytu) a statistiky per tabulka:

Pamatujte prosím, že v Souhrnu plánů seskupujeme SQL pomocí plánu provedení, což znamená, že pouze plán je konzistentní pro vzor, a pro Časový souhrn seskupujeme pomocí textu SQL příkazu, a ostatní věci (hodnoty parametrů, doby provedení atd.) se mohou lišit. Použijte tyto informace jako příklad vzoru provedení (v 99% případů to stačí k reprodukci problému).

Níže máme individuální graf s provedeními tohoto konkrétního dotazu. Jak vidíte, tento dotaz byl spuštěn v období vysoké zátěže, kterou jsme zaznamenali na přehledovém grafu.

A na konci máme velmi důležitou kolekci statistik pro VŠECHNY dotazy, které odpovídají vzoru, a seznam adres zdrojů:

V těchto statistikách vidíme minimum, maximum, průměr a medián dob provedení, stejné statistiky pro fetch operace, čtení, zápisy a označení (operace vyprázdnění cache).

2.1. Jak používat Časový souhrn:

• Nejprve identifikujte dotazy spotřebovávající nepřiměřené množství času (jsou top 3 v této sekci - #1, 2, 3)

• Porovnejte spotřebu času s frekvencí

• Podívejte se na průměrnou dobu provedení (celkový čas / frekvence) ve spodní části sekce dotazu (viz níže)

• Hledejte vzorce, kde:

• Vysoký čas + Nízká frekvence = Neefektivní jednotlivé dotazy

• Vysoký čas + Vysoká frekvence = Potenciálně neefektivní, ale hojně používané dotazy

3. Analýza frekvence: Frekvence a Frekvence plánů

Použijte analýzu frekvence k pochopení, jak často se dotazy spouštějí. Představte si to jako počítání, kolikrát je konkrétní silnice použita během dopravní špičky.

Pokud dotazy nejsou parametrizované, tj. explicitně obsahují hodnoty parametrů v textu SQL místo zástupného symbolu parametru (:myparam1), je nutné použít sekci "Souhrn plánů" k identifikaci dotazů s nejvyšší frekvencí.
Příklad neparametrizovaného dotazu: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Příklad parametrizovaného dotazu: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Pochopení dopadu frekvence

Reprezentace vzoru frekvence dotazů je velmi podobná Souhrnu plánů/času:

Vysokofrekvenční dotazy jsou jako rušné křižovatky - i když se každé auto (dotaz) pohybuje rychle, samotný objem může způsobit kongesci. To ovlivňuje:

• Databázová připojení (jako parkovací místa - omezený počet)

• Síťovou šířku pásma (jako kapacitu silnice)

• Využití CPU (např. zahlcení řídicích jednotek)

• Efektivita mezipaměti (např. nutnost opakovaného přístupu ke stejným informacím)

Pro odhad dopadu dotazů s vysokou frekvencí shromážděte trasování s prahem parametru = 0.

3.2. Kategorie dopadu frekvence

3.3. Příklad analýzy

Podívejme se na skutečný případ z naší zprávy o trasování:

Frekvence: 4 428 provedení (24,43 % z celku)
Dopad: Kritický - vysoký objem dotazů na tabulku SALES
Hlavní příčina: Opakované kontroly zůstatků zákazníků
Priorita optimalizace: Vysoká

Vysvětlení: Tento dotaz se spouští tisíckrát, podobně jako
rušná křižovatka. I když každé provedení může být rychlé,
kumulativní dopad je významný. Aplikace může kontrolovat
zůstatky častěji, než je nutné.

4. Analýza statistik nejlepších dotazů v sekcích xx-Summary a Frequency

Při analýze zpráv o trasování Firebird obsahuje každé seskupení dotazů podrobné souhrnné statistiky, které poskytují klíčové informace o vzorcích výkonu. Pojďme si rozebrat každou metriku a pochopit její význam pro optimalizaci databáze.

4.1. Analýza souhrnných statistik

Podívejme se na tento příklad souboru statistik:

Celkem: 4428 položek:
Doby trvání: min: 351; max: 3919; průměr: 457,70; medián: 455,00; součet: 2026710 (20,29 %);
Fetch: min: 7135; max: 7168; průměr: 7146,86; medián: 7147,00; součet: 31646289 (0,75 %);
Zápisy: min: 0; max: 0; průměr: 0,00; medián: 0,00; součet: 0 (0,00 %);
Čtení: min: 0; max: 6995; průměr: 3,13; medián: 0,00; součet: 13856 (8,22 %);
Značky: min: 0; max: 0; průměr: 0,00; medián: 0,00; součet: 0 (0,00 %);
Z 1 jedinečné adresy: TCPv6:::1 (4428)

4.2. Analýza počtu provedení

4.2.1. Celkový počet položek

Celkem: 4428 položek

Toto číslo představuje počet provedení tohoto konkrétního vzoru dotazu během období trasování.

Pochopení tohoto čísla vám pomůže:

• Vypočítat využití prostředků na jedno provedení

• Určit, zda by mohlo být přínosné ukládání dotazů do mezipaměti (nebo jednoduše spouštět dotaz méně často)

Vysoký počet provedení může naznačovat příležitosti pro:

• Implementaci připravených příkazů (a parametrizovaných) - stejný dotaz se stejnou frekvencí, pokud je parametrizovaný a připravený pro opakované provedení, bude vyžadovat méně prostředků

• Přidání ukládání výsledků do mezipaměti - ukládání výsledné hodnoty pro použití během dlouhé operace nebo i déle, pro uživatelskou relaci, může snížit potřebu častého provádění dotazu

• Dávkové operace - zvažte provedení dotazu pro vrácení nebo zpracování mnoha záznamů najednou, což odstraní režii na provedení dotazu (příprava, přenos po síti atd.).

4.3. Metriky doby trvání

4.3.1. Příklad komponent doby trvání

Doby trvání: min: 351; max: 3919; průměr: 457,70; medián: 455,00; součet: 2026710 (20,29 %);

4.3.2. Analýza doby trvání

• Blízký medián a průměr (457,70 vs 455,00 ms) naznačuje konzistentní výkon

• Poměr max/min (~11x) naznačuje určitou variabilitu

• 20,29 % celkového času je významné - je tento dotaz v top 3 v sekci Frequency nebo Plan-Frequency? (ano, je.)

4.4. Metriky využití prostředků

4.4.1. Operace Fetch

Fetch: min: 7135; max: 7168; průměr: 7146,86; medián: 7147,00; součet: 31646289 (0,75 %);

Fetch představují načítání řádků:

• Konzistentní počty fetch (rozdíl min/max pouze 33) naznačují stabilní sady výsledků

• Relativně vysoké počty fetch (>7000 na provedení) mohou naznačovat:

• Potřebu omezení sady výsledků a/nebo stránkování, pokud se vrací mnoho záznamů.

• Potenciál pro optimalizaci dotazu - dává smysl zejména pokud je dotaz v top 3 sekce Frequency/Plan-Frequency.

4.5. Operace čtení

Čtení: min: 0; max: 6995; průměr: 3,13; medián: 0,00; součet: 13856 (8,22 %);

Fyzická čtení indikují přístup na disk:

• Nulový medián s nenulovým maximem naznačuje občasné chyby mezipaměti

• 8,22 % celkových čtení indikuje mírný dopad na I/O

• Velký rozdíl mezi min (0) a max (6995) naznačuje proměnnou efektivitu mezipaměti.

4.6. Operace zápisu

Zápisy: min: 0; max: 0; průměr: 0,00; medián: 0,00; součet: 0 (0,00 %);

Pokud dotaz neprovádí žádné zápisy, obvykle se jedná o operaci pouze pro čtení.

4.7. Operace značek

Značky: min: 0; max: 0; průměr: 0,00; medián: 0,00; součet: 0 (0,00 %);

Operace značek souvisí se správou mezipaměti datových stránek:

• Nulové značky indikují, že žádná datová stránka nebyla označena pro zapsání, běžné pro jednoduché SELECT dotazy

• Nenulové operace značek souvisí s mezipamětí

4.8. Analýza připojení klienta

Z 1 jedinečné adresy: TCPv6:::1 (4428)

Toto ukazuje distribuci zdrojů dotazů:

• Jediná adresa klienta naznačuje dotaz specifický pro aplikaci

• Lokální připojení (::1 je IPv6 localhost)

• Všech 4428 provedení ze stejného zdroje

4.9. Použití těchto metrik pro optimalizaci

4.9.1. Analýza vzorců výkonu

Konzistence provedení

• Porovnejte min/max doby trvání

• Hledejte odlehlé hodnoty ve využití prostředků

• Zkontrolujte medián vs průměr pro variabilitu

Vzorce využití prostředků

• Vysoké fetch → Zkontrolujte velikost sady výsledků

• Vysoká čtení → Zkontrolujte pokrytí indexů

• Vysoké značky → Prozkoumejte konflikty zámků

Analýza dopadu klienta

• Více klientů → Velikost fondu připojení

• Jeden klient → Optimalizace aplikace

4.9.2. Priority optimalizace

Na základě těchto metrik upřednostněte:

• Velikost sady výsledků

• 7000 fetch na provedení

• Zvažte přidání LIMIT/OFFSET

• Zkontrolujte seznam sloupců v SELECT

Strategie ukládání do mezipaměti

• Časté provedení (4428krát)

• Konzistentní velikost výsledků

• Žádné zápisy

Pravděpodobně lze tento dotaz provádět méně často.

Použití indexů

• Proměnný počet čtení

• Nulový medián čtení, ale vysoké maximum

• Zkontrolujte pokrytí indexů

5. Praktické použití

Pro tento konkrétní příklad:

Krátkodobá zlepšení:

• Implementujte ukládání výsledků do mezipaměti (vysoký počet provedení, konzistentní fetch)

• Zkontrolujte velikost sady výsledků (>7000 fetch na provedení)

Střednědobá optimalizace:

• Analyzujte vzorce použití indexů

• Zvažte použití připravených příkazů

• Zkontrolujte logiku aplikace pro frekvenci provedení

Dlouhodobé úvahy:

• Sledujte vzorce provedení v průběhu času

• Naplánujte strategii údržby indexů

• Zvažte změny vzorců přístupu k datům

6. Analýza doby trvání

Analýza doby trvání zkoumá, jak dlouho trvá provedení jednotlivých dotazů. Představte si dobu trvání jako stopky měřící každý dotaz - čím déle dotaz trvá, tím pravděpodobněji způsobí problémy s výkonem.

6.1. Pochopení metrik doby trvání

Metriky doby trvání jsou klíčové, protože přímo ovlivňují uživatelskou zkušenost, tj. uživatelé tvrdí, že „systém je pomalý“. Stejně jako se zákazníci frustrují při dlouhém čekání ve frontě, uživatelé se frustrují, když dotazy trvají příliš dlouho. Dlouhé dotazy způsobují:

• Špatnou uživatelskou zkušenost, když načítání obrazovek trvá příliš dlouho

• Vázání systémových prostředků na delší dobu

• Ostatní dotazy čekající ve frontě za pomalými

• Potenciální problémy s časovým limitem v aplikacích

6.2. Kategorie dopadu

6.3. Příklad analýzy

Doba trvání: 77 793 ms
Dopad: Kritický - jeden dotaz spotřebovává 77,7 sekund
Hlavní příčina: Komplexní agregace v PRC_COLLECT_RANKCATEGORY
Priorita optimalizace: Okamžitá

Vysvětlení: Tento dotaz trvá přes minutu, což je jako
úplné zastavení provozu. Uložená procedura pravděpodobně
zpracovává příliš mnoho dat nebo používá neefektivní algoritmy.

7. Strategie implementace

Představte si optimalizaci jako zlepšování dopravního systému - musíte identifikovat problémy, naplánovat řešení a pečlivě implementovat změny.

7.1. Matice priorit

Tato matice vám pomůže rozhodnout, co potřebuje pozornost jako první, podobně jako třídění dopravních problémů ve městě:

7.2. Postup optimalizace krok za krokem

1. Identifikujte kritické dotazy

• Hledejte největší dopravní zácpy (pomalé dotazy)

• Najděte nejrušnější křižovatky (dotazy s vysokou frekvencí)

• Odhalte neefektivní trasy (vysoké využití prostředků)

2. Analyzujte plány provedení

• Studujte aktuální trasy (použití indexů)

• Prozkoumejte dopravní vzorce (metody spojení)

• Zkontrolujte úzká místa (operace řazení)

3. Implementujte optimalizace

• Postavte nové silnice (indexy)

• Předělejte trasy (restrukturalizace dotazů)

• Přidejte zkratky (ukládání do mezipaměti)

4. Ověřte zlepšení

• Změřte nový dopravní tok (nová zpráva o trasování)

• Porovnejte metriky před/po

• Zdokumentujte, co fungovalo

Kontaktujte IBSurgeon s jakýmikoli dotazy

Neváhejte nás kontaktovat s jakýmikoli dotazy: [email protected].