IBAnalyst: wat je kunt zien in de Summary View

Dmitry Kuzmenko, laatste update 31-03-2014

Samenvatting

Dit document is gewijd aan de uitleg van informatie op de “Samenvattingsweergave”-pagina van IBAnalyst, en hoe u deze informatie kunt interpreteren voor uw eigen databasestatistieken. Ook hebben we verschillende voorbeelden van statistieken aan het installatiepakket toegevoegd om u te helpen alle fijne kneepjes van InterBase-statistieken te bestuderen. Deze bevinden zich in de map Voorbeelden van de IBAnalyst-installatie.

Als u niet weet wat Oudste transactie, Oudste snapshot, actief en Volgende is, lees dan eerst Craig Stunz’s artikel “Understanding Transactions Lifetime”:

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

Transactienummers

Als u het artikel Understanding Transaction Lifetimes heeft gelezen, heeft u misschien nog vragen over OIT/OST/OAT-nummers. Hier is een korte beschrijving:


Nummer	Blijft staan, …	Gaat vooruit, …
Oudste transactie	wanneer een transactie met dit nummer werd teruggedraaid en er veel gegevenswijzigingen in zaten, of wanneer de clientverbinding verloren ging	wanneer automatische of handmatige sweep slaagt.
Oudste snapshot	wanneer een snapshot (of read committed write vóór IB 7.1) lange tijd actief is (het onthield de oudste actieve snapshot als zijn lokale OST)	wanneer een nieuwe transactie start, als de transactie die OST vasthoudt is beëindigd
Oudste actieve	wanneer een transactie met dit nummer lange tijd actief is	wanneer een nieuwe transactie start, als de transactie die OAT vasthoudt is beëindigd
Volgende	nooit	wanneer een nieuwe transactie start

opmerking: Oudste transactie hier is hetzelfde als Oudste Interessante Transactie (OIT), genoemd in veel andere artikelen.

Fijne statistieken met standaardinstellingen

Laten we IBAnalyst starten en het bestand !allok.txt openen (met Statistieken/Statistieken uit bestand laden menu).

IBAnalyst rapporteert niet alleen de aanmaakdatum van de database, maar herkent ook de huidige datum/tijd op de server als de statistieken via Services API zijn genomen, of de bestandsdatum/tijd als het een geladen statistiekenbestand is.

Daarom raden we aan om statistiekenbestanden niet te wijzigen, omdat IBAnalyst in dat geval de gemiddelde transacties per dag onjuist zal berekenen. De rij Transacties per dag toont hier ongeveer ~12500 transacties per dag en dat de database vanaf de aanmaak of het herstel 8 dagen “leeft”.

Oudste, Oudste snapshot, Oudste actieve en Volgende transacties zijn hier in perfecte staat, we wensen u dat uw statistieken er altijd zo uitzien.

Veel actieve transacties

Open vervolgens het bestand !lotofactive.txt (u kunt op elk moment terugkijken naar de !allok-afbeelding om de volgende voorbeelden ermee te vergelijken).

Hier is de rij Actieve transacties rood gemarkeerd, omdat er een groot verschil is tussen Oudste actieve en Volgende transactie. Dit betekent dat sommige transacties op het moment dat de statistieken werden genomen nog actief waren, en dat er na de start ervan al 55.000 transacties zijn gestart (ze kunnen in elke staat zijn - actief, vastgelegd, teruggedraaid). Aangezien het aantal gemiddelde transacties per dag ~12500 is, toont IBAnalyst u een waarschuwing dat sommige transacties al 4,4 dagen leven. Dit kan gebeuren wanneer:

sommige applicaties nog draaien en ten minste één transactie open hebben - sommige gebruikers laten de applicatie mogelijk lange tijd draaien
applicaties lange tijd draaien en transactiehandles verliezen - d.w.z. uw code (of componenten/bibliotheken die u gebruikt) start dynamisch transacties en “vergeet” onder bepaalde omstandigheden om ze te beëindigen met rollback of commit.
uw applicatie geen expliciete transacties gebruikt (BDE), waardoor transactieafhandeling wordt overgelaten aan de gebruikte componenten. Als gevolg hiervan worden transactielifetimes niet door de applicatie gecontroleerd en kunt u er zeker van zijn dat de meeste Next-OAT-transacties echt actief zijn.
uw applicatie een driver of componenten gebruikt die een “standaardtransactie” toestaan. Als uw code deze transactie niet controleert, kan deze zeer lang draaien.

Helaas tonen statistieken niet het werkelijke aantal momenteel actieve transacties. Dit kan alleen worden bekeken in InterBase 7.x met IBConsole, IB Performance Monitor of via een directe query op de tijdelijke systeemtabellen tmp$transactions. In Firebird 1.5 kunt u isc_database_info aanroepen met de parameter isc_info_active_transactions.

Sweeping

Laten we nu !needsweep.txt openen.

