10
Firebird 4 Superserver - Performance
N'Abend zusammen.
Ich hätt' da mal ne Frage an diejenigen, die sich mit Firebird als Datenbank-Server und der Entwicklung von entsprechenden Applikationen ein wenig besser auskennen als ich.
Einer unserer Kunden hat teils massive Performance-Probleme bei der Verwendung seiner Applikation, die mit einer Firebird-Datenbank arbeitet. Erst kürzlich wurde Firebird auf Version 4 aktualisiert und in der "SuperServer Architecture" installiert. Nun fiel auf: Der Firebird nutzt nur einen von vier virtuellen Cores.
Bei der Suche nach einer Lösung bin ich über "CPUAffinity" gestolpert und wir haben nach Rücksprache mit dem Software-Entwickler den Wert auf 15 gesetzt und den Firebird neu gestartet (auf eigenes Risiko, der Entwickler hat das noch nie getan). Das scheint auch tatsächlich etwas gebracht zu haben, die Applikation lädt nun die Ergebnisse auch größerer Abfragen deutlich schneller.
Im Verlauf der Recherche haben wir unzählige, auch aktuelle Artikel gefunden, in denen das Thema Performance besprochen wird. 95% der Artikel kommen zu dem Schluss, dass durch Virtualisierung "bis zu 80% der Performance" des Firebird verlustig gehen und man doch bitte für jede Firebird-Instanz idealerweise dedizierte Hardware, mindestens aber mal eine eigene VM (die natürlich inkl. Storage für brutal viele IOPS ausgelegt sein muss) zur Verfügung zu stellen hat.
Daraus resultiert meine Frage bzw. mein Verständnisproblem:
Ernsthaft? Echte Hardware anno 2022? Haben da die Entwickler der Datenbank irgendwie die Zeit verschlafen?
Wenn allein das anpassen einer .conf-Datei die "eingebaute Handbremse" lösen kann halte ich die Aussagen aus den Artikeln für irgendwie krumm.
Kann jemand mit mehr Erfahrung in diesem Bereich mich mal erleuchten, warum Firebird so "speziell" ist?
Wir reden über eine Umgebung mit max. 15 Usern und ner Datenbankgröße <1GB, betrieben auf virtuellen Windows 2022 Servern. Ich meine, ich bekomme jeden MS SQL auf vergleichbaren virtuellen Plattformen und Umgebungen "aus dem Stand" mit deutlich besserer Performance an den Start....
Danke für euren Input.
Cheers,
jsysde
Ich hätt' da mal ne Frage an diejenigen, die sich mit Firebird als Datenbank-Server und der Entwicklung von entsprechenden Applikationen ein wenig besser auskennen als ich.
Einer unserer Kunden hat teils massive Performance-Probleme bei der Verwendung seiner Applikation, die mit einer Firebird-Datenbank arbeitet. Erst kürzlich wurde Firebird auf Version 4 aktualisiert und in der "SuperServer Architecture" installiert. Nun fiel auf: Der Firebird nutzt nur einen von vier virtuellen Cores.
Bei der Suche nach einer Lösung bin ich über "CPUAffinity" gestolpert und wir haben nach Rücksprache mit dem Software-Entwickler den Wert auf 15 gesetzt und den Firebird neu gestartet (auf eigenes Risiko, der Entwickler hat das noch nie getan). Das scheint auch tatsächlich etwas gebracht zu haben, die Applikation lädt nun die Ergebnisse auch größerer Abfragen deutlich schneller.
Im Verlauf der Recherche haben wir unzählige, auch aktuelle Artikel gefunden, in denen das Thema Performance besprochen wird. 95% der Artikel kommen zu dem Schluss, dass durch Virtualisierung "bis zu 80% der Performance" des Firebird verlustig gehen und man doch bitte für jede Firebird-Instanz idealerweise dedizierte Hardware, mindestens aber mal eine eigene VM (die natürlich inkl. Storage für brutal viele IOPS ausgelegt sein muss) zur Verfügung zu stellen hat.
Daraus resultiert meine Frage bzw. mein Verständnisproblem:
Ernsthaft? Echte Hardware anno 2022? Haben da die Entwickler der Datenbank irgendwie die Zeit verschlafen?
Wenn allein das anpassen einer .conf-Datei die "eingebaute Handbremse" lösen kann halte ich die Aussagen aus den Artikeln für irgendwie krumm.
Kann jemand mit mehr Erfahrung in diesem Bereich mich mal erleuchten, warum Firebird so "speziell" ist?
Wir reden über eine Umgebung mit max. 15 Usern und ner Datenbankgröße <1GB, betrieben auf virtuellen Windows 2022 Servern. Ich meine, ich bekomme jeden MS SQL auf vergleichbaren virtuellen Plattformen und Umgebungen "aus dem Stand" mit deutlich besserer Performance an den Start....
Danke für euren Input.
Cheers,
jsysde
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4080383068
Url: https://administrator.de/contentid/4080383068
Printed on: June 2, 2024 at 00:06 o'clock
10 Comments
Latest comment
Moin...
Einer unserer Kunden hat teils massive Performance-Probleme bei der Verwendung seiner Applikation, die mit einer Firebird-Datenbank arbeitet. Erst kürzlich wurde Firebird auf Version 4 aktualisiert und in der "SuperServer Architecture" installiert. Nun fiel auf: Der Firebird nutzt nur einen von vier virtuellen Cores.
jo... das ist so!
Bei der Suche nach einer Lösung bin ich über "CPUAffinity" gestolpert und wir haben nach Rücksprache mit dem Software-Entwickler den Wert auf 15 gesetzt und den Firebird neu gestartet (auf eigenes Risiko, der Entwickler hat das noch nie getan). Das scheint auch tatsächlich etwas gebracht zu haben, die Applikation lädt nun die Ergebnisse auch größerer Abfragen deutlich schneller.
aber nicht sehr viel.
Im Verlauf der Recherche haben wir unzählige, auch aktuelle Artikel gefunden, in denen das Thema Performance besprochen wird. 95% der Artikel kommen zu dem Schluss, dass durch Virtualisierung "bis zu 80% der Performance" des Firebird verlustig gehen und man doch bitte für jede Firebird-Instanz idealerweise dedizierte Hardware, mindestens aber mal eine eigene VM (die natürlich inkl. Storage für brutal viele IOPS ausgelegt sein muss) zur Verfügung zu stellen hat.
das ist si richtig!
Daraus resultiert meine Frage bzw. mein Verständnisproblem:
Ernsthaft? Echte Hardware anno 2022? Haben da die Entwickler der Datenbank irgendwie die Zeit verschlafen?
irgendwie Schon...
Kann jemand mit mehr Erfahrung in diesem Bereich mich mal erleuchten, warum Firebird so "speziell" ist?
warum, kann ich nicht sagen, die entwickler wissen aber sicher mehr 
bis 20 User ist das noch machbar... allerdings sind 15 User im Netzwerk (ohne RDS) schon der Hammer!
mein Ratschlag, stell auf RDS um...
wenn du mehr Infos brauchst, Schreib mir, oder wir Telefonieren!
Danke für euren Input.
Cheers,
jsysde
Frank
Zitat von @jsysde:
N'Abend zusammen.
Ich hätt' da mal ne Frage an diejenigen, die sich mit Firebird als Datenbank-Server und der Entwicklung von entsprechenden Applikationen ein wenig besser auskennen als ich.
ok...N'Abend zusammen.
Ich hätt' da mal ne Frage an diejenigen, die sich mit Firebird als Datenbank-Server und der Entwicklung von entsprechenden Applikationen ein wenig besser auskennen als ich.
Einer unserer Kunden hat teils massive Performance-Probleme bei der Verwendung seiner Applikation, die mit einer Firebird-Datenbank arbeitet. Erst kürzlich wurde Firebird auf Version 4 aktualisiert und in der "SuperServer Architecture" installiert. Nun fiel auf: Der Firebird nutzt nur einen von vier virtuellen Cores.
Bei der Suche nach einer Lösung bin ich über "CPUAffinity" gestolpert und wir haben nach Rücksprache mit dem Software-Entwickler den Wert auf 15 gesetzt und den Firebird neu gestartet (auf eigenes Risiko, der Entwickler hat das noch nie getan). Das scheint auch tatsächlich etwas gebracht zu haben, die Applikation lädt nun die Ergebnisse auch größerer Abfragen deutlich schneller.
Im Verlauf der Recherche haben wir unzählige, auch aktuelle Artikel gefunden, in denen das Thema Performance besprochen wird. 95% der Artikel kommen zu dem Schluss, dass durch Virtualisierung "bis zu 80% der Performance" des Firebird verlustig gehen und man doch bitte für jede Firebird-Instanz idealerweise dedizierte Hardware, mindestens aber mal eine eigene VM (die natürlich inkl. Storage für brutal viele IOPS ausgelegt sein muss) zur Verfügung zu stellen hat.
Daraus resultiert meine Frage bzw. mein Verständnisproblem:
Ernsthaft? Echte Hardware anno 2022? Haben da die Entwickler der Datenbank irgendwie die Zeit verschlafen?
Wenn allein das anpassen einer .conf-Datei die "eingebaute Handbremse" lösen kann halte ich die Aussagen aus den Artikeln für irgendwie krumm.
nein, nicht wirklich!Kann jemand mit mehr Erfahrung in diesem Bereich mich mal erleuchten, warum Firebird so "speziell" ist?
Wir reden über eine Umgebung mit max. 15 Usern und ner Datenbankgröße <1GB, betrieben auf virtuellen Windows 2022 Servern. Ich meine, ich bekomme jeden MS SQL auf vergleichbaren virtuellen Plattformen und Umgebungen "aus dem Stand" mit deutlich besserer Performance an den Start....
wir haben einige Kunden mit Theorg, dort genauso- flüssig Arbeiten geht nur auf einem RDS und NVMe unterbau! der Firebird Superserver hat keine SMP Unterstützung, mit dem CpuAffinityMask Parameter wird nur der Core nicht getauscht!. Der Classic Server kann SMP, und wird warscheinlich in deinem Fall besser sein!bis 20 User ist das noch machbar... allerdings sind 15 User im Netzwerk (ohne RDS) schon der Hammer!
mein Ratschlag, stell auf RDS um...
wenn du mehr Infos brauchst, Schreib mir, oder wir Telefonieren!
Danke für euren Input.
Cheers,
jsysde
Ohne deine Software zu kennen ist die Diskussion müßig.
Hi,
ja, das ist leider so mit Firebird. Ich mußte jahrelang eine Software (orgaMAX) supporten, die auf Firebird setzte. Gab ständig massive Performance-Probleme. Zusätzlich war die Software auch noch so richtig grottig programmiert, das größere Abfragen mitunter mehrere Minuten gebraucht haben. Zum Glück bin ich davon weg.
cu,
ipzipzap
ja, das ist leider so mit Firebird. Ich mußte jahrelang eine Software (orgaMAX) supporten, die auf Firebird setzte. Gab ständig massive Performance-Probleme. Zusätzlich war die Software auch noch so richtig grottig programmiert, das größere Abfragen mitunter mehrere Minuten gebraucht haben. Zum Glück bin ich davon weg.
cu,
ipzipzap
Zitat von @jsysde:
Ich hätt' da mal ne Frage an diejenigen, die sich mit Firebird als Datenbank-Server und der Entwicklung von entsprechenden Applikationen ein wenig besser auskennen als ich.
Kann jemand mit mehr Erfahrung in diesem Bereich mich mal erleuchten, warum Firebird so "speziell" ist?
Wir reden über eine Umgebung mit max. 15 Usern und ner Datenbankgröße <1GB, betrieben auf virtuellen Windows 2022 Servern. Ich meine, ich bekomme jeden MS SQL auf vergleichbaren virtuellen Plattformen und Umgebungen "aus dem Stand" mit deutlich besserer Performance an den Start....
Wir reden über eine Umgebung mit max. 15 Usern und ner Datenbankgröße <1GB, betrieben auf virtuellen Windows 2022 Servern. Ich meine, ich bekomme jeden MS SQL auf vergleichbaren virtuellen Plattformen und Umgebungen "aus dem Stand" mit deutlich besserer Performance an den Start....
Ohne massive Unterstützung durch den Softwarehersteller wird das ein sinnloses Unterfangen werden.
Man kann mit schlechter Programmierung jedes noch so gute Datenbanksystem in die Knie zwingen. Dem kann man nur sehr begrenzt entgegenwirken. Mehr CPU Leistung, mehr IOPS, schnelleres Netzwerk und RDS können schon helfen, lösen aber das Grundproblem nicht.
Andere Softwarehersteller können das mit der schlechten Performance mit anderen Datenbanksystemen genauso.
Hallo,
wenn man das so liests, kann man auch gleich eine Access-DB mit Datendatei einsetzen.
Kann man die Software ändern, damit sie z.B. MySQL verwendet?
Da hätte man dann wenigstens eine Perspektive.
Aber Danke für den Thread.
Ich streiche Firebird von allen Überlegungen zum Thema Datenbank.
Stefan
wenn man das so liests, kann man auch gleich eine Access-DB mit Datendatei einsetzen.
Kann man die Software ändern, damit sie z.B. MySQL verwendet?
Da hätte man dann wenigstens eine Perspektive.
Aber Danke für den Thread.
Ich streiche Firebird von allen Überlegungen zum Thema Datenbank.
Stefan
Ich hatte den Feuervogel bei meinem vorletzten Arbeitgeber auf einem Linux-Unterbau als VM Laufen.
Das ging bei ca. 25 Nutzern recht gut.
Das ging bei ca. 25 Nutzern recht gut.
Mahlzeit.
Asche auf mein Haupt - das ^^ ist schon so: RDS mit max. 15 Usern drauf, der Firebird läuft auf der VM "nebenan". Hier wäre die Frage, ob wir den Firebird nicht direkt auf den RDS migrieren? Wobei Netzwerk-Performance eher nicht das Thema ist...
Was die verwendete Software angeht: Spielt tatsächlich eher eine untergeordnete Rolle, ich hab nur mal einen Kunden rausgepickt, bei dem die Performance arg unterirdisch war. Die eingesetzte Software ist eine Fachanwendung für die Immobilienverwaltung. Bei einem anderen Kunden ist es eine Fachanwendung für die Garten- und Landschaftsbaubranche und der Kunde kommt auf insg. 7 User, von denen drei die Applikation auf ihrem Arbeitsplatz installiert haben -kein RDS- und die DB auf ner VM im Netz liegt. Die Liste ließe sich noch um <n> Einträge erweitern, aber eure Aussagen helfen mir schon sehr, das ganze besser einordnen zu können - danke euch für euren Input!
Cheers,
jsysde
Asche auf mein Haupt - das ^^ ist schon so: RDS mit max. 15 Usern drauf, der Firebird läuft auf der VM "nebenan". Hier wäre die Frage, ob wir den Firebird nicht direkt auf den RDS migrieren? Wobei Netzwerk-Performance eher nicht das Thema ist...
[...]wenn du mehr Infos brauchst, Schreib mir, oder wir Telefonieren!
Danke für das Angebot, ich komme ggf. darauf zurück. Momentan ist der Kunde erstmal "glücklicher", da es augenscheinlich nun alles schneller läuft. Was ich gestern, als ich das gepostet habe, noch nicht wusste: Der Software-Hersteller hat gestern einen Hotfix rausgegeben, der ebenfalls installiert wurde. Aktuell also unklar, ob die Performance-Steigerung durch die Anpassung der "CPUAffinity" resultiert oder durch den Hotfix. Schlimmstenfalls isses ein wilder Mix von beidem...Was die verwendete Software angeht: Spielt tatsächlich eher eine untergeordnete Rolle, ich hab nur mal einen Kunden rausgepickt, bei dem die Performance arg unterirdisch war. Die eingesetzte Software ist eine Fachanwendung für die Immobilienverwaltung. Bei einem anderen Kunden ist es eine Fachanwendung für die Garten- und Landschaftsbaubranche und der Kunde kommt auf insg. 7 User, von denen drei die Applikation auf ihrem Arbeitsplatz installiert haben -kein RDS- und die DB auf ner VM im Netz liegt. Die Liste ließe sich noch um <n> Einträge erweitern, aber eure Aussagen helfen mir schon sehr, das ganze besser einordnen zu können - danke euch für euren Input!
Cheers,
jsysde
N'Abend.
Kann "man" bestimmt - leider kommen alle Setups als .exe oder .msi daher und enthalten eine vorkonfigurierte Instanz. Ich kenn das bei anderen Applikation auch eher so, dass der Admin vorher "irgendwo" ne SQL-Instanz vorbereitet und die Applikation dann per Setup dorthin verbunden wird. Scheint aber im Universum der mit Firebird arbeitenden Applikationen eher die Ausnahme zu sein.
Cheers,
jsysde
Kann "man" bestimmt - leider kommen alle Setups als .exe oder .msi daher und enthalten eine vorkonfigurierte Instanz. Ich kenn das bei anderen Applikation auch eher so, dass der Admin vorher "irgendwo" ne SQL-Instanz vorbereitet und die Applikation dann per Setup dorthin verbunden wird. Scheint aber im Universum der mit Firebird arbeitenden Applikationen eher die Ausnahme zu sein.
Cheers,
jsysde
N'Abend.
Cheers,
jsysde
Zitat von @beidermachtvongreyscull:
Ich hatte den Feuervogel bei meinem vorletzten Arbeitgeber auf einem Linux-Unterbau als VM Laufen.
Das ging bei ca. 25 Nutzern recht gut.
Ich würd' diesen Versuch tatsächlich wagen, aber wie schon geschrieben, habe ich während des Setups gar keine Möglichkeit, eine SQL-Instanz anzugeben. Aus dem Wirrwarr der Config-Files werd' ich auch nach Rücksprache mit dem Software-Entwickler nicht schlau und der sagt ganz klar: Ist so nicht vorgesehen, nimm unser "gekapseltes" Setup oder lass es.Ich hatte den Feuervogel bei meinem vorletzten Arbeitgeber auf einem Linux-Unterbau als VM Laufen.
Das ging bei ca. 25 Nutzern recht gut.
Cheers,
jsysde
Moin.
Boah, das treibt mich in den Wahnsinn - der Software-Hersteller verweist auf einen eher merkwürdigen Benchmark, der natürlich der VM eine miserable Performance attestiert. Auf der anderen Seite weigert sich der Hersteller, die DB auf einen Linux-Host, auf dem ausschließlich der Firebird läuft, zu portieren. Das wäre so nicht vorgesehen.
Könnt' ich grad platzen. Die HyperV-Hosts sind performant genug, um alle anderen Anwendungen (z.B. auch nen Exchange 2019) performant zu betreiben - ein Aufrüsten nur wegen eines besch*** programmierten Datenbankservers fällt also aus.
Hat noch jemand ne Idee dazu?
Danke.
Cheers,
jsysde
Boah, das treibt mich in den Wahnsinn - der Software-Hersteller verweist auf einen eher merkwürdigen Benchmark, der natürlich der VM eine miserable Performance attestiert. Auf der anderen Seite weigert sich der Hersteller, die DB auf einen Linux-Host, auf dem ausschließlich der Firebird läuft, zu portieren. Das wäre so nicht vorgesehen.
Könnt' ich grad platzen. Die HyperV-Hosts sind performant genug, um alle anderen Anwendungen (z.B. auch nen Exchange 2019) performant zu betreiben - ein Aufrüsten nur wegen eines besch*** programmierten Datenbankservers fällt also aus.
Hat noch jemand ne Idee dazu?
Danke.
Cheers,
jsysde