IBAnalyst: co můžete vidět v souhrnném zobrazení

Dmitry Kuzmenko, poslední aktualizace 31-03-2014

Abstrakt

Tento dokument je věnován vysvětlení informací na stránce „Summary view“ v IBAnalyst a tomu, jak tyto informace interpretovat pro vlastní statistiky databáze. Také jsme do instalačního balíčku přidali několik příkladů statistik, abyste si usnadnili studium všech detailů statistik InterBase. Jsou v adresáři Examples instalace IBAnalyst.

Pokud nevíte, co je Oldest transaction, Oldest snapshot, active a Next, přečtěte si prosím nejprve článek Craiga Stunze „Understanding Transactions Lifetime“:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Čísla transakcí

Pokud jste si přečetli článek Understanding Transaction Lifetimes, možná stále máte otázky ohledně čísel OIT/OST/OAT. Zde je stručný popis:


Číslo	Drží se, …	Posouvá se vpřed, …
Oldest transaction	když byla transakce s tímto číslem vrácena zpět (rollback) a bylo v ní mnoho změn dat, nebo když bylo ztraceno připojení klienta	když proběhne automatický nebo ruční sweep.
Oldest Snapshot	když je snapshot (nebo read committed write před IB 7.1) aktivní po dlouhou dobu (zapamatoval si nejstarší aktivní snapshot jako svůj lokální OST)	když začne nová transakce, pokud transakce držící OST skončila
Oldest Active	když je transakce s tímto číslem aktivní po dlouhou dobu	když začne nová transakce, pokud transakce držící OAT skončila
Next	nikdy	když začne nová transakce

poznámka: Oldest transaction zde je totéž co Oldest Interesting Transaction (OIT), zmiňovaný v mnoha dalších článcích.

Přesné statistiky se standardním nastavením

Spustíme IBAnalyst a otevřeme (příkazem Statistics/Load statistics from file menu) soubor !allok.txt.

IBAnalyst nehlásí pouze datum vytvoření databáze, ale také rozpozná aktuální datum a čas na serveru, pokud byly statistiky pořízeny přes Services API, nebo datum a čas souboru, pokud se jedná o načtený soubor statistik.

Proto doporučujeme nemodifikovat soubory statistik, protože v tomto případě bude IBAnalyst počítat průměrný počet transakcí za den nesprávně. Řádek Transactions per day zde ukazuje přibližně ~12500 transakcí za den a že databáze „žije“ od svého vytvoření nebo obnovení (restore) 8 dní.

Oldest, Oldest snapshot, Oldest active a Next transakce jsou zde v perfektním stavu, přejeme vám, aby vaše statistiky vždy vypadaly takto.

Mnoho aktivních transakcí

Dále otevřeme soubor !lotofactive.txt (kdykoli se můžete podívat zpět na obrázek !allok a porovnat následující příklady s ním).

Zde je řádek Active transactions označen červeně, protože je velký rozdíl mezi Oldest active a Next transakcí. To znamená, že některá transakce byla v okamžiku pořízení statistik stále aktivní a po jejím startu již začalo 55 000 transakcí (mohou být v jakémkoli stavu - aktivní, potvrzené, vrácené zpět). Protože průměrný počet transakcí za den je ~12500, IBAnalyst vám zobrazí varování, že některá transakce stále žije 4,4 dní. To se může stát, když:

některá aplikace stále běží a má otevřenou alespoň jednu transakci - nějaký uživatel možná nechává aplikaci běžet dlouhou dobu
aplikace běží dlouhou dobu a ztrácí transakční handly - tj. váš kód (nebo komponenty/knihovny, které používáte) dynamicky spouští transakce a za určitých okolností „zapomene“ je ukončit rollbackem nebo commitem.
vaše aplikace nepoužívá explicitní transakce (BDE), přenechává správu transakcí používaným komponentám. Výsledkem je, že životnost transakcí není řízena aplikací a můžete si být jisti, že většina transakcí Next-OAT je skutečně aktivních.
vaše aplikace používá ovladač nebo komponenty, které umožňují „výchozí transakci“. Pokud váš kód tuto transakci neřídí, může běžet velmi dlouho.

Bohužel statistiky neukazují skutečný počet aktuálně aktivních transakcí. To lze zobrazit pouze v InterBase 7.x pomocí IBConsole, IB Performance Monitor nebo přímým dotazem na dočasnou systémovou tabulku tmp$transactions. Ve Firebirdu 1.5 můžete zavolat isc_database_info s parametrem isc_info_active_transactions.

Sweeping

Nyní otevřeme !needsweep.txt.

