Firebird lassulás - folyamatos update ugyanarra a rekordra

(Találkoztam olyan esettel, hogy a fejlesztő kolléga aktív tranzakcióként production adatbázison hagyott egy select-et, majd napokkal később az ügyfél telefonált, hogy nem érti miért, ilyen még nem volt, de lassul a rendszere, nézzünk már rá. A tranzakció lezárásával gyorsan helyreállt a régi rend. Firebird 2.5 alatt javaslom a mon$transaction táblában kutakodást, nagyon szépen meg lehet találni a régi, de még aktív tranzakciókat, amik a lassulást okozhatják.
Sajnos nincsenek már meg, hogy ebben az esetben a nyitva maradt aktív tranzakció számához képest a TIP hogy állt, így csak becslésekbe tudok bocsátkozni. Úgy tippelem, hogy 90-100k tranzakció után következhetett be a lassulás, de ez nyilván csak attól függ, hogy milyen műveletek történnek ezeken a tranzakciókon, mennyire voltak adatmanipulálók, és mennyire csak lekérdezők.)

A fenti, gondos tranzakció tervezés mellett is találkoztam egy olyan esettel, ami lassulást okozott.
Ha egy rekordon sok-sok update fut, miközben ezek rekordverziókat gyártanak (mert nincs commit az update-ek közt, vagy van, de van olyan nem read only read commited tranzakció, ami megköveteli a verziózást), és ezeket a rekordverziókat figyelembe vevő select-ek futnak, akkor a firebird az alap rekordból kiindulva, követve a rekordverziókat minden selectnél a rekordra vonatkozóan VÉGIGOLVASSA az összes megelőző változatot. Ráadásul, ha a sok update azt okozza, hogy a módosulások másik adatlapra kerülnek, akkor ennek további lassulás lesz az eredménye (erről a 70%-30%-os tárolásról a hivatkozott fórum bejegyzésben írtam.)

Készítettem egy teszt alkalmazást egy nagyobb adatbázison, ami a következőt teszi:
- egy milliós tábla egyetlen rekordjának egyetlen mezőjét update-eli 3000x (különböző értékekre, mert az FB figyeli, hogy történt-e változás és csak akkor készít rekordverziót, ha igen!)
- a táblán egy trigger egy másik tábla egy rekordjából kiolvassa, hogy hány módosulás volt eddig az eredeti tábla rekordjaira. A kiolvasott értéket megnöveli eggyel és update-eli a segédtábla érintett rekordját
Ebben a tesztben két tábla két mezője folyamatosan változik, és a segédtábla mezőjét még ráadásul mindig újra és újra ki is olvassa a motor. Ez utóbbi fogja a lassulást okozni.
Íme egy táblázat, amely megmutatja, hogy 3000 ismétlődő update esetén milyen sebességlassulás következhet be:

Count

Egy műveletre jutó idő

101

1,36367801980198E-08

501

5,59760109780439E-08

1001

1,8258362008362E-07

1501

3,89902102302169E-07

2001

6,78133155644398E-07

2501

1,0472107453315E-06

3000

1,49621141975309E-06

Látható tehát, hogy a 3000. update már 2 nagyságrenddel lassabban fut le, mint az első!

Összefoglalva: lehetőleg kerüljük az azonos rekordra történő masszív update-eket egy tranzakción belül, mert jelentős lassulást okozhat még egy tranzakciós környezet esetén is, nem beszélve a többfelhasználós (több aktív tranzakciós) használatról.

Nem tudom, hogy LMoon-éknál ez volt-e a lassulás oka, de ha már többen érdeklődtek, gondoltam leírom egy kicsit a tapasztalatomat a firebird tranzakciókkal kapcsolatban. Remélem hasznos post lett belőle. :)

Közben eszembe jutott még valami, amivel gondok lehetnek. Hyper Threadinges processzoroknál a HT-t ajánlott kikapcsolni. Bár, amikor mi először belefutottunk, és túrtuk a netet, akkor egységesen azt írták, hogy adatbázis szerverekben kimondottan ajánlott kikapcsolni a HT-t, mert a megosztott cache folyamatos ürítése extrémül lassít. (Nem tudom, hogy ez valóban általános, vagy Firebird specifikus, azóta nem ajánlunk HT-s gépeket szervernek, és nincs vele gond.)