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
davor und
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