Sweep je proces údržby uvnitř InterBase. Sweep prochází všechny záznamy v databázi a snaží se vyčistit všechny nepotřebné verze (garbage), poté se snaží posunout číslo Oldest transaction výše. V nově vytvořené databázi je výchozí interval sweepu 20000. Když rozdíl mezi transakcemi (viz tabulka níže) překročí interval sweepu, sweep se spustí automaticky. Tak můžete na své databázi pozorovat periodické snižování výkonu. Například vaše aplikace fungují dobře v pondělí a úterý, ale ve středu uživatelé hlásí problémy s výkonem po několik hodin a poté se výkon opět vrátí do normálu.

Pokud pozorujete podobné chování - jedná se o automatický sweep.


Verze serveru	Kdy se sweep spustí
InterBase 7.x	(Oldest Active - Oldest) > interval sweepu
InterBase 4.x, 5.x, 6.x, Firebird před 1.5.2, Yaffil	(Oldest Snapshot - Oldest) > interval sweepu

Tabulka 1. Podmínky pro automatický sweep

poznámka: IBAnalyst automaticky zobrazuje správné informace o mezeře sweepu pro všechny verze. IBAnalyst dokáže rozlišit rozdíly mezi implementacemi serveru pouze podle ID ODS, například InterBase 7.x má ODS 11.x, ostatní moderní servery mají ODS 10.x. Pokud pracujete pouze s databázemi InterBase 7.x (ODS 11), můžete přepnout příslušnou volbu v dialogu Options.

Když má vaše databáze interval sweepu <> 0, IBAnalyst tento řádek v podstatě označí žlutě (varování, že automatický sweep může začít v jakémkoli nepředvídatelném okamžiku). Obecně má 60 % všech aplikací problémy s automatickým sweepingem. Nejsnazší způsob, jak se tomuto problému vyhnout, je nastavit interval sweepu na 0, což vede k vypnutí automatického sweepingu. Pokud ale některá aplikace provede mnoho změn a poté je vrátí zpět (rollback), Oldest transaction zamrzne a nepohne se vpřed, dokud se nespustí sweep. Protože se efektivní stav transakcí počítá od Oldest po Next transakci, tato vzdálenost poroste a výkon klesne. Abyste tomu zabránili, musíte spustit sweep ručně (gfix -sweep). Na tomto obrázku vidíte chování, když je interval sweepu 0 a došlo k vrácení velké transakce:

Zde hodnota sweep gap ukazuje, že nějaká velká (s mnoha změnami) transakce byla vrácena zpět přibližně před 4,5 dny. Doporučujeme spouštět sweep ručně každý den.

Samozřejmě, pro zmíněných 60 % aplikací může být lepší nastavit interval sweepu větší nebo menší než 20000, ale záleží to na mnoha faktorech (denní počet transakcí je jedním z těchto faktorů, například) a lze to pochopit pouze experimentálně. Pokud tedy nastavíte interval sweepu na 0, můžete si být jisti, že se sweep nespustí automaticky v nepředvídatelném okamžiku.

Stejný obrázek můžete vidět pro soubor !rollback.txt.

poznámka: Pokud sweep běží automaticky, u velké databáze nebo databáze s velkým množstvím nepotřebných verzí záznamů se Snapshot, Active a Next transakce mohou posunout vpřed, zatímco sweep pracuje, a sweep se může znovu spustit při nejbližším startu transakce.

Když sweep nemůže vykonat svou práci

Existuje mnoho případů, kdy sweep nemůže posunout Oldest transaction výše. Sweep se samozřejmě nejprve snaží vykonat svou práci, tj. zkontrolovat všechny záznamy v databázi a shromáždit nepotřebné verze záznamů. Ale bude se spouštět znovu a znovu bez úspěchu, pokud

došlo k nějakému problému při běhu sweepu: server byl zastaven během sweepu, nebo došlo k chybě při čištění nepotřebných verzí záznamů. Tento obrázek můžete také vidět, když:

statistiky byly pořízeny, když sweep pracoval
sweep běží a snaží se shromáždit nepotřebná data pro tabulku, která je neustále aktualizována. To může trvat, dokud aktualizace neskončí.
sweep je zablokován na zámcích stránek, protože s daty pracuje mnoho uživatelů.

Obecně sweep nemá šanci dokončit práci při vysokém zatížení databáze. Obvykle, když výkon klesne na nemožnost pokračovat v normální práci, DBA restartuje server a sweep se spustí při prvním připojení uživatele. Protože než se připojí ostatní uživatelé, bude nějaký čas, sweep stihne dokončit svou práci.