Sweep is een onderhoudsproces binnen InterBase. Sweep doorloopt alle records in de database en probeert alle garbage-versies op te schonen, en probeert vervolgens het Oudste transactienummer omhoog te verplaatsen. In een nieuw aangemaakte database is het Sweep-interval standaard 20000. Wanneer het verschil tussen transacties (zie onderstaande tabel) groter wordt dan het sweep-interval, wordt sweep automatisch uitgevoerd. Zo kunt u periodieke prestatievermindering op uw database zien. Bijvoorbeeld: uw applicaties werken maandag en dinsdag goed, maar woensdag melden gebruikers prestatieproblemen gedurende enkele uren, en daarna wordt de prestatie weer normaal.

Als u soortgelijk gedrag ziet - dan is het automatische sweeping.


Serverversie	Wanneer sweep wordt uitgevoerd
InterBase 7.x	(Oudste actieve - Oudste) > Sweep-interval
InterBase 4.x, 5.x, 6.x, Firebird vóór 1.5.2, Yaffil	(Oudste snapshot - Oudste) > Sweep-interval

Tabel 1. Voorwaarden waaronder automatische sweep wordt uitgevoerd

opmerking: IBAnalyst toont automatisch de juiste Sweep-gap-informatie voor alle versies. IBAnalyst kan het verschil tussen serverimplementaties alleen detecteren via ODS-id, bijvoorbeeld InterBase 7.x heeft ODS 11.x, andere moderne servers hebben ODS 10.x. Als u alleen met InterBase 7.x-databases (ODS 11) werkt, kunt u de betreffende optie in het Opties-dialoogvenster inschakelen.

Wanneer uw database een sweep-interval <> 0 heeft, markeert IBAnalyst deze rij in principe geel (waarschuwing dat automatische sweep op elk onvoorspelbaar moment kan starten). Over het algemeen hebben 60% van alle applicaties problemen met automatische sweeping. De eenvoudigste manier om dit probleem te voorkomen is het instellen van het sweep-interval op 0, wat leidt tot het uitschakelen van automatische sweeping. Maar als sommige applicaties veel wijzigingen maken en vervolgens terugdraaien, zal de Oudste transactie bevriezen en niet omhoog gaan totdat sweep wordt uitgevoerd. Aangezien de effectieve transactiestatus wordt berekend van Oudste tot Volgende transactie, zal deze afstand groeien en zal de prestatie dalen. Om dit te voorkomen, moet u sweep handmatig uitvoeren (gfix -sweep). Op deze afbeelding ziet u het gedrag wanneer het sweep-interval 0 is en er een grote transactie is teruggedraaid:

Hier toont de Sweep-gap-waarde dat sommige grote (met veel wijzigingen) transacties ongeveer 4,5 dagen geleden zijn teruggedraaid. We raden aan om sweep elke dag handmatig uit te voeren.

Natuurlijk is het voor die genoemde 60% applicaties misschien beter om het sweep-interval groter of kleiner dan 20000 in te stellen, maar dit hangt af van vele factoren (dagelijkse transacties is bijvoorbeeld één van deze factoren) en kan alleen experimenteel worden begrepen. Dus als u Sweep-interval op 0 instelt, kunt u er zeker van zijn dat sweep niet automatisch op een onvoorspelbaar moment wordt uitgevoerd.

Hetzelfde beeld kunt u zien voor het bestand !rollback.txt.

opmerking: Als sweep automatisch wordt uitgevoerd, kunnen voor een grote database of een database met veel garbage-recordversies Snapshot-, Actieve- en Volgende-transacties vooruitgaan terwijl sweep werkt, en kan sweep opnieuw starten bij de dichtstbijzijnde transactiestart.

Wanneer sweep zijn werk niet kan doen

Er zijn veel gevallen waarin sweep de Oudste transactie niet hoger kan verplaatsen. Natuurlijk probeert sweep eerst zijn werk te doen, d.w.z. alle records in de database controleren en onnodige recordversies verzamelen. Maar het zal keer op keer zonder succes worden uitgevoerd als

er een probleem was tijdens het uitvoeren van sweep: de server werd gestopt tijdens sweep, of er was een fout tijdens het opschonen van garbage-recordversies. Bovendien kunt u dit beeld zien wanneer:

statistieken werden genomen terwijl sweep werkte
sweep draait en probeert garbage te verzamelen voor een tabel die constant wordt bijgewerkt. Dit kan duren totdat de updates eindigen.
sweep vastloopt op paginasloten, omdat er veel gebruikers met gegevens werken.

Over het algemeen heeft sweep geen kans om te eindigen tijdens hoge databasebelasting. Meestal herstart de DBA de server wanneer de prestatie zodanig verslechtert dat normaal werk onmogelijk wordt, en sweep wordt uitgevoerd bij de eerste gebruikersverbinding. Omdat er enige tijd zal zijn terwijl andere gebruikers verbinding maken, zal sweep tijd hebben om zijn werk af te maken.

