IBAnalyst: шта можете видети у приказу резимеа

Дмитриј Кузменко, последње ажурирање 31-03-2014

Апстракт

Овај документ је посвећен објашњењу информација на страници „Summary view“ у IBAnalyst-у и како тумачити те информације за статистику ваше базе података. Такође смо додали неколико примера статистике у инсталациони пакет како бисмо вам олакшали проучавање свих детаља InterBase статистике. Они се налазе у директоријуму Examples у инсталацији IBAnalyst-а.

Ако не знате шта су Oldest transaction, Oldest snapshot, active и Next, молимо вас да прво прочитате чланак Craig Stunz-а „Understanding Transactions Lifetime“:

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

Бројеви трансакција

Ако сте прочитали чланак Understanding Transaction Lifetimes, можда још увек имате питања о OIT/OST/OAT бројевима. Ево кратког описа:


Број	Држи, …	Помера се напред, …
Oldest transaction	када је трансакција са овим бројем враћена (rolled back) и било је много промена података у њој, или када је клијентска веза изгубљена	када аутоматско или ручно чишћење (sweep) успе.
Oldest Snapshot	када је snapshot (или read committed write пре IB 7.1) активан дуже време (запамтио је најстарији активни snapshot као свој локални OST)	када нова трансакција почне, ако је трансакција која држи OST завршена
Oldest Active	када је трансакција са овим бројем активна дуже време	када нова трансакција почне, ако је трансакција која држи OAT завршена
Next	никада	када нова трансакција почне

напомена: Oldest transaction овде је исто што и Oldest Interesting Transaction (OIT), поменут у многим другим чланцима.

Добра статистика са стандардним подешавањима

Покренимо IBAnalyst и отворимо (преко менија Statistics/Load statistics from file) датотеку !allok.txt.

IBAnalyst не само да пријављује датум креирања базе података, већ и препознаје тренутни датум и време на серверу ако је статистика узета преко Services API-ја, или датум датотеке ако је учитана статистичка датотека.

Зато предлажемо да не мењате статистичке датотеке, јер ће у том случају IBAnalyst погрешно израчунати просечан број трансакција по дану. Ред „Transactions per day“ овде показује око ~12500 трансакција по дану и да база података „живи“ од свог креирања или рестаурације 8 дана.

Oldest, Oldest snapshot, Oldest active и Next трансакције су овде у савршеном стању; желимо вам да статистика увек изгледа овако.

Много активних трансакција

Затим отворите датотеку !lotofactive.txt (можете се у било ком тренутку вратити на слику !allok да бисте упоредили следеће примере са њом).

Овде је ред Active transactions означен црвеном бојом, јер постоји велика разлика између Oldest active и Next трансакције. То значи да је нека трансакција у тренутку када је статистика узета још увек активна, и након њеног почетка већ је покренуто 55.000 трансакција (оне могу бити у било ком стању - активне, потврђене, враћене). Пошто је број просечних трансакција по дану ~12500, IBAnalyst вам показује упозорење да нека трансакција још увек траје 4,4 дана. Ово се може десити када:

нека апликација још увек ради и има бар једну отворену трансакцију - неки корисник можда држи апликацију укључену дуже време
апликација ради дуже време и губи ручке трансакција - тј. ваш код (или компоненте/библиотеке које користите) динамички покреће трансакције и у неким околностима „заборавља“ да их заврши са rollback или commit.
ваша апликација не користи експлицитне трансакције (BDE), препуштајући управљање трансакцијама компонентама које се користе. Као резултат, животни век трансакција није контролисан од стране апликације, и можете бити сигурни да је већина Next-OAT трансакција заиста активна.
ваша апликација користи драјвер или компоненте које омогућавају „подразумевану трансакцију“. Ако ваш код не контролише ову трансакцију, она може трајати веома дуго.

Нажалост, статистика не показује стварни број тренутно активних трансакција. То се може видети само у InterBase 7.x помоћу IBConsole, IB Performance Monitor-а или директним упитом на привремену системску табелу tmp$transactions. У Firebird 1.5 можете позвати isc_database_info са параметром isc_info_active_transactions.

Чишћење (Sweeping)

