IBAnalyst: Како на правилан начин добити статистику из InterBase/Firebird базе података

Dmitry Kuzmenko, последње ажурирање 31-03-2014

Апстракт

Овај документ је посвећен саветима и триковима за прикупљање и анализу статистике из InterBase/Firebird база података са или без IBAnalyst-а.

Право време, право место

Звучи чудно, али само узимање статистике преко gstat-а или Services API-ја није довољно. Статистика мора бити узета у правом тренутку да би показала како апликације утичу на податке и трансакције у бази података. Најгоре време за узимање статистике је

Одмах након ресторе-а
Након бекапа (gbak -b db.gdb) без -g прекидача
Након ручног sweep-а (gfix -sweep)

Такође је тачно да током рада могу постојати тренуци када је база података у исправном стању, на пример, када апликације праве мање оптерећење базе него обично (корисници на покретању, ручак или је то због специфичних пословних процеса).

Како ухватити када нешто није у реду у бази података?

Да, ваше апликације могу бити дизајниране тако савршено да ће увек радити са трансакцијама и подацима исправно, не правећи sweep празнине, много активних трансакција, дуготрајне snapshot-ове и тако даље. Обично се то не дешава. Барем зато што неки програмери тестирају своје апликације са 2-3 истовремена корисника, не више. Дакле, када поставе написане апликације за 15 и више истовремених корисника, база података може да се понаша непредвидиво. Наравно, мултикориснички режим може да ради добро, јер већина мултикорисничких конфликата може бити тестирана са 2-3 истовремено покренуте апликације. Али, затим, када ће више истовремених апликација радити, проблеми са garbage collection-ом могу да се појаве (барем). И то се може ухватити ако узмете статистику у правим тренуцима.

Ако не доживљавате периодичне проблеме са перформансама

Ово се може десити када су ваше апликације исправно дизајниране, постоји ниско оптерећење базе података, или је ваш хардвер модеран и веома моћан (довољан да добро поднесе тренутни број корисника и податке).

Највреднија информација је оптерећење трансакција и акумулација верзија. Ово се може видети само ако подесите редовно чување статистике.

InterBase нема интерни таск scheduler, тако да сте слободни да користите било који екстерни, као што је стандардни Task Scheduler (Windows) или cron (Unix).

Најбоље подешавање је да добијате сатну статистику трансакција. Ово се може урадити покретањем

gstat -h db.gdb >db_stat_.txt

где је

db.gdb име ваше базе података,

db_stat_.txt је текст фајл где ће статистика бити сачувана,

- тренутни датум и време када је статистика узета.

Ако доживљавате периодичне проблеме са перформансама

Ови проблеми обично су узроковани аутоматским sweep покретањем. Прво морате одредити временски период између таквих удараца на перформансе. Затим, поделите овај интервал минимално на 4 (8, 16 и тако даље). Сада информациони системи имају много истовремених корисника, и већина проблема са перформансама са неконфигурисаним сервером и базом података дешава се 2 или 3 пута дневно. На пример, ако се ударци на перформансе дешавају свака 3 сата, потребно је да узмете

gstat -h db.gdb

статистику сваких 30-45 минута, и

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

сваких 1-1.5 сат.

Најбоље је када узмете gstat -a -r статистику непосредно пре предстојећег ударца на перформансе. То ће показати где је прави garbage и колико је застарелих верзија записа акумулирано.

Шта радити са овом статистиком

Ако ваша апликација експлицитно користи трансакције и користи их добро, тј. знате шта је read_committed и када га користити, ваше snapshot трансакције не трају дуже него што је потребно, и трансакције су активне минимално време, можете подесити sweep интервал или га искључити, и онда се само бринути о томе колико ажурирања апликација(е) прави и које табеле треба мање ажурирати или се бринути о ажурирањима.

Шта то значи, можете питати? Даћемо пример неког система, где су се проблеми са перформансама дешавали свако јутро 20-30 минута. То је било веома довољно за “јутрање” апликације, и није могло трајати дуже.

Администратор базе података је постављен исправна питања, и ево слике:

Дневни рад је био подељен на секције - аналитичари раде ујутру, затим подаци се уносе и уређују од стране уобичајених оператера, и на крају дана специјалне процедуре почињу да прикупљају податке, који ће бити коришћени за аналитику следећег дана (барем).

Последњи рад на бази података на крају дана био је много ажурирања, и ажурирања оних табела које су аналитичари користили ујутру. Дакле, било је много garbage верзија, које је почела да прикупља апликација, која ради ујутру.

И, одговор на тај проблем је пронађен једноставно - покренути gfix -sweep на крају дана.

Sweep чита све табеле у бази података и покушава да прикупи све garbage верзије за комитоване и ролловане трансакције. Након sweep-а база података је постала скоро чиста као што је након ресторе-а.

И, “јутрањи проблем” је нестао.

Дакле, потребно је размотрити статистику са много других фактора:

колико истовремених корисника (просечно) ради током дана
колико је дуг радни дан (8, 12, 16, 24 сата)
какве апликације раде у различитим деловима дана, и како утичу на податке које користе друге апликације, које раде у исто време или следеће. Тј. морате разумети пословне процесе који се дешавају током целог дана и целе недеље.

Када DBA не може ништа да уради

Нажалост, ове ситуације се дешавају. И опет, пример:

Неки систем инсталиран за ~15 корисника. Периодично перформансе су толико лоше, да DBA мора да рестартује сервер. Након рестарта сервера све ради добро неко време, затим перформансе опет постају лоше. Статистика је показала да је просечан дневни број трансакција око 75,000, и постоје активне трансакције које раде од почетка дана до тренутка када перформансе опадају.

Нажалост, апликације су написане са BDE и без икаквог коришћења трансакција; тј. све управљање трансакцијама је било аутоматско и коришћено од стране BDE-а. То је узроковало да неке трансакције остану активне дуго времена, и garbage (верзије записа) се акумулирао док DBA није рестартовао сервер. Након рестарта аутоматски sweep је покренут, и garbage је постао прикупљен (елиминисан).

Све ово је узроковано апликацијама, јер су тестиране само са 2-3 истовремена корисника, и када их је постало ~15, апликације су почеле да праве веома високо оптерећење.

Треба рећи да је у тој конфигурацији 70% корисника само читало податке, а других 30% је уносило и ажурирало неке (!) податке.

У овој ситуацији једина ствар која може побољшати перформансе је потпуно редизајнирање апликација.

Још увек имате питања? Питајте нас на [email protected]