Wie bekomme ich einen performanten Firebird?

[Union]

Hier mal die wichtigsten Eckdaten:

Zitat von 3DM2:

Server:
2x Intel Xeon E5620 @2,40 Ghz
24566 MB Speicher
5371 MB frei
Auslastung zwischen 0-4%
fb_inet_server belegt 22020Kb
Schreibgeschwindigkeit in FDB schwankt zwischen 500.000 - 1.600.000 B/s 58-160 ms Antwortzeit

Controller: LSI 3Ware Liberator
Firmware: FHX 5.12.00.007
Driver: 5.01.00.018
BIOS: BE9X 5.11.00.006
Memory: 488 MB
Bus Type: PCIe
Bus Width: 4 Lanes
Bus Speed 2.5 Gbps/Lane
Unit 0: Raid 5 1,82TB
Stripe: 64kb
Volumes: 1
Subunits 3
HDs: WDC WD1003FBYX-01Y7B0 931,51 GB SATA
Letzter Verify: 19.04.2014 19:20, OK
Keine Fehler seit 16.02.2013 (weiter reicht das Log nicht zurück).

[IBExpert]

Moin,

das mit den Buffers hast du ja schon gefunden, in der Statistik stand ja vorher 0 als Page Buffers und das bedeutet, das dein Superclassic pro connection sage und schreibe 75 Pages cacht. Da deine DB dann auch noch nur 4k Pagesize hat und nicht wie durchaus empfehlenswert 16k, ist daher dein cache beim insert 75*4k, also sage und schreibe 300 Kbyte.

Das reicht nicht mal um die Systemtabellen zu cachen, geschweige denn Index pages, data pages usw. Dieser durchaus von Firebird bei der Classic/Superclassic Variante gewählte default wert von 75 ist sicherlich zu klein, aber aufgrund der Historie von Firebird bzw Interbase schon in der Steinzeit benutzbar gewesen, als Datenbankserver sich noch über 1MB Ram mehr gefreut haben.

Weiterhin gehe ich aber davon aus, das dein Server trotz guter CPU mit Firebird leider eine ziemlich lahme Gurke ist, denn die fehlende CPU Last ist ganz einfach damit zu erklären, das die CPU nur auf den Datenträger=Festplatte oder Raid wartet. Und ich würde wetten, das der Datenträger eine gute alte drehende Festplatte ist, was im Zeitalter von robusten Enterprise SSDs für Datenbank so ähnlich ist wie heute noch einen Röhrenbildschirm auf dem Schreibtisch zu haben. Und ganz wichtig: RAID ist nicht immer vorteilhaft, dazu später mehr.

Also erster Tip:

Wenn Classic oder Superclassic, dann zunächst mal in firebird.conf den Eintrag #DefaultDbCachePages = 2048 durch
DefaultDbCachePages = 1024 ersetzen (ohne # davor, weil das das Kommentarzeichen ist).

Dann gilt ab sofort dieser Wert als Default, auch wenn in der DB nicht mit gfix angepasst wurde. Ab ca. 500 Pages wird firebird mit normalen Festplatten überhaupt erst sinnvoll benutzbar. Es gilt dabei immer der Wert mit gfix oder in ibexpert-services-database properties eingestellte wert überschreibt den Wert aus der Firebird.conf. Wenn im Statistikheader Page buffers 0 steht, gilt der Wert der Firebird.conf. Wenn der nicht gesetzt ist, dann gilt der Default Wert der Firebird Version, bei Superserver also 2048 und bei classic oder superclassic 75.

Wenn du nun also mit einem Backup/Restore die Pagesize auf 16k verändert hast, dann gilt für 1000 Pages beim Superclassic ein Cache pro Userconnection von 16MB, da passt deutlich mehr rein als in 300k. Dieser Wert muss aber pro Userconnection auch auf dem Datenbankserver physikalisch frei sein und nicht in einer ausgelagerten Pagefile simuliert werden.

Wenn du das mit zum Beispiel maximal 10 Userconnections auf der DB arbeitest, dann braucht der Cache gerade mal 160 MB, das sollte man schon frei haben. Dreh den Wert aber nicht zu hoch, es gibt nachher nicht nur Vorteile.

Nächster Punkt: Deine Inserts kannst du am besten einfach mit execute block zusammenfassen, d.h. bei Masseninserts gar nicht parametrisieren, sondern nimm dir aus der SQL Datei wenn es geht jeweils 50 Zeilen (darf nicht mehr als 32 kb pro block sein) und schreibe

Code:

execute block as begin

davor und

Code:

end

dahinter. Jede insert Zeile muss am Ende ein Semikolon haben. Den Text packst du nun ganz normal in die sql.text eigenschaft deiner TxxQuery und führst das mit execsql aus. Auf dem Weg schickst du 50 Sqls in einem TCP/IP Datenpaket an den Server und nicht 2000 wie bei parametrisierten SQLs. Ob du dann nach jeweils 100*50 zeilen ein commit machst ist dann gar nicht mehr so wild.

So erzeugte SQLs Dateien kannst du auch mit IBExpert im Script executive, mit ibescript.exe oder mit jedem anderen einigermaßen brauchbaren SQL Tool für Firebird direkt ausführen. Manche Delphi Komponenten sind leider zu blöd dafür, mit den meisten klappt das aber.

Zu guter Letzt dann noch folgender Hinweis zur Hardware:

Wir haben mal bei einem Kunden, mit dessen Software und Hardware alle MTV Europe Fernsehstationen (MTV, viva und wie der Kram nicht alles heisst) ihr Programm ausstrahlen, einen Test von einigen Dell Servern als Stichprobe gemacht. Insgesamt setzt MTV über 100 Firebird Server ein, jeweils einer pro Kanal und Land, je Kanal auch eigene Hardware ohne Virtualisierung. Das komplette MTV Programm kommt aus Firebird Servern, genau so wie länderspzifische Klingeltonwerbung usw.

Das spannende dabei war, das die Stichprobe mit 10 Server auf 7 Servern ok war und auf 3 angeblich baugleichen unglaublich langsam war. In allen Rechnern waren DELL Raid Controller mit 3 SAS HDDs eingebaut, auf den schnellen Rechner dauerte der in der IBExpert Vollversion eingebaute Benchmark insgesamt ca. 2 Minuten, auf den langsamen jedoch 17 Minuten.

Theoretisch war alles identisch praktisch aber scheinbar nicht. Der Dell Support selbst hat auch nicht weitergeholfen, sondern auf der Kiste nur eine 500MB Datei in ca 2-3 Sekunden von einen Pfad in den anderen kopiert und gesagt, der Rechner ist ok. Aus der Sicht des Hardwareherstellers auch verständlich, für den Kunden aber trotzdem inakzeptabel.

Egal ob du nun classic oder superclassic nimmst, im Multiuserbetrieb mit 10 User verursacht diese Version gegenüber dem Superserver die 10fache I/O Last auf dem Datenträger und die CPU wartet meistens nur darauf, das der Datenträger endlich mal wieder die eine oder andere angeforderte Page von der Platte nachlädt. Daher siehst du keine CPU Last.

Wenn dann noch für jede Page der Schreiblesekopf bewegt werden muss, dann ist die mittlere Zugriffszeit des Datenträgers viel wichtiger als der CPU Speed, weil die eh nur wartet. Bei recht guten 10ms durchschnittliche Zugriffszeit wären dann also für 10*10 Kopfbewegungen schon die erste Sekunde Wartezeit zusammen. Wenn nun noch die Cachebuffers zu klein sind, dann sind das eher 10*100 Kopfbewegungen, also zusammen 10 Sekunden. SSDs habe da erhebliche Vorteile, im Zusammenspiel mit ausreichend Arbeitsspeicher geht dann noch mal richtig die Post ab, wenn man das sinnvoll einstellt. Deine CPUs können aber auch 100 Kerne haben, bei ienem zu lahmen Datenträger heizen die nur das Gehäuse während die warten. Das siehst du ja auch auf deinem Taskmanager: gähnende Langeweile in der CPU ....

Ganz wichtiger Zusatzhinweis: pro userconnection benutzt Firebird in allen Versionen immer nur einen CPU Kern. Wenn du beim Import der einzige User bist, wirst du mit diesem einem Import auch nur einen CPU Kern auslasten. Wenn dein Import sauber multithreaded programmiert ist, könnte es ein Vorteil sein, das jeder Thread beim classic oder superclassic auf einem anderen Kern laufen kann, aber wenn der Datenträger lahm ist, dann erzeugt das mehr Last als es vorteile bringt.

Mit den bei mtv auf den schnellen Servern gemessenen 120 Sekunden erreichst du im IBExpert Benchmark eine Wert von ca. 35% (die Referenz 100% ist der gleiche Benchmark auf einem von uns als Hardware für 1200 € angebotenen IFS Server, der ca. 40 Sekunden für den Benchmark mit dem Superserver braucht, d.h. das sind die 100% (beim superclassic erreicht der etwa 60%)

Eine heute von mir ausgelieferter IFS Server, der schon ein paar Euro mehr gekostet hat, schafft mit verschiedenen Techniken mit dem Superserver als auch mit dem superclassic server im IBExpert Benchmark ca. 170 %, braucht als knapp über 20 Sekunden.

Eine Benchmark auf einem Kundenserver, wo Schweinchen Schlau Systemadministrator wieder alles besser wusste, hat letzte Woche sämtliche mir bekannten Negativ Rekorde gebrochen, der brauchte für den gleichen Test sage und schreibe ca. 2 Stunden! Keine Ahnung was der da eingebaut, sah aber irgendwie nach iscsi schnittstelle an externer storage aus order irgendwas ähnliches, was für Datenbankserver der absolute Oberschwachfug ist, weil dann zu den mittleren Zugriffszeiten der HDD auch noch die Latenzzeit auf dem Netzwerkkabel kommt und bei viel Traffic auch noch die Kollosionen.

Im Benchmark wurde dieser Server als erster mit 0% gemessen, weil die Referenzzeit unseres 100% Systems geteilt durch diese Zeit gerundet weniger als 1 ergab. Und die Anwender der Firebird basierenden Software können nicht vernünftig arbeiten, weil Schweinchen Schlau Systemadministrator meint, alles besser zu wissen als der Softwarehersteller, von dem wir den Auftrag zur Rechnerprüfung hatten. Der Softwarehersteller selbst hat schon einen von ihm konfgurierten Firebird Server zum Kunden mitgenommen hatte, auf dem das vernünftig lief. Kunde wollte aber lieber seine Schrottkonfiguration behalten, egal wie lahm die ist, warum auch immer ...

Im Rahmen unsere Hotline schalten wir uns auch gerne auf die Server unserer Kunden und nutze dann eine IBExpert Tageslizenz für den Benchmark (ist halt nur in der Vollversion drin). Es ist immer wieder lustig, wenn dann jemand einen frisch gekauften teuren Rechner als komplett ungeeignet erkennt und dann doch auf einmal jemanden fragt, der sich damit auskennt, wie man den denn doch noch einigermaßen schnell bekommt. Je teurer die Storage und je virtualisierter das ganze ist, um so mieser sind die Werte im Vergleich zu einem echten dedizierten Datenbankserver.

Als einfach Vorabtest auch ohne unseren Benchmark: Nicht eine Datei mit 500 MB von einen Pfad in den anderen auf dem gleichen Laufwerk kopieren, das ist langweilig und sagt nichts über Datenbankoperationen aus. Dafür lieber einfach mal 100000 oder 1mio Dateien mit je 1k von einem Pfad in einen anderen Pfad auf dem gleichen Laufwerk kopieren (wichtig: kopieren, nicht verschieben). Da rödelt sich die Platte einen ähnlichen Wolf wie bei Datenbankoperationen. Damit habt ihr schon mal ganz grob einen Vergleichswert mit einem Referenzsystem eurer Wahl.

Die CPU Geschwindigkeit ist vergleichweise egal, der heute ausgelieferte Server, der die 170% erreicht hat, hatte 2,5 Ghz, das aber mit insgesamt 10 Kernen (Xeon E5) und einem guten Servermainboard, auf dem der eingebaute Intel C220/600 RAID Controler mit RAID1 super Leistung bringt.

Aber auch da setzen wir diverse Tricks ein, damit eine 5,5GB große Datenbank mit ca. 50mio Datensätzen und reichlich Indizes beim backup/restore innerhalb von 13 Minuten durch ist (4 Minuten backup/9 Minuten Restore, jeweils mit gbak). Könnt Ihr ja mal mit euren Werten vergleichen

So, das reicht aber auch nun, keine Ahnung ob so lange Post überhaupt von den meisten bis zum Ende gelesen werden

Ein schönes Wochenende wünsche ich

[Lemmy]

Zitat von IBExpert:

So, das reicht aber auch nun, keine Ahnung ob so lange Post überhaupt von den meisten bis zum Ende gelesen werden

HIER!!! Danke für die Ausführungen!

[tsteinmaurer]

Zitat:

Insgesamt setzt MTV über 100 Firebird Server ein

Schade, schade, dass das Firebird Projekt um jeden Euro/Dollar kämpfen muss, wenn solche kommerzielle Firebird Installation im Umlauf sind.

Interessanter Post, btw.

LG

[Union]

Super Post, ich habe jede Zeile genossen. Mein Datenimport ist nun durch, 8364632 records in 11:09:16.531. Bei der Einrichtung des Servers mussten wir wegen des Raids ganz schön tricksen weil Windows Server standardmäßig meint den Cache ausschalten zu müssen. Ich erzeuge gerade mal 1 Mio Testfiles.

[hstreicher]

Noch eines zur Stripset Größe 64 KB
das Stripeset ist die Verwaltungseinheit eines RAID , d.h. jede Lese oder Schreibanforderung liest/schreibt diese Datenmenge von den Platten

also bei Firebird Pagesize 4KB und Stripset 64KB laufen 60 KB nutzlos über die Platten also rund 93 % nutzlose Daten

Bei dem vom HK vorgeschlagenen 16 KB sind das immer noch 75% Nutzlose Daten die von den Platten geholt werden
also Stripset Größe auf 16KB (oder das kleinst mögliche )

-

Wieso der Performance Einbruch nach ca 300000 Inserts ,
Antwort der Ram Cache des Diskcontrollers (488MB) ist vollgelaufen und jetzt schlägt der Treibanker RAID voll zu

mfg Hannes

[Sir Rufo]

Ein RAID5 mit 3 Platten ist sicher(er) aber sicher nicht schnell.

Meine Erfahrung mit RAID5 hat mich gelehrt, dass man ab ca. 6 Platten in einem Verbund einen schnelleren Zugriff bekommt.

Für Datenbanken ist allerdings ein RAID10 fast schon Pflicht.

Windows Server und Cache abschalten:

Das ist doch hoffentlich kein Domain-Controller, oder?
Ein Domain-Controller schaltet den Cache auf der System-Platte (die Platte, wo die System-Partition liegt) ab, damit das Active-Directory keinen Schaden nehmen kann. Das sollte man auch tunlichst unterlassen, den Cache da wieder einzuschalten

Ein Server, der Domain-Controller werden soll bekommt für das System einen eigenen Plattenverbund spendiert (RAID1,5,10 je nach Geldbeutel und Gusto) und für die restlichen Daten weitere Platten-Verbünde, je nach Anforderung (RAID10 für DB, RAID5 für den anderen Kram).

Für ein performantes, sicheres und schnell wiederherzustellendes Netzwerk packe ich auf 2 (hardware) getrennte VMs den Domain-Controller und Backup-Domain-Controller. Und diese sind ausschließlich Domain-Controller und haben sonst keine weiteren Aufgaben.

Alle anderen Server werden nur Mitglieder der Domäne.

[IBExpert]

Zitat von Sir Rufo:

Für Datenbanken ist allerdings ein RAID10 fast schon Pflicht.

ich plädiere da eher auch ein RAID 1 auf Basis von 2 High End Enterprise SSDs namhafter Hersteller, z.B. Intel
und einem ausgeklügelten Sicherungskonzept.

Vorteile Raid 1: Jede der beiden Platten ist ohne Einschränkung in einem anderen Rechner sofort einsetzbar, zum
Beispiel ist damit ein Backupserver mit gleichen Hot Plug Einschüben sofort einsetzbar.

Im RAID 10 sind Einzelplatten gar nicht benutzbar und so manch ein Controller reagiert seltsam, wenn er zwei
asynchrone Raid 0 Parts hochfahren soll. Der Geschwindigkeitsgewinn durch Raid0 hält sich je nach Stripe Größe
auch sehr im Rahmen oder sorgt sogar für negative Auswirkungen.

Auf dem Raid Laufwerk ist dann aber nur die Datenbank. Das OS kann dann auf einer normalen Platte sein, ob die
dann mit Raid Technik abgesichert ist, ist dann dem eigene Geschmack und Budget überlassen.

[jsheyer]

Hallo,

es war sehr viel Text, habe es aber auch mit Freuden bis zum Ende gelesen

Übrigens, das System, das bei einem Kunden die Performance Problem bei schreiben hatte, war auch ein Dell, Zufall????
Auch hier konnte nicht festgestellt werden, absolut rätselhaft.
Man konnte den Effekt sogar beim kopieren von grossen Dateien nachstellen, also mal 5 GB kopiert, so ab 500 MB ging die Geschwindigkeit teilweise auf 200 kB / Sek runter.
Und wie gesagt, nirgendwo irgendeine Fehlermeldung.

[mikhal]

Zitat:

So, das reicht aber auch nun, keine Ahnung ob so lange Post überhaupt von den meisten bis zum Ende gelesen werden

Ich hab's auch bis zum Ende gelesen und mir so meine Gedanken zur Firmendatenbank unseres ERP gemacht. Hier ist es zwar eine Oracle-Datenbank mit ca. 100 GByte Tablespace, aber auch hier ist der Effekt schlechter Performance zu erkennen. Hier ist im SAN (über FibreCat angesteuert) ein RAID 5 Verbund gegeben und die Performance ist hier schlechter wie bei der Kopie für die Entwickler, die ohne RAID auf einem Testserver zugreifen (und das nicht nur, weil dann deutlich weniger Mitarbeiter im System arbeiten).

Auf jeden Fall sind ein paar technische Fragen bei mir hochgekommen, wie man es verbessern kann - aber das ERP wird nächsten Monat durch ein ein anderes ersetzt...
Trotzdem: Danke Holger, hat mir tiefe Einblicke gegeben und wird mir bei meinem zukünftigen Weg weiterhelfen.

Mikhal