Gretchenfrage: Classic oder Superserver
Moderator: SYNERPY
-
- Beiträge: 399
- Registriert: Fr Mai 26, 2006 3:44 pm
- Wohnort: Velbert-Langenberg
Gretchenfrage: Classic oder Superserver
Gibt es Erfahrung egal ob Positiv oder Negativ mit
FB 2.5 Classic-Server?
Habe unter OpenSuSe 11.3 64Bit, Firebird 2.5.0 (Original Firebird Classic rpm; ) installiert und problemlos mit AvERP zum Laufen gebracht.
Restore eines 1.6 GB FB1.5-AvERP2009-BackUps klappte zügig, ebenso das Kompilieren aller Prozeduren und Trigger. Hier machten sich positiv die üppigen Ressourcen: 2 mal 4-Kern-Prozessor und 12GB RAM bemerkbar.
Etwas enttäuschend war die Arbeit mit AvERP mit einem gemessenem Performance-Gewinn von lediglich 30% bei bisher bemängelten Ladezeiten für häufig benutze Masken wie Artikelstamm, Auftrag-/Pos. - da zählt wahrscheinlich eher die Prozessor-Leistung des Clients zur Interpretation der Pascal-Scripte.
Nun wurde mir von einer Seite geraten, doch lieber auf den SuperServer umzusteigen.
Laut Firebird-Doc. wegen
Superserver: Single-Process aber kein Guardian unter LINUX
Classic: Supports multiprocessing out of the box
hatte ich mich für den Classic-Server entschieden.
(auch geprägt durch die ungenügende Multiprocessing-Unterstützung des FB 1.5 unter Windows)
Zurück zur Ausgangsfrage:
Gibt es Argumente gegen Verwendung des FB 2.5 CS unter LINUX ???
FB 2.5 Classic-Server?
Habe unter OpenSuSe 11.3 64Bit, Firebird 2.5.0 (Original Firebird Classic rpm; ) installiert und problemlos mit AvERP zum Laufen gebracht.
Restore eines 1.6 GB FB1.5-AvERP2009-BackUps klappte zügig, ebenso das Kompilieren aller Prozeduren und Trigger. Hier machten sich positiv die üppigen Ressourcen: 2 mal 4-Kern-Prozessor und 12GB RAM bemerkbar.
Etwas enttäuschend war die Arbeit mit AvERP mit einem gemessenem Performance-Gewinn von lediglich 30% bei bisher bemängelten Ladezeiten für häufig benutze Masken wie Artikelstamm, Auftrag-/Pos. - da zählt wahrscheinlich eher die Prozessor-Leistung des Clients zur Interpretation der Pascal-Scripte.
Nun wurde mir von einer Seite geraten, doch lieber auf den SuperServer umzusteigen.
Laut Firebird-Doc. wegen
Superserver: Single-Process aber kein Guardian unter LINUX
Classic: Supports multiprocessing out of the box
hatte ich mich für den Classic-Server entschieden.
(auch geprägt durch die ungenügende Multiprocessing-Unterstützung des FB 1.5 unter Windows)
Zurück zur Ausgangsfrage:
Gibt es Argumente gegen Verwendung des FB 2.5 CS unter LINUX ???
Gruß U.Schmidt
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024
-
- Beiträge: 1295
- Registriert: Fr Jul 28, 2006 9:13 am
Frage: setzen Sie dann in der firebird.conf auf Mehrprozessor / Mehrkern Systemen die CPUAffinityMask auf einen bestimmten Wert? Und vor allem, gelten diese Erfahrungen gleichermaßen für Windows und Linux serverseitig?
Gruß
Michael
Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
-
- Beiträge: 515
- Registriert: Di Okt 19, 2004 5:45 am
- Wohnort: Diepholz
Achtung:
Bei einer Installation eines rpm-Paketes wird firebird als Classic-Server installiert.
Will man auf Superclassic-Server umsteigen, dann kann man das mit dem mitgelieferten Skript changeMultiConnectMode.sh erledigen.
Bei Mehrkernprozessoren und mehreren Benutzern ist auf jeden Fall der Superclassic-Server zu empfehlen, da jede connection (User) 100% CPU Leistung zur Verfügung hat.
Wir haben hier einen Server mit Dual-Sixcore, bedeutet unter Linux das 24 Kerne zur Verfügung stehen.
Es können also im Idealfall 24 User mit je 100% CPU-Leistung arbeiten.
Bei einer Installation eines rpm-Paketes wird firebird als Classic-Server installiert.
Will man auf Superclassic-Server umsteigen, dann kann man das mit dem mitgelieferten Skript changeMultiConnectMode.sh erledigen.
Bei Mehrkernprozessoren und mehreren Benutzern ist auf jeden Fall der Superclassic-Server zu empfehlen, da jede connection (User) 100% CPU Leistung zur Verfügung hat.
Wir haben hier einen Server mit Dual-Sixcore, bedeutet unter Linux das 24 Kerne zur Verfügung stehen.
Es können also im Idealfall 24 User mit je 100% CPU-Leistung arbeiten.
MfG
KDP
----------------------------------------------------------
Durch den Computer spart der Mensch so viel Zeit,
dass er diese am Computer verbringen kann.
KDP
----------------------------------------------------------
Durch den Computer spart der Mensch so viel Zeit,
dass er diese am Computer verbringen kann.
-
- Site Admin
- Beiträge: 2673
- Registriert: Di Feb 10, 2004 5:48 am
- Wohnort: Bayreuth
-
- Beiträge: 1295
- Registriert: Fr Jul 28, 2006 9:13 am
Danke für die Info ... und zum Glück bin ich nicht der einzige, der das mit dem Dual-Sixcore nicht verstanden hat
Das mit dem Superclassic habe ich nur mal am Rande erwähnt auch nicht verstanden. Anstatt sich endlich für EINE Architektur zu entscheiden und diese optimal weiter zu entwickeln, macht man bei Firebird jetzt noch eine dritte Dose auf ...
Gruß
Michael
![Question :?:](./images/smilies/icon_question.gif)
![Evil or Very Mad :evil:](./images/smilies/icon_evil.gif)
Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
-
- Beiträge: 515
- Registriert: Di Okt 19, 2004 5:45 am
- Wohnort: Diepholz
Hallo admin,
Unser Server hat 2x Intel x5680, das bedeutet je Prozessor mit 6 Kernen und 12 Threads.
Somit können 24 Threads mit je 100% ausgelastet werden.
das ist richtig. Ich hatte mich etwas unglücklich ausgedrückt.admin hat geschrieben: Dual-Sixcore = 12, oder?
Unser Server hat 2x Intel x5680, das bedeutet je Prozessor mit 6 Kernen und 12 Threads.
Somit können 24 Threads mit je 100% ausgelastet werden.
MfG
KDP
----------------------------------------------------------
Durch den Computer spart der Mensch so viel Zeit,
dass er diese am Computer verbringen kann.
KDP
----------------------------------------------------------
Durch den Computer spart der Mensch so viel Zeit,
dass er diese am Computer verbringen kann.
-
- Site Admin
- Beiträge: 2673
- Registriert: Di Feb 10, 2004 5:48 am
- Wohnort: Bayreuth
Nicht ganz. Unter FB 3 wird dann der SuperServer multithreadingfähig werden. Der SuperClassic ist der erste Schritt in diese Richtung, also der Versuch Classic und Super zu verbinden. Endziel ist der Wegfall von Super und Classic. Sogesehen hat man sich schon auf eine Architektur geeinigt und wird diese dann vorantreiben, nur eben dass diese Architektur erst erschaffen werden musste.miboe hat geschrieben:...macht man bei Firebird jetzt noch eine dritte Dose auf
-
- Beiträge: 399
- Registriert: Fr Mai 26, 2006 3:44 pm
- Wohnort: Velbert-Langenberg
Classic Server ist die einzige Wahl gegen langlaufende Quer
Bevor die Diskussion zu akademisch wird
Wenn der SuperServer einen Kern zu 100% mit einer Query auslastet warten allen anderen bis diese fertig ist. Gibt es länger laufende Queries hilft nur der ClassicServer.
Vom Hybrid-SuperClassic gibt es hinreichend Hinweise in Foren, das die Stabiltät nicht immer gegeben ist.
CpuAfinity wird unter LINUX nicht ausgewertet - nur unter Windows.
Unter LINUX bringt ein Experimentieren mit dem Firebird Cache gar Nichts - LINUX als Betriebssystem geht mit dem Filesystem-Cache effektiver um - es gibt ja auch mehr LINUX als Firebird-Entwickler....
Unbedingt die Firebird 2.5 Release Notes zum Caching speziell FileSystemCacheThreshold beachten! Auf aktuellen POSIX-Systemen mit schnellen Platten sollte FileSystem-Caching mit dem Default Parameter von 65536 Pages größer als die Anzahl Pages der Datenbank seien!!
Ich bin der Empfehlung hier im Forum gefolgt und habe auf einer 8-Kern-Maschine den Firebird 2.5 Superserver gegen den zuvor ausgewählten Classic Server ausgetauscht.
Jetzt kann ich aber sagen, das die einzige Wahl zum Betrieb von AvERP auf Mehrkern-Maschinen, wenn AvERP hinreichend mit Daten gefüllt ist und länger laufende Queries absetzt, der Classic Server ist.
Wird der Superserver zu 100% ausgelastet, warten alle Anderen Sitzungen!
Wir hatten ganz unglücklich den Job Artikelstatistik um 14:00 Uhr laufen lassen. Vor Update auf die 2011/2-er-Version lief der Job halt 1 bis 2 Minuten und kam dem Bedürfnis der Anwender entgegen - täglich auf einem aktuellen Artikelkontext zugreifen zu können.
Nach Update läuft der Job um die 4 Stunden - das neu hinzugekommene Ermitteln der Jahresverbräuche über alle verbauten Teile bei einem Maschinenbauer dauert halt etwas länger....
Damit hatten man bis zum Erreichen dieses Kenntnisstandes den SuperServer regelmäßig abzuschießen - geht beim SuperServer bei nur einem über inet.d-gesteuerten Prozeß ja auch einfacher als auf dem ClassicServer
Diese Erfahrungen gesammelt mit:
Averp 2011.A02 / 2012.B08
auf
SUSE 11.3 64 bit
8-Kern zu 2.26 GHZ
12 GB - 4 GB für 4 virtuelle XP
(PS: 100.000 Artikel einem AvERP-Client
auf eine virtuelles WIN-XP rüberzuschicken
lastet auch eine weitere Client genutzte CPU einige Minuten zu 100% aus!)
Gruß
U.Schmidt
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
Wenn der SuperServer einen Kern zu 100% mit einer Query auslastet warten allen anderen bis diese fertig ist. Gibt es länger laufende Queries hilft nur der ClassicServer.
Vom Hybrid-SuperClassic gibt es hinreichend Hinweise in Foren, das die Stabiltät nicht immer gegeben ist.
CpuAfinity wird unter LINUX nicht ausgewertet - nur unter Windows.
Unter LINUX bringt ein Experimentieren mit dem Firebird Cache gar Nichts - LINUX als Betriebssystem geht mit dem Filesystem-Cache effektiver um - es gibt ja auch mehr LINUX als Firebird-Entwickler....
Unbedingt die Firebird 2.5 Release Notes zum Caching speziell FileSystemCacheThreshold beachten! Auf aktuellen POSIX-Systemen mit schnellen Platten sollte FileSystem-Caching mit dem Default Parameter von 65536 Pages größer als die Anzahl Pages der Datenbank seien!!
Ich bin der Empfehlung hier im Forum gefolgt und habe auf einer 8-Kern-Maschine den Firebird 2.5 Superserver gegen den zuvor ausgewählten Classic Server ausgetauscht.
Jetzt kann ich aber sagen, das die einzige Wahl zum Betrieb von AvERP auf Mehrkern-Maschinen, wenn AvERP hinreichend mit Daten gefüllt ist und länger laufende Queries absetzt, der Classic Server ist.
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
Wird der Superserver zu 100% ausgelastet, warten alle Anderen Sitzungen!
Wir hatten ganz unglücklich den Job Artikelstatistik um 14:00 Uhr laufen lassen. Vor Update auf die 2011/2-er-Version lief der Job halt 1 bis 2 Minuten und kam dem Bedürfnis der Anwender entgegen - täglich auf einem aktuellen Artikelkontext zugreifen zu können.
Nach Update läuft der Job um die 4 Stunden - das neu hinzugekommene Ermitteln der Jahresverbräuche über alle verbauten Teile bei einem Maschinenbauer dauert halt etwas länger....
Damit hatten man bis zum Erreichen dieses Kenntnisstandes den SuperServer regelmäßig abzuschießen - geht beim SuperServer bei nur einem über inet.d-gesteuerten Prozeß ja auch einfacher als auf dem ClassicServer
Diese Erfahrungen gesammelt mit:
Averp 2011.A02 / 2012.B08
auf
SUSE 11.3 64 bit
8-Kern zu 2.26 GHZ
12 GB - 4 GB für 4 virtuelle XP
(PS: 100.000 Artikel einem AvERP-Client
auf eine virtuelles WIN-XP rüberzuschicken
lastet auch eine weitere Client genutzte CPU einige Minuten zu 100% aus!)
Gruß
U.Schmidt
-
- Beiträge: 399
- Registriert: Fr Mai 26, 2006 3:44 pm
- Wohnort: Velbert-Langenberg
ClassicServer LINUX /etc/xinetd.conf instances !!
Ergänzender Erfahrungswert, der Nachfolgern möglicherweise schmerzliche Probleme vermeiden hilft:
Wenn der firebird keine neuen connections zuläßt:
"When client tries to connect and limit is reached, it would get an error like this one: Connection rejected by remote interface."
Betrachte: http://www.firebirdfaq.org/faq161/
Problem gelöst über erhöhen instances (viel)> 30
#
# xinetd.conf
#
# Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany.
# Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany.
#
defaults
{
log_type = FILE /var/log/xinetd.log
log_on_success = HOST EXIT DURATION
log_on_failure = HOST ATTEMPT
# only_from = localhost
instances = 30
Wenn der firebird keine neuen connections zuläßt:
"When client tries to connect and limit is reached, it would get an error like this one: Connection rejected by remote interface."
Betrachte: http://www.firebirdfaq.org/faq161/
Problem gelöst über erhöhen instances (viel)> 30
#
# xinetd.conf
#
# Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany.
# Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany.
#
defaults
{
log_type = FILE /var/log/xinetd.log
log_on_success = HOST EXIT DURATION
log_on_failure = HOST ATTEMPT
# only_from = localhost
instances = 30
Gruß U.Schmidt
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024