Gretchenfrage: Classic oder Superserver

Einsatz von AvERP mit Linux als Server- und/oder Anwendungs-OS

Moderator: SYNERPY

Antworten
UliS
Beiträge: 392
Registriert: Fr Mai 26, 2006 3:44 pm
Wohnort: Velbert-Langenberg

Gretchenfrage: Classic oder Superserver

Beitrag von UliS » Fr Feb 18, 2011 5:57 pm

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 ???
Gruß U.Schmidt
http://averpen4dummies.blogspot.de/

Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation

aktuelle Erkenntnisse mit:
Software-Version 6.7.9.0 - 14.02.2019
GDB 2019.01

admin
Site Admin
Beiträge: 2673
Registriert: Di Feb 10, 2004 5:48 am
Wohnort: Bayreuth

Beitrag von admin » So Feb 20, 2011 2:28 pm

Wir haben bessere Erfahrungen mit dem SuperServer und lassen auch Installationen mit 80 Usern auf den SuperServer laufen.

miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe » Mi Mai 11, 2011 7:16 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
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

festus01
Beiträge: 515
Registriert: Di Okt 19, 2004 5:45 am
Wohnort: Diepholz

Beitrag von festus01 » Mi Mai 11, 2011 7:56 am

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.
MfG

KDP

----------------------------------------------------------
Durch den Computer spart der Mensch so viel Zeit,
dass er diese am Computer verbringen kann.

admin
Site Admin
Beiträge: 2673
Registriert: Di Feb 10, 2004 5:48 am
Wohnort: Bayreuth

Beitrag von admin » Do Mai 12, 2011 2:38 pm

CPU-Affinity setzen wir nicht.

Dual-Sixcore = 12, oder?

Mit dem SuperClassic hatten wir Probleme bzgl. der Stabilität. Auch war ein Verändern von Prozeduren und Triggern nicht möglich, wenn Benutzer eingeloggt waren.

miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe » Do Mai 12, 2011 6:04 pm

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 ... :evil:

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

festus01
Beiträge: 515
Registriert: Di Okt 19, 2004 5:45 am
Wohnort: Diepholz

Beitrag von festus01 » Fr Mai 13, 2011 5:10 am

Hallo admin,
admin hat geschrieben: Dual-Sixcore = 12, oder?
das ist richtig. Ich hatte mich etwas unglücklich ausgedrückt.
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.

admin
Site Admin
Beiträge: 2673
Registriert: Di Feb 10, 2004 5:48 am
Wohnort: Bayreuth

Beitrag von admin » Fr Mai 13, 2011 9:42 am

miboe hat geschrieben:...macht man bei Firebird jetzt noch eine dritte Dose auf
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.

UliS
Beiträge: 392
Registriert: Fr Mai 26, 2006 3:44 pm
Wohnort: Velbert-Langenberg

Classic Server ist die einzige Wahl gegen langlaufende Quer

Beitrag von UliS » Fr Mai 13, 2011 5:32 pm

Bevor die Diskussion zu akademisch wird :roll:

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

UliS
Beiträge: 392
Registriert: Fr Mai 26, 2006 3:44 pm
Wohnort: Velbert-Langenberg

ClassicServer LINUX /etc/xinetd.conf instances !!

Beitrag von UliS » Mi Sep 28, 2011 11:15 am

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
Gruß U.Schmidt
http://averpen4dummies.blogspot.de/

Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation

aktuelle Erkenntnisse mit:
Software-Version 6.7.9.0 - 14.02.2019
GDB 2019.01

Antworten