Protože InterBase 7.1/7.5 počítá mezeru sweepu odlišně od předchozích verzí, další situace, kdy sweep nemůže vykonat svou práci, nastává, když některá aplikace má dlouho běžící snapshot transakci:

Zde jsou dvě varování - jedno (žluté) o dlouho běžícím snapshotu a druhé (červené) o intervalu sweepu a mezeře sweepu.

Dlouho běžící snapshot

Předchozí obrázek indikuje dlouho běžící snapshot v InterBase 7.1/7.5. Pokud by byl interval sweepu nastaven na 0, nebyla by zde červená varování, pouze žlutá. Podobný obrázek bude indikovat dlouho běžící snapshot transakci v jiných verzích InterBase, Firebirdu a Yaffilu:

Jak vidíte, zde se mezera sweepu počítá z rozdílu Oldest Snapshot a Oldest transaction (pro ODS 10, verze před IB 7.x). Takže zde není žádné varování o sweepu (kromě výchozího intervalu sweepu).

Ale nejen snapshot transakce ovlivňují stav transakcí tímto způsobem. Všechny verze InterBase, Firebirdu a Yaffilu kromě InterBase 7.1/7.5 mají následující chování, které jsme nazvali „read committed artefakt“.

Snapshots znovu a Když ReadCommitted zamrazí Oldest Snapshot

Otevřete !snapshot2.txt:

Všimněte si, že Oldest transaction je větší než Oldest snapshot. A mezera sweepu má zápornou hodnotu. To se může stát ve dvou případech. První případ je, když některé snapshot transakce začínají a končí jedna po druhé. Tj. tento obrázek se může stát se snapshots stejně jako předchozí obrázek. Další případ nastává pouze na serverech jiných než IB 7.1/7.5 s transakcemi ReadCommitted (nebo v kombinaci transakcí ReadCommitted a Snapshot). Mohou zamrazit číslo Oldest Snapshot stejným způsobem jako snapshot transakce. Aktuální stav transakcí lze simulovat následující sekvencí:

spusťte transakci 1, snapshot nebo read_committed
spusťte/ukončete některé read_committed transakce
spusťte transakci 2, snapshot nebo read_committed
spusťte/ukončete některé read_committed transakce
ukončete transakci 1

(samozřejmě zde mluvíme o read_committed write transakcích, ne read-only).

V tomto okamžiku aktuálně aktivní transakce 2 (snapshot nebo read committed), spuštěná po snapshotu 1 (bod 3), bude držet číslo snapshotu jako Oldest Snapshot (pokud pracujete s IB 7.1/7.5, toto se může stát pouze pro souběžné snapshot transakce. read_committed nebo read_committed+snapshot tento efekt nezpůsobí). Protože nedošlo k žádným velkým rollbackům, Oldest transaction se posouvá vpřed a stává se větší než Oldest Snapshot.

Nyní, pokud máte dlouho běžící read committed transakci, uvidíte obrázek jako tento. Bohužel zde nemůžete se svými aplikacemi nic dělat (kromě přidání parametru „read“ pro read-only transakce). A samozřejmě, sweep se v tomto případě automaticky nespustí (pokud je nastaven <> 0).

poznámka: toto chování bude opraveno ve Firebirdu 2.0

Absolutní a relativní pohledy

Ve výchozím nastavení IBAnalyst vyplňuje řádky transakcí podle procent jejich absolutní hodnoty. Tj. 100 % je od 0 do Next transakce. Někdy, když databáze pracuje dlouhou dobu, můžete vidět informace o transakcích jako

Zatímco je mnoho transakcí, rozdíl mezi snapshot, active a oldest vypadá velmi malý (blízko 98 %). Aby byla situace jasnější, otevřete dialog Options, záložku Transactions a zaškrtněte volbu „Relative (from oldest) bars %“ (toto zaškrtávací políčko nelze nastavit, pokud používáte starý styl pohledu bez grafických pruhů). Po stisknutí tlačítka OK se pohled na transakce změní na

Nyní vidíte rozdíl transakcí v relativním zobrazení (100 % je od nejstarší (nebo snapshot) transakce k další, ne od 0). Je snazší pochopit aktuální situaci a zobrazit varování (pokud nějaká jsou).

Toto zobrazení zůstane aktivní, dokud jej nezrušíte v dialogu Možnosti. Můžete poznat, jaké zobrazení vidíte, podle řádku Nejstarší transakce nebo Nejstarší snapshot - v relativním zobrazení není žádný z těchto řádků nikdy vyplněn zelenou barvou. V absolutním zobrazení je vždy vyplněn (samozřejmě částečně).

Stále máte otázky? Zeptejte se nás na [email protected]