Kapcsolódó információk:
› Paraméterezési útmutatók

Az itt leírt esetekből szerzett tapasztalatainkat nagyrészt a Firebird SQL 2-es verzióinak üzemeltetése során szereztük.

Bevezetés

A dokumentációban szereplő hibák, valamint azok megoldási javaslatai egy-egy konkrét, megtörtént, valós esethez köthetők. Ez okból irányadóak lehetnek egy-egy felmerülő probléma orvoslása során, azonban a részletes hadware- és software-környezet ismerete nélkül e megoldási javaslatok is csak korlátozott segítséget biztosítanak.

Partnereink, valamint saját tapasztalataink alapján törekszünk a felmerülő problémák okát pontosan felderíteni, viszont erre sok esetben - tekintve az éles üzemben lévő szervereket, összetett vagy éppen speciális környezetet - nincs mindig lehetőségünk. Ezért a leírt megoldások esetenként csak egy kerülő megoldást jelentenek, vagy sajnos hatástalanok az infrastrukturális különbségek miatt.

 
A új tapasztalatainkkal folyamatosan bővítjük e dokumentumot.

 

Javasolt, bármilyen - e dokumentumban leírt -  módosítás végrehajtása előtt, e leírás részletes áttekintése, tanulmányozása!

Telepítési hibák megelőzése érdekében javasolt az Adatbázis szerver telepítése a SUP rendszerhez dokumentáció részletes áttekintése!

A problémák nagy hányadára az alábbi irányelvek vizsgálata megoldást jelenthet

  • Elegendő operatív memória áll-e a Firebird processz rendelkezésére?
  • Van-e szabad processzor idő a Firebird processz számára?
  • Megfelelő-e a HDD írási sebessége (HDD fizikai hiba, Cache hiba, RAID vezérlő driver)
  • Hálózati kommunikációt lassítja-e valami (fizikai hiba, hálózati kártya driver, másik processz)
  • Virtualizáció esetén a virtualizált harware-ek összehangolása (Vmware-Tools telepítése, lehetőség szerint nem Legacy driver használata)

Windows SBS szerven

Microsoft SBS szerver licenc esetén a Firebird SQL szerver teljesítmény problémája mutatkozhat.

Több okai is lehet:

  • Ha az adatbázis rendszerterületen van, akkor - a rendszer írási cache kikapcsolt állapota miatt - az adatbázis írás lassulhat. Lehetőség szerint, át kell tenni az adatbázist nem rendszermeghajtóra.
    Don't put databases to the same HDD/RAID where SBS Windows server is installed because it has write cache disabled (and you cannot enable it).

      

  • Ha a Primary Domain Controller (PDC) szolgáltatás aktív, annak jelentős erőforrás igénye miatt teljesítményproblémák adódhatnak. A Microsoft ajánlása szerint pl. az alkalmazás szervert el kell választani a PDC-től, legalább virtualizációval, de inkább fizikailag. (Persze ilyen esetben azt az operációs rendszert nem SBS licenszel kell telepíteni) Amennyiben nem megoldható a Firebird szerver nem SBS licenszű operációs rendszerre való telepítése, akkor érdemes próbálkozni a Firebird Classic Server változatának telepítésével.

Windows operációs rendszer cseréje R2-es változatra

Windows 2008 R2 és Windows 2003 R2 operációs rendszerek esetén jelentkezhet a probléma, hogy ugyanazok a funkciók, melyek az egy kiadással régebbi Windows verziók esetén kitűnő sebességgel működtek, az R2 operációs rendszer verziók esetén kimondottan lassúak.

A probléma konkrét oka jelenleg nem ismert. Nem tudjuk, mit tett a Microsoft az R2-es kiadású szerver verziókba, amitől romlott a Firebird teljesítménye.

Probléma megoldása (tüneti kezelése)

A valódi megoldás nem ismert jelenleg. A következőket célszerű ellenőrizni.

  • A Firebird adatbázisok lehetőleg ne a C:\ meghajtóra legyenek telepítve, mivel az újabb Windows verzióban a C:\ meghajtón nincs engedélyezve az "Írási gyorsítótár" (writeback cache).
    Példa: Windows 7 esetén, beállítás a következőképp:
    • A számítógép merevlemez meghajtóit nézve - JobbKlikk | Tulajdonságok | Hardver adatlap | Lemezmeghajtó kiválasztása | [Tulajdonságok] gomb | Házirendek adatlap | "Írási gyorsítótárazás engedélyezése az eszközön".
      Ez a tulajdonság alapbeállítás, tehát normál esetben be van kapcsolva.

  • A Firebird-nek van saját opciója is az "Írási gyorsítótár" (writeback cache) kezelésére. Mivel a Windows gyorsítótár alapesetben be van kapcsolva, ezért a Qsoft által létrehozott SUP-os adatbázisok esetén ez alapesetben ki van kapcsolva.
    Az opció kapcsolgatása adatbázisonként a GFIX utility-vel, ill. a DBX segédprogrammal lehetséges.
    Szintaxis:
        FB gyorsítótárazás bekapcsolása pl.:
          C:\Program Files\Firebird2\bin\GFIX.EXE -user SYSDBA -pass masterkey -write async serverneve:meghajto:\adatbazis\eleresi\ut\FB2_CegDbFile.fdb
        FB gyorsítótárazás kikapcsolás pl.:
          C:\Program Files\Firebird2\bin\GFIX.EXE -user SYSDBA -pass masterkey -write sync serverneve:/adatbazis/Eleresi/UT/FB2_CegDbFile.fdb

