IBAnalyst: Hoe je op de juiste manier statistieken uit een InterBase/Firebird-database haalt

Dmitry Kuzmenko, laatste update 31-03-2014

Samenvatting

Dit document is gewijd aan tips en trucs voor het verzamelen en analyseren van statistieken van InterBase/Firebird-databases, met of zonder IBAnalyst.

Het juiste moment, de juiste plaats

Het klinkt vreemd, maar alleen het nemen van statistieken via gstat of de Services API is niet voldoende. Statistieken moeten op het juiste moment worden genomen om te laten zien hoe applicaties gegevens en transacties in de database beïnvloeden. Het slechtste moment om statistieken te nemen is

• Direct na een restore
• Na een backup (gbak -b db.gdb) zonder de -g schakelaar
• Na een handmatige sweep (gfix -sweep)

Het is ook juist dat er tijdens het werk momenten kunnen zijn waarop de database in een correcte staat verkeert, bijvoorbeeld wanneer applicaties minder databasebelasting veroorzaken dan normaal (gebruikers bij de start, lunchpauze of door specifieke bedrijfsprocestijden).

Hoe vang je momenten waarop er iets mis is met de database?

Ja, je applicaties kunnen zo perfect zijn ontworpen dat ze altijd correct met transacties en gegevens werken, zonder sweep-gaten, veel actieve transacties, langlopende snapshots en dergelijke te veroorzaken. Meestal gebeurt dit niet. Tenminste omdat sommige ontwikkelaars hun applicaties testen met 2-3 gelijktijdige gebruikers, niet meer. Dus, wanneer ze geschreven applicaties opzetten voor 15 of meer gelijktijdige gebruikers, kan de database zich onvoorspelbaar gedragen. Natuurlijk kan de multiuser-modus goed werken, omdat de meeste multiuser-conflicten kunnen worden getest met 2-3 gelijktijdig draaiende applicaties. Maar, vervolgens, wanneer er meer gelijktijdige applicaties draaien, kunnen er (op zijn minst) problemen met garbage collection ontstaan. En dit kan worden opgemerkt als je statistieken op de juiste momenten neemt.

Als je geen periodieke prestatieproblemen ervaart

Dit kan gebeuren wanneer je applicaties correct zijn ontworpen, er een lage databasebelasting is, of je hardware modern en zeer krachtig is (voldoende om het huidige aantal gebruikers en gegevens goed aan te kunnen).

De meest waardevolle informatie is transactiebelasting en versieaccumulatie. Dit kan alleen worden gezien als je regelmatig statistieken opslaat.

InterBase heeft geen interne taakplanner, dus je bent vrij om elke externe te gebruiken, zoals de standaard Taakplanner (Windows) of cron (Unix).

De beste opzet is om elk uur transactiestatistieken te verkrijgen. Dit kan worden gedaan door het uitvoeren van

gstat -h db.gdb >db_stat_.txt

waarbij

db.gdb de naam van je database is,

db_stat_.txt het tekstbestand is waar de statistieken worden opgeslagen,

- de huidige datum en tijd waarop de statistieken zijn genomen.

Als je periodieke prestatieproblemen ervaart

Deze problemen worden meestal veroorzaakt door een automatische sweep-run. Eerst moet je de tijdsperiode tussen dergelijke prestatiehits bepalen. Verdeel dit interval vervolgens minimaal door 4 (8, 16 enzovoort). Informatiesystemen hebben nu veel gelijktijdige gebruikers, en de meeste prestatieproblemen met een niet-geconfigureerde server en database gebeuren 2 of 3 keer per dag. Bijvoorbeeld, als prestatiehits elke 3 uur gebeuren, moet je

gstat -h db.gdb

statistieken elke 30-45 minuten nemen, en

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

elke 1-1,5 uur.

Het beste is om gstat -a -r statistieken te nemen vlak voordat de komende prestatiehit plaatsvindt. Het zal laten zien waar de echte garbage is en hoeveel verouderde recordversies zijn geaccumuleerd.

