IBAnalyst: Jak správně získat statistiky z databáze InterBase/Firebird

Dmitry Kuzmenko, poslední aktualizace 31-03-2014

Abstrakt

Tento dokument je věnován tipům a trikům pro shromažďování a analýzu statistik z databází InterBase/Firebird s použitím IBAnalyst nebo bez něj.

Správný čas, správné místo

Zní to divně, ale pouhé získání statistik pomocí gstat nebo Services API nestačí. Statistiky musí být pořízeny ve správný okamžik, aby ukázaly, jak aplikace ovlivňují data a transakce v databázi. Nejhorší čas pro pořízení statistik je

Těsně po obnově (restore)
Po zálohování (gbak -b db.gdb) bez přepínače -g
Po ručním sweepu (gfix -sweep)

Je také pravda, že během práce mohou nastat okamžiky, kdy je databáze ve správném stavu, například když aplikace vytvářejí menší zátěž databáze než obvykle (uživatelé při spuštění, oběd nebo podle konkrétních časů obchodních procesů).

Jak zjistit, kdy je v databázi něco špatně?

Ano, vaše aplikace mohou být navrženy tak dokonale, že budou vždy pracovat s transakcemi a daty správně, bez vytváření sweep mezer, mnoha aktivních transakcí, dlouhých snapshotů a podobně. Obvykle se to nestává. Přinejmenším proto, že někteří vývojáři testují své aplikace s 2-3 současnými uživateli, ne více. Když tedy nasadí napsané aplikace pro 15 a více současných uživatelů, databáze se může chovat nepředvídatelně. Samozřejmě, víceuživatelský režim může fungovat dobře, protože většinu víceuživatelských konfliktů lze otestovat s 2-3 současně běžícími aplikacemi. Ale když pak poběží více souběžných aplikací, mohou nastat problémy s garbage collection (přinejmenším). A to lze zachytit, pokud pořizujete statistiky ve správných okamžicích.

Pokud nemáte periodické problémy s výkonem

To se může stát, když jsou vaše aplikace navrženy správně, je nízká zátěž databáze, nebo je váš hardware moderní a velmi výkonný (dostatečný pro zvládnutí aktuálního počtu uživatelů a dat).

Nejcennější informací je zatížení transakcemi a akumulace verzí. To lze vidět pouze tehdy, pokud nastavíte pravidelné ukládání statistik.

InterBase nemá interní plánovač úloh, takže můžete použít jakýkoli externí, jako je standardní Plánovač úloh (Windows) nebo cron (Unix).

Nejlepší nastavení je získávat hodinové statistiky transakcí. To lze provést spuštěním

gstat -h db.gdb >db_stat_.txt

kde

db.gdb je název vaší databáze,

db_stat_.txt je textový soubor, kam budou statistiky uloženy,

- aktuální datum a čas, kdy byly statistiky pořízeny.

Pokud máte periodické problémy s výkonem

Tyto problémy jsou obvykle způsobeny automatickým spuštěním sweepu. Nejprve musíte určit časový interval mezi takovými výkonnostními poklesy. Poté tento interval minimálně rozdělte na 4 (8, 16 a tak dále). Informační systémy mají nyní mnoho souběžných uživatelů a většina problémů s výkonem u nenakonfigurovaného serveru a databáze nastává 2 nebo 3krát denně. Například pokud výkonnostní poklesy nastávají každé 3 hodiny, musíte pořizovat

gstat -h db.gdb

statistiky každých 30-45 minut a

gstat -a -r db.gdb -user SYSDBA -pass masterkey

každých 1-1,5 hodiny.

Nejlepší je pořídit statistiky gstat -a -r těsně před očekávaným výkonnostním poklesem. Ukáže, kde je skutečný garbage a kolik zastaralých verzí záznamů se nahromadilo.

Co dělat s těmito statistikami

Pokud vaše aplikace explicitně používá transakce a používá je dobře, tj. víte, co je read_committed a kdy jej použít, vaše snapshot transakce netrvají déle, než je nutné, a transakce jsou aktivní minimální dobu, můžete vyladit interval sweepu nebo jej vypnout a pak se starat pouze o to, kolik aktualizací aplikace provádějí a které tabulky je třeba méně aktualizovat nebo se o aktualizace starat.

Co to znamená, můžete se zeptat? Uvedeme příklad systému, kde docházelo k problémům s výkonem každé ráno po dobu 20-30 minut. To bylo velmi dostačující pro „ranní" aplikace a nemohlo to trvat déle.

Správce databáze byl dotázán na správné otázky a zde je obrázek:

Denní práce byla rozdělena na sekce - analytici pracují ráno, poté jsou data vkládána a upravována běžnými operátory a na konci dne spouštějí speciální procedury shromažďování dat, která budou použita pro analýzu další den (přinejmenším).

Poslední práce na databázi na konci dne byla spousta aktualizací a aktualizací těch tabulek, které analytici používali ráno. Takže tam bylo mnoho garbage verzí, které začala shromažďovat aplikace běžící ráno.

A řešení tohoto problému bylo nalezeno jednoduše - spustit gfix -sweep na konci dne.

Sweep přečte všechny tabulky v databázi a pokusí se shromáždit všechny garbage verze pro potvrzené a vrácené transakce. Po sweepu se databáze vyčistí téměř jako po obnově.

A „ranní problém" zmizel.

Takže musíte zvážit statistiky s mnoha dalšími faktory:

kolik souběžných uživatelů (průměrně) pracuje během dne
jak dlouhý je pracovní den (8, 12, 16, 24 hodin)
jaké druhy aplikací běží v různých denních dobách a jak ovlivňují data používaná jinými aplikacemi, běžícími ve stejnou dobu nebo další den. To znamená, že musíte rozumět obchodním procesům probíhajícím během celého dne a celého týdne.

Když DBA nemůže udělat nic

Bohužel, tyto situace nastávají. A opět příklad:

Některý systém nainstalovaný pro ~15 uživatelů. Periodicky je výkon tak špatný, že DBA musí restartovat server. Po restartu serveru vše funguje nějakou dobu dobře, pak se výkon opět zhorší. Statistiky ukázaly, že průměrný denní počet transakcí je asi 75 000 a že existují aktivní transakce běžící od začátku dne až do okamžiku, kdy výkon klesne.

Bohužel, aplikace byly napsány s BDE a bez použití transakcí vůbec; tj. veškeré zpracování transakcí bylo automatické a používané samotným BDE. To způsobilo, že některé transakce zůstaly aktivní po dlouhou dobu a garbage (verze záznamů) se hromadil, dokud DBA nerestartoval server. Po restartu se spustil automatický sweep a garbage byl shromážděn (eliminován).

To vše bylo způsobeno aplikacemi, protože byly testovány pouze s 2-3 souběžnými uživateli, a když jich bylo ~15, aplikace začaly vytvářet velmi vysokou zátěž.

Je třeba říci, že v této konfiguraci 70% uživatelů pouze četlo data a dalších 30% vkládalo a upravovalo některá (!) data.

V této situaci je jediná věc, která může zlepšit výkon, kompletní přepracování aplikací.

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