Aangezien InterBase 7.1/7.5 de Sweep-gap anders berekent dan eerdere versies, is de andere situatie waarin sweep zijn werk niet kan doen wanneer sommige applicaties een langlopende snapshot-transactie hebben:

Hier zijn twee waarschuwingen - één (geel) over langlopende snapshot, en andere (rood) over Sweep-interval en Sweep-gap.

Langlopende snapshot

De vorige afbeelding duidt een langlopende snapshot aan in InterBase 7.1/7.5. Als Sweep-interval op 0 was ingesteld, zouden er geen rode waarschuwingen zijn, alleen geel. Een soortgelijk beeld duidt een langlopende snapshot-transactie aan in andere InterBase-, Firebird- en Yaffil-versies:

Zoals u hier ziet, wordt Sweep-gap berekend door het verschil tussen Oudste snapshot en Oudste transactie (voor ODS 10, pre-IB7.x-versies). Er is dus geen sweep-waarschuwing (behalve het standaard sweep-interval).

Maar niet alleen snapshot-transacties beïnvloeden de transactiestatus op deze manier. Alle InterBase-, Firebird- en Yaffil-versies behalve InterBase 7.1/7.5 hebben het volgende gedrag, dat we “read committed artefact” hebben genoemd.

Snapshots opnieuw en Wanneer ReadCommitted de Oudste snapshot bevriest

Open !snapshot2.txt:

Merk op dat de Oudste transactie groter is dan de Oudste snapshot. En Sweep-gap heeft een negatieve waarde. Dit kan in twee gevallen gebeuren. Het eerste geval is wanneer er enkele snapshot-transacties starten en de een na de ander worden vastgelegd. D.w.z. dit beeld kan met snapshots gebeuren, evenals het vorige beeld. Het volgende geval gebeurt alleen op servers anders dan IB 7.1/7.5 met ReadCommitted-transacties (of in combinatie van ReadCommitted- en Snapshot-transacties). Ze kunnen het Oudste snapshot-nummer op dezelfde manier vergrendelen als Snapshot-transacties doen. De huidige transactiestatus kan worden geëmuleerd met de volgende reeks

start transactie 1, snapshot of read_committed
start/leg enkele read_committed-transacties vast
start transactie 2, snapshot of read_committed
start/leg enkele read_committed-transacties vast
leg transactie 1 vast

(natuurlijk hebben we het hier over read_committed write-transacties, niet read-only).

Op dit punt zal de momenteel actieve transactie 2 (snapshot of read committed), gestart na snapshot 1 (stap 3), het snapshotnummer als Oudste snapshot vasthouden (als u met IB 7.1/7.5 werkt, kan dit alleen gebeuren voor gelijktijdige snapshot-transacties. read_committed of read_committed+snapshot zal dit effect niet produceren). Aangezien er geen grote rollbacks waren, gaat de Oudste transactie vooruit en wordt groter dan de Oudste snapshot.

Nu, als u een langlopende read committed-transactie heeft, zult u een beeld zoals dit zien. Helaas kunt u hier niets aan doen met uw applicaties (behalve het toevoegen van de parameter “read” voor read-only-transacties). En natuurlijk zal sweep in dit geval niet automatisch worden uitgevoerd (als het <> 0 is ingesteld).

opmerking: dit gedrag zal worden verholpen in Firebird 2.0

Absolute en relatieve weergaven

Standaard vult IBAnalyst transactierijen in volgens het percentage van hun absolute waarde. D.w.z. 100% is van 0 tot Volgende transactie. Soms, wanneer de database lange tijd werkt, kunt u transactie-informatie zien als

Terwijl er veel transacties zijn, lijkt het verschil tussen snapshot, actief en oudste zeer klein (dicht bij 98%). Om de situatie duidelijker te maken, opent u het Opties-dialoogvenster, tabblad Transacties, en vinkt u de optie “Relatieve (vanaf oudste) balken %” aan (u kunt dit selectievakje niet instellen als u de oude stijlweergave zonder grafiekbalken gebruikt). Na het indrukken van de OK-knop verandert de transactieweergave naar

Nu ziet u het transactieverschil in relatieve weergave (100% is van de oudste (of snapshot) transactie naar de volgende, niet vanaf 0). Het is gemakkelijker om de huidige situatie te begrijpen en waarschuwingen (indien aanwezig) te bekijken.

Deze weergave blijft actief totdat u deze uitschakelt via het dialoogvenster Opties. U kunt begrijpen welke weergave u ziet aan de rij Oudste transactie of Oudste snapshot - in relatieve weergave is een van deze rijen nooit gevuld met de kleur groen. In absolute weergave is deze altijd gevuld (gedeeltelijk, uiteraard).

Heeft u nog vragen? Stel ze ons via [email protected]