Wat te doen met deze statistieken

Als je applicatie expliciet transacties gebruikt en ze goed gebruikt, d.w.z. je weet wat read_committed is en wanneer je het moet gebruiken, je snapshot-transacties niet langer duren dan nodig, en transacties een minimale duur actief zijn, kun je het sweep-interval afstemmen of uitschakelen, en je vervolgens alleen zorgen maken over hoeveel updates de applicatie(s) maakt en welke tabellen minder moeten worden bijgewerkt of aandacht nodig hebben voor updates.

Wat betekent dit, kun je vragen? We geven een voorbeeld van een systeem waar prestatieproblemen elke ochtend 20-30 minuten duurden. Dat was zeer voldoende voor “ochtend” applicaties, en kon niet langer duren.

De databasebeheerder werd de juiste vragen gesteld, en hier is het beeld:

Het dagelijkse werk was verdeeld in secties - analisten werken in de ochtend, daarna worden gegevens ingevoegd en bewerkt door gewone operators, en aan het einde van de dag startten speciale procedures met het verzamelen van gegevens die de volgende dag (op zijn minst) voor analisten zouden worden gebruikt.

Het laatste werk aan de database aan het einde van de dag bestond uit veel updates, en updates van die tabellen die analisten in de ochtend gebruikten. Dus waren er veel garbage-versies, die werden verzameld door de applicatie die in de ochtend draaide.

En het antwoord op dat probleem was eenvoudig gevonden - om gfix -sweep aan het einde van de dag uit te voeren.

Sweep leest alle tabellen in de database en probeert alle garbage-versies te verzamelen voor vastgelegde en teruggedraaide transacties. Na het sweepen werd de database bijna zo schoon als na een restore.

En het “ochtendprobleem” was verdwenen.

Dus moet je statistieken overwegen met veel andere factoren:

1. hoeveel gelijktijdige gebruikers (gemiddeld) werken tijdens de dag

2. hoe lang is de werkdag (8, 12, 16, 24 uur)

3. wat voor soort applicaties draaien op verschillende tijdstippen van de dag, en hoe beïnvloeden ze gegevens die worden gebruikt door andere applicaties, die tegelijkertijd of de volgende dag draaien. D.w.z. je moet de bedrijfsprocessen begrijpen die gedurende de hele dag en de hele week plaatsvinden.

Wanneer de DBA niets kan doen

Helaas moeten we zeggen dat deze situaties voorkomen. En nogmaals, een voorbeeld:

Een systeem geïnstalleerd voor ~15 gebruikers. Periodiek is de prestatie zo slecht dat de DBA de server opnieuw moet starten. Na het herstarten van de server werkt alles een tijdje goed, daarna wordt de prestatie weer slecht. Statistieken toonden aan dat het gemiddelde dagelijkse aantal transacties ongeveer 75.000 is, en er zijn actieve transacties die lopen vanaf het begin van de dag tot het moment waarop de prestatie verslechtert.

Helaas waren de applicaties geschreven met BDE en zonder enig gebruik van transacties; d.w.z. alle transactieafhandeling was automatisch en werd door BDE zelf gebruikt. Dit veroorzaakte dat sommige transacties lang actief bleven, en garbage (recordversies) accumuleerde totdat de DBA de server opnieuw startte. Na het herstarten draaide de automatische sweep, en de garbage werd verzameld (geëlimineerd).

Dit alles werd veroorzaakt door de applicaties, omdat ze alleen werden getest met 2-3 gelijktijdige gebruikers, en toen ze ~15 werden, begonnen de applicaties een zeer hoge belasting te veroorzaken.

Moet worden gezegd dat in die configuratie 70% van de gebruikers alleen gegevens las, en de andere 30% voegde gegevens in en werkte sommige (!) gegevens bij.

In deze situatie is het enige dat de prestatie kan verbeteren het volledig herontwerpen van de applicaties.

Nog vragen? Stel ze ons op [email protected]