Az adatbázis írási gyorsítótár bekapcsolása, megfelelő kiegészítő védelmek nélkül ( szünetmentes tápegység, és ehhez kapcsolódó automatizált szerverleállítási szolgáltatás) adatvesztéshez vezethet.

Az aktuális adatbázis írási cache beállítása a SUP rendszerben a Szerviz | Technikai funkciók | Rendszerinformációk menüpontban a Firebird szerver információk adatlapon a  ForcedWrites nevű tulajdonságnál ellenőrizhető.

A fenti módszerek segítségével többnyire visszaállítható az "eredeti" sebesség.

Firebird szerveren belüli írás lassulás

A bekarikázott érték nagyon magas, több ezres értéket vesz fel, tipikusan 6-9000 közötti értéket.

Adatbázis sebességteszt


A probléma feltételezhető oka, ha a szerveren a HDD-t érintő file műveletek valamilyen oknál fogva belassulnak. Amennyiben a hálózati műveletek is lassúak, akkor a legfelső - Írás az adatbázisba kliens oldalról - érték is nagyon magas lesz.

  • Linux
    Ennek az egyik megállapítási módja az úgynevezett IO wait state figyelése. Szükséges utility: dstat.



    Ha ebben az értékben 10-esnél magasabb értékek szerepelnek, az már gondot okozhat. Ez nem kizárólag a HDD-ről ad tájékoztatást, hanem összesítésről.

  • Windows

    A Windows-ban a HDD IO-wait figyelése kicsit trükkösebb, erre a PerfMon programot használható, abban pedig a Fizikai lemez | Lemezvárólista jelenlegi hossza és a Fizikai lemez | Lemezvezérlő írási várólista átlagos hossza számlálók alapján lehet ezt felmérni.

Lemezterület allokálása

Annak érdekében, hogy a Firebird adatbázis file méretének növekedése során (ahogy egyre több adat kerül bele) az adatbázis file ne fragmentálódjon, célszerű (akár a telepítés során) előre lefoglalni azt a lemezterületet, mely az adatbázis tárolására elegendő lesz. Más adatbáziskezelők ezt DBSPACE-nek hívják.

A Firebird-ben ilyen szolgáltatás nincs, a DBX adatbázis segédprogram ad hasonlóra lehetőséget.

Lehet azonban befolyásolni, hogy az adatbázis méretének növekedését milyen allokációs egységekben tegye.

Ezt a firebird.conf DatabaseGrowthIncrement bejegyzése szabályozza. Alapértéke: 128 KB. Várhatóan nagy adatbázisok esetén célszerű lényegesen nagyobbra választani, vagy a DBX adatbázis segédprogrammal előre lefoglalni a szükséges területet. ez akár 1 GB is lehet.

Forrás: http://www.firebirdsql.org/rlsnotesh/rlsnotes210.html#rnfb210-fbconf-dbgrowth

Az op.rendszer file-system cache ellenhatásának kiküszöbölése

A Firebird-nak saját cache rendszere van.
Ennek az optimális kihasználása érdekében nem célszerű, hogy a Firebird és az op.rendszer is cache-elje az adatokat.

Az optimális teljesítmény érdekében célszerű csak az egyik gyorsítótár kikapcsolása.

1; Az op. rendszer saját cache mechanizmus kikapcsolása (ajánlott):

2; Firebird cache mechanizmus kikapcsolása

MaxFileSystemCache paraméterrel. Ez a kapcsoló csak SuperServer esetén működik.

Ha nem akarjuk, hogy a két cache "egymás ellen" dolgozzon a MaxFileSystemCache paramétert NULLA értékre célszerű beállítani.
Sajnos alapértelmezésként nem így van beállítva!

Forrás: http://www.firebirdsql.org/rlsnotesh/rlsnotes210.html#rnfb210-fbconf-fscache

Shadow file

Ez nem más mint egy on-line biztonsági másolat. Akár mirror -nak is nevezhetnénk. Lehetőség szerint ne ugyanazon a fizikai lemezegységen (vezérlőn) legyen, mint az elsődleges adatbázis file (FDB).

Sebesség probléma Win2008R2 esetén

Az alábbi esetben a HP RAID vezérlő "hibás" drivere okoz lassulást, a driver downgrade megoldotta a problémát

I finally found the reason of this poor performance. It's driver for HP SmartArray P400 witch are broken above Version: 6.14.0.64 (B) (6 May 2009). I was using version 6.20.0.64 (8 Mar 2010) so now when I downgrade to 6.14.0.64 (B) everything works fine for me.

But I still can't explain why DB workbench and flash apps boost this performance

Forrás: http://forums.techarena.in/windows-x64-edition/1352650.htm