Сада отворимо !needsweep.txt.

Sweep је процес одржавања унутар InterBase-а. Sweep пролази кроз све записе у бази података и покушава да очисти све непотребне верзије записа, а затим покушава да помери број Oldest transaction навише. У новокреираној бази података, интервал чишћења је подразумевано 20000. Када разлика између трансакција (видети табелу испод) постане већа од интервала чишћења, sweep ће се покренути аутоматски. Тако можете приметити периодично опадање перформанси на вашој бази података. На пример, ваше апликације раде добро током понедељка и уторка, али у среду корисници пријављују проблеме са перформансама током неколико сати, а затим се перформансе поново враћају у нормалу.

Ако видите слично понашање - то је аутоматско чишћење.


Верзија сервера	Када се sweep покреће
InterBase 7.x	(Oldest Active - Oldest) > Sweep interval
InterBase 4.x, 5.x, 6.x, Firebird пре 1.5.2, Yaffil	(Oldest Snapshot - Oldest) > Sweep interval

Табела 1. Услови када се аутоматско чишћење покреће

напомена: IBAnalyst аутоматски приказује исправне информације о Sweep gap-у за све верзије. IBAnalyst може да разликује имплементације сервера само по ODS ID-ју, на пример, InterBase 7.x има ODS 11.x, док други савремени сервери имају ODS 10.x. Ако радите само са InterBase 7.x базама података (ODS 11), можете укључити одговарајућу опцију у дијалогу Options.

Када ваша база података има sweep interval <> 0, IBAnalyst углавном означава овај ред жутом бојом (упозоравајући вас да аутоматско чишћење може почети у било ком непредвидивом тренутку). Генерално, 60% свих апликација има проблема са аутоматским чишћењем. Најлакши начин да избегнете овај проблем је да поставите sweep interval на 0, што доводи до искључивања аутоматског чишћења. Али, ако нека апликација направи много промена, а затим их врати (rollback), Oldest transaction ће се замрзнути и неће се померити док се sweep не покрене. Пошто се ефективно стање трансакција израчунава од Oldest до Next трансакције, ова раздаљина ће расти и перформансе ће опасти. Да бисте то спречили, морате ручно покренути sweep (gfix -sweep). На овој слици можете видети понашање када је sweep interval 0 и када је велика трансакција враћена:

Овде вредност sweep gap показује да је нека велика (са много промена) трансакција враћена пре око 4,5 дана. Препоручујемо вам да ручно покрећете sweep сваког дана.

Наравно, за тих поменутих 60% апликација можда је боље поставити sweep interval већи или мањи од 20000, али то зависи од многих фактора (дневни број трансакција је један од тих фактора, на пример) и може се разумети само експерименталним путем. Дакле, ако поставите Sweep interval на 0, можете бити сигурни да се sweep неће аутоматски покренути у непредвидивом тренутку.

Исту слику можете видети за датотеку !rollback.txt.

напомена: Ако се sweep покреће аутоматски, за велику базу података или базу са много непотребних верзија записа, Snapshot, Active и Next трансакције могу се померити напред док sweep ради, и sweep може поново почети при следећем покретању трансакције.

Када sweep не може да обави свој посао

Постоји много случајева када sweep не може да помери Oldest transaction навише. Наравно, sweep прво покушава да обави свој посао, тј. провери све записе у бази података и прикупи непотребне верзије записа. Али ће се покретати изнова и изнова без успеха ако

је постојао неки проблем када је sweep покренут: сервер је заустављен током чишћења, или је дошло до грешке током чишћења непотребних верзија записа. Поред тога, ову слику можете видети када:

статистика је узета док sweep ради
sweep ради и покушава да прикупи непотребне верзије за табелу која се стално ажурира. Ово може трајати док се ажурирања не заврше.
sweep је заглављен на page locks, јер постоји много корисника који раде са подацима.

Уопштено, sweep нема шансе да заврши током високог оптерећења базе података. Обично када перформансе деградирају до немогућности наставка нормалног рада, DBA поново покреће сервер, и sweep се покреће при првом корисничком повезивању. Пошто ће проћи неко време док се остали корисници повежу, sweep ће имати времена да заврши свој посао.

Пошто InterBase 7.1/7.5 израчунава Sweep gap другачије од претходних верзија, друга ситуација када sweep не може да обави свој посао је када нека апликација има дуготрајну snapshot транскакцију:

Овде су два упозорења - једно (жуто) о дуготрајном snapshot-у, и друго (црвено) о Sweep интервалу и Sweep gap-у.

Дуготрајни snapshot

Претходна слика указује на дуготрајни snapshot у InterBase 7.1/7.5. Ако је Sweep интервал постављен на 0, не би било црвених упозорења, само жутих. Слична слика ће указати на дуготрајну snapshot транскакцију у другим InterBase, Firebird и Yaffil верзијама:

Као што видите овде, Sweep gap се израчунава на основу разлике између Oldest Snapshot и Oldest transaction (за ODS 10, пре-IB7.x верзије). Дакле, нема sweep упозорења (осим подразумеваног sweep интервала).

Али, не само snapshot транскакције утичу на стање транскакција на овај начин. Све InterBase, Firebird и Yaffil верзије осим InterBase 7.1/7.5 имају следеће понашање, које смо назвали “read committed artifact”.

Snapshots поново и када ReadCommitted замрзава Oldest Snapshot

Отворите !snapshot2.txt. :

Приметите да је Oldest transaction већи од Oldest snapshot. И Sweep gap има негативну вредност. Ово се може десити у два случаја. Први случај је када постоје неке snapshot транскакције које се покрећу и комитују једна за другом. Тј. ова слика се може десити са snapshots-има као и претходна слика. Следећи случај се дешава само на серверима који нису IB 7.1/7.5 са ReadCommitted транскакцијама (или у комбинацији ReadCommitted и Snapshot транскакција). Оне могу закључати Oldest Snapshot број на исти начин као што то раде Snapshot транскакције. Тренутно стање транскакција може се емулирати следећим редоследом

покрените транскакцију 1, snapshot или read_committed
покрените/комитујте неке read_committed транскакције
покрените транскакцију 2, snapshot или read_committed
покрените/комитујте неке read_committed транскакције
комитујте транскакцију 1

(наравно, овде говоримо о read_committed write транскакцијама, не read-only).

У овом тренутку, тренутно активна транскакција 2 (snapshot или read committed), покренута после snapshot-а 1 (ознака 3), ће држати snapshot број као Oldest Snapshot (ако радите са IB 7.1/7.5 ово се може десити само за конкурентне snapshot транскакције. read_committed или read_committed+snapshot неће произвести овај ефекат). Пошто није било великих rollback-ова, Oldest transaction се помера напред и постаје већи од Oldest Snapshot.

Сада, ако имате дуготрајну read committed транскакцију, видећете овакву слику. Нажалост, не можете ништа учинити овде са својим апликацијама (осим додавања “read” параметра за read-only транскакције). И наравно, sweep се неће аутоматски покренути (ако је постављен <> 0) у овом случају.

напомена: ово понашање ће бити исправљено у Firebird 2.0

Апсолутни и релативни прикази

Подразумевано, IBAnalyst попуњава редове транскакција према проценту њихове апсолутне вредности. Тј. 100% је од 0 до Next transaction. Понекад, када база података ради дуго времена, можете видети информације о транскакцијама као

Док постоји много транскакција, разлика између snapshot, active и oldest изгледа веома мала (близу 98%). Да бисте разјаснили ситуацију, отворите Options дијалог, Transactions картицу, и означите опцију “Relative (from oldest) bars %” (не можете означити ову кућицу ако користите стари стил приказа, без графичких трака). Након притиска на OK дугме, приказ транскакција ће се променити у

Сада видите разлику транскакција у релативном приказу (100% је од Oldest (или snapshot) транскакције до Next, не од 0). Лакше је разумети тренутну ситуацију и видети упозорења (ако их има).

Овај приказ ће остати док не поништите опцију у Options дијалогу. Можете разумети који приказ видите по Oldest Transaction или Oldest snapshot реду - у релативном приказу један од ових редова никада није попуњен зеленом бојом. У апсолутном приказу је увек попуњен (делимично, наравно).

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