Hardware für Firebird

Forum für neue Firebird-Anwender.

Moderator: thorben.braun

Antworten
aaj
Beiträge: 2
Registriert: So 9. Feb 2020, 13:01

So 9. Feb 2020, 13:07

Hallo zusammen,
Ich möchte einen Server aufbauen für eine Firebird Datenbank.

Aktuell läuft alles auf einem 7 Jahre alten SBS2011 Essential Server und ich will es auf Server 2016 migrieren.

Genutzt wird die Datenbank von maximal 5 Benutzer und läuft auf einem Adaptec Raid Controller 6805T mit WD Black Platten.

Was ich nun wissen möchte ist welches Mainboard mit welcher CPU ist empfehlenswert?

Reicht ein Sockel 2066 oder muss es ein 3467 sein?
ECC Ram pflicht oder normaler Speicher ausreichend mit 32GB.

Gerne würde ich das OS auf gespiegelten SSDs oder NVMe betreiben und die Daten vom RAID weiterhin nutzen.

Danke schon mal vorab.

Mit freundlichen Grüßen
aaj
Benutzeravatar
martin.koeditz
Beiträge: 218
Registriert: Sa 31. Mär 2018, 14:35

So 9. Feb 2020, 22:15

Guten Abend,

ich habe mich seit Jahren nicht mehr mit Mainboards und CPUs beschäftigt. Was du benötigst, hängt natürlich von den Anforderungen an die Software ab.

Damit du einen Eindruck von den Möglichkeiten der passenden Hardware gewinnst, wirf doch mal einen Blick auf die gesammelten Benchmarks von IBSurgeon unter https://ib-aid.com/en/simple-insert-upd ... r-firebird.

Damit wir einen sinnvollen Vorschlag geben können, gib uns doch bitte ein paar Daten zur Anwendung und Datenbank. Welches Betriebssystem, Größe der Datenbank, eingesetzte Client-Software, etc.

Gruß
Martin
Martin Köditz
it & synergy GmbH
vr2
Beiträge: 75
Registriert: Fr 13. Apr 2018, 00:13

Mo 10. Feb 2020, 06:01

Hallo aaj,

Wenn Du ein typisches OLTP-Szenario hast, ist die Hardware nahezu egal. Selbst jeder aktuelle halbwegs komponentenmäßig abgestimmte Laptop reicht hardwaremäßig, Firebird ist nicht ressourcenhungrig, bei 5 Usern ist da noch kein Problem. Kritisch ist, wenn Du eine Virtualisierung einsetzt, weil die oft so konfiguriert sind, dass sie die Ressourcen (CPU, RAM, IO) selber zuteilen, aber erst bei Bedarf und nach ihrer Beurteilung. Das ist für eine Datenbank fast immer zu spät oder falsch. Hier wäre der Ansatz, die Virtualisierung auf Durchzug zu schalten.

Wenn Du trotz der 5 User richtig Dampf brauchst (Reporting, Business Intelligence), nimm eine CPU mit hoher Single-Thread-Performance. Nach meinen Erfahrungen ist die Rechenleistung wichtiger als die IO, obwohl das erstmal überraschend klingt, wenn man nicht weiß, wie viel im Speicher passiert. Sorge für gute Anbindung der CPU ans RAM (Speicher-Lanes usw) und für ausreichend und schnelles RAM, dann kannst Du die verschiedenen beteiligten Caches (Page Cache der DB, Temp Cache) bei Bedarf großzügig dimensionieren. Viel läuft auch über den File System Cache des Betriebssystems.

Firebird ab Version 3.0 parallelisiert über Connections, davor nicht. In Version 4 kommen weitere Bereiche hinzu, die parallelisieren können. Also wenn die 5 User richtig Zirkus machen, nimm eine CPU, die bspw 8 Threads oder mehr parallel kann.

IO spielt eine Rolle, aber nicht so stark wie oft angenommen, da viel mehr im Speicher passiert. Firebird macht viel in-memory, auch wenn es nicht als in-memory-DB beworben wird. Wenn Du RAID einsetzt, konfiguriere RAID 10.

Wenn Du NVME-SSDs ins Spiel bringst, sorge dafür, dass der RAID-Controller mit den Platten mithalten kann, das ist nicht selbstverständlich.

Grundsätzlich gilt immer: Auch wenn die HW passt - die Last, die Du erzeugst, muss optimiert sein. Das ist oft nicht so.

Grüße, Volker
bfuerchau
Beiträge: 188
Registriert: Mo 7. Mai 2018, 18:09

Mo 10. Feb 2020, 11:59

Wie oben schon beschrieben spielt die Hardware nur eine untergeordnete Rolle.
Wichtig wie eigentlich für alle Datenbanken ist der verfügbar Memory, also Hauptspeicher.
Parallelisierung funktioniert auch bereits ab 2.0 durch die Konfiguration als Classikserver. Dabei wird für jede Connection 1 neuer Prozess gestartet.
Erst ab 3.0 wird alles im Singleprozess mit Multithreads abgefackelt, wobei hier auch je Connection ein Thread und nicht je Datenbank ein Thread erstellt wird.
Superclassic bis 2.5 ist also der falsche Weg, da hier keine Parallelisierung mit einer DB möglich ist.

Ich habe bzgl. SSD oder Festplatte keinen wesentlichen Unterscheid in der Performance festgestellt, da i.W. der Hauptspeicher und auch der Filecache von Windows eine erhebliche Rolle spielt.
Das Wegkonfigureiren des Filecaches in der fbconfig ist da kontraproduktiv.

Auch bzgl. VM habe ich da keine Nachteile gespürt da hier durchaus 2 Caches eine Rolle spielen. Der VM-Eigene Cache als auch Filecache des Hosts spielen da eine ordentliche Rolle.

Auf meinem Laptop mit 16GB Speicher und 2,4GHz CPU Intel I7 (8 Threads) schaffe ich z.B. um eine DB Tabelle für Tabelle zu kopieren (wenn der Backup mal wieder nicht klappt) bis zu 10.000 Inserts pro Sekunde (je nach Anzahl Spalten)!
D.h. es werden bis zu 4 Tabellen parallel aus einer DB gelesen und in die andere DB geschrieben.

In unserer BI-Anwendung werden bis zu 10 Mio Zeilen / Sekunde aggregiert.
Ich finde das schon ganz ordentlich.
Ein Microsoft SQL-Server kommt da lange nicht mit.

Natürlich sollte der DB-Server nicht noch für andere Zwecke parallel benötigt werden (Web-Server, Exchange, ...).
aaj
Beiträge: 2
Registriert: So 9. Feb 2020, 13:01

Mo 10. Feb 2020, 14:17

Danke schon mal für die sehr guten Ausführungen.
Da werde ich mir die aktuellen FIREBIRD Version noch mal anschauen müssen.

Firebird hört sich also nicht sooooo hungrig an und ich denke das ich dann mit Kanonen auf Spatzen schiesse wenn ich mich für folgende CPUs entscheiden würde.

Intel Core i9 9820X 10x 3.30GHz So.2066
oder
Intel Xeon Silver 4110 8x 2.10GHz So.3647

Danke noch mal.

BTW: Kein Exchange oder Webserver am laufen, nur noch als FILE Server.
bfuerchau
Beiträge: 188
Registriert: Mo 7. Mai 2018, 18:09

Mo 10. Feb 2020, 15:37

Auch ein Fileserver kann höhere Transaktionsraten erzeugen. Ins besonders wenn z.B. mit Office-Dokumenten gearbeitet wird, viele User auf Dokumente zugreifen und eben viel File-IO betrieben wird.
Da der Systemfile-Cache für alle da ist, kommt es hier durchaus zu einem Verdrängungswettbewerb, so dass DB-Abfragen und -Änderungen da schon langsamer werden können.
Antworten