Misi blogja

Firebird lassulás - folyamatos update ugyanarra a rekordra

Ebben fórum bejegyzésben található egy alszál, amely arról szól, hogy LMoon kolléga találkozott a Firebird-del kapcsolatban egy olyan megmagyarázhatatlan lassulással, amely miatt át kellett írniuk az egész programot MySQL alapokra.

A lent leírt dolgok sok év FB fejlesztés és viszonylag testes adatbázisokon szerzett tapasztalatok alapján kristályosodtak ki.
Ha kisebb projektekben dolgozunk, akkor is érdemes figyelembe venni őket, hátha egyszer elérjük azt a műveleti és adatmennyiséget, ahol ez már probléma lehet.

Az FB tranzakció kezeléséről bővebben nem kívánnék most értekezni, de azt jó tudni, hogy minden induló tranzakció kap egy szigorúan monoton növekvő sorszámot (ezt tárolja az FB a Transaction Inventory Page-en (TIP)), és minden tranzakció, mindaddig, amíg commit(ez a preferált, erre van kihegyezve a motor)/vagy rollback nem lesz a vége aktív tranzakcióként rekordverziókat generál minden (más) tranzakción keletkező insert/update/delete művelettel kapcsolatban. Ezért javasolt minden olyan tranzakciót, amin csak adatlekérés van READ ONLY (read commited) módban indítani, mert ezek a tranzakciók nem gyártanak rekordverziókat. (A GTT táblák read only tranzakción is írhatóak!) Ha igazán ügyesen akarjuk szervezni a programunkat, akkor egy globális read only read commited tranzakcióra akasztjuk az összes lekérdező jellegű utasításunkat, és ezt a tranzakciót soha nem commitoljuk, ezzel is erőforrást megtakarítva (a tranzakció indítása is erőforrást vesz el szerver oldalon, még ha nem is sokat, ráadásul feleslegesen "pörgetjük" a TIP maximális értékét, ami előbb-utóbb a garbage collector elindítását eredményezi).
Az írási műveleteket végző tranzakciókat pedig a lehető leggyorsabban le kell zárni.
Ha így szervezzük a programunkat, akkor vélhetőleg nem lesz problémánk a rekordverziók miatti lassulással.
(Jó tudni, hogy a rekordverziók három módon szűnhetnek meg. Vagy egy őket olvasó select utasítás érzékelheti, hogy már nincs rájuk szükség, és takaríthatja ki őket (ezért lehet látszólag érthetetlen módon lassú egy select, ami másodszorra már pillanatok alatt lefut), vagy a garbage collector vagy egy gbak mentés fogja ezt megtenni. A gbak alapértelmezetten tehát takarít, ha azt szeretnénk, hogy a mentésünk minél előbb lefusson, akkor -g kapcsolóval indítsuk.)

Mindig van tanulság

Mindig van tanulságTegnap őseimnél kihalt a tűzfalból a tápegység. Nem is volt gond, gyors szervíz, kicserélték (régi darab volt szegénykém, van vagy 8 éves gép), de valahogy csak nem akar felkúszni a netre. Na ez szép munka, 200 km választ el a géptől, édesapám meg nem informatikusként jött a világra :)
Nagy levegőt vettünk és hajrá, telefon fel, fater root login, hibakeresés indul. :) Hát kiderül, hogy nem csak a táp, de a jó öreg ISA-s ne2000-es kártya számára is a tegnapi volt az utolsó nap.
Pechemre anno eth1-ként funkcionált, az ADSL meg ezen keresztül ment. Este nincs már bolt persze, új kártya csak ma reggel lett.
Fater hősiesen configolta a debiant telefonos segítséggel (na ez nem 30 mp-es volt, mint abban a bizonyos műsorban ;)), tűzfal, pppoe, így este már át tudtam nézni a gépet, hogy más baj nincs, csak fel kell cserélni még néhány fájlban az eth0/eth1 párost.