Wie bekomme ich einen performanten Firebird?

[Union]

Auf dem Server läuft keine. Wenn ich auf der WS ausschalte, gibt es keinerlei Unterscheid - hatte ich bereits probiert.

[hstreicher]

ein bisschen mehr zur Hardware wäre nützlich

Raid ? wenn ja was für eines
ggf Stripset size ?
Ram Buffer auf dem Controller ? Größe ?

? ? ?

[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).

[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

[Union]

Zwischenbericht
Dank der Hilfe von Euch Allen und besonders Holger Klemt konnte ich das Problem jetzt lokalisieren. Es lag an der Write-Cache-Policy des Controllers. Diese war sehr konservativ eingestellt. Der in IBExpert eingebaute Benchmark meldete nach dem Aktivieren einer mehr auf Performance setzende Policy 120-fach höhere Performance!

Der Import der Buchungstabelle war nach 5:53 abgeschlossen, also ca. doppelt so schnell wie vorher.

Ich habe nun den nächsten Importlauf gestartet, diesmal mit deaktivierten Indizes. Es sieht auf den ersten Blick so aus als wäre das nochmals ca. 5-10 Mal schneller.

Als nächsten Test werde ich einmal das ISql direkt auf dem Server starten und sehen ob durch den Wegfall der TCP-Übertragung noch etwas herauskommt.

Im letzten Schritt werde ich durch mein Export-Tool mal ein Script erzeugen lassen, das die EXTERNAL TABLE Definitionen für die zu importierende Tabelle erzeugt und eine Importdatendatei mit festen Feldlängen passend dazu.

Ich weiss nur noch nicht was ich mit evtl. vorhandenen Memos machen soll.

@Sir Rufo: Ja, der Server ist leider auch ein DC. Der Cache wird schon ab Windows Server 2003 immer dann ausgeschaltet, wenn Windows auf der betreffenden Disk das AD hat und auf dem Controller keine BBU erkennen kann. Was dann passiert hängt in der Tat von der Qualität des Treibers ab. Ich habe daher beim Bootvorgang dskcache eingebunden um die Laufwerk-Richtlininen zu ändern. Wenn die Cache-Befehle nicht durchgereicht werden (dann gibt auch dskcache einen Fehler aus), der Treiber also eigentlich schlecht programmiert ist, dann ist alles in Ordnung.

[IBExpert]

Da merkt man ja, das mein Text durchaus einige Male gelesen wurde.

Lasst euch von den Hardwareheinis keinen vom Pferd erzählen, Ihr könnt tausende Euros für Pseudosicherheit ausgeben, die bei Datenbanksystemen so viele negative Einflüsse haben, das man das gar nicht glaubt. Meistens ist weniger mehr.

Falls Ihr schon mit Firebird arbeitet, dann gibt es noch einen anderen sehr einfach Test.

Erzeugt mit dem Befehl

Code:

"CREATE SHADOW 1 ''C:\db\db.shd'"

mal ein Shadow der Datenbank und messt die Zeit, die der dafür braucht. Das Shadow sollte auf der selben Platte liegern wie die DB. Nachdem das Shadow erzeugt wurde, könnt ihr mit

Code:

"DROP SHADOW 1"

das shadow wieder löschen. Achtung: das Shadow ist fast genau so groß wie die Orginal Datenbankdatei.

Gestern beim Kunden auf dem neuen Server aktuell gemessener Bestwert waren ca. 6 Sekunden pro GB, die 5,5GB große Datei wurde von Firebird 2.5 dabei page für page innerhalb von ca. 30 Sekunden kopiert. Mit einem Trick konnten wir den Wert sogar noch auf 20 Sekunden herunterbringen und das Shadow haben wir dann als automatisierte Datensicherung genommen, die ab sofort alle 30 oder 15 Minuten ausgeführt wird, obwohl beim Erstellen des Shadow aktive Verbindungen auf der Datenbank auch schreiben können, während das Shadow erstellt wird.

Falls euer Server also beim Shadow erzeugen die auf Festplatten und RAIDs üblichen 3-5MB pro Sekunde schafft, dann sollte Ihr die Eignung als Datenbakserver einfach mal hinterfragen. Meistens braucht man ja nur messbare Argmente, damit die Hardwareheinis mal aufhören mit deren Klugscheißereien und den Schweigefuchs zu machen: Öhrchen auf und Schnäuzchen zu.

[vagtler]

Zitat von Union:

[...] @Sir Rufo: Ja, der Server ist leider auch ein DC. [...]

Ein DC ist ein DC, kein Datenbankserver.

[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!