FB 2.5 Classic-Server?
Diese Frage stellte ich im Februar 2011 im AvERP-Forum LINUX
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)
Aber Versuch macht klug!!
Nachdem AvERP auf den SuperServer den Eindruck vermittelt hat: Es geht gar nichts mehr -
Administrator sollte den Server booten, damit mit AvERP weitergearbeitet werden kann,
bin ich zu dem Schluß gekommen, daß auf Mehrkern-Maschinen der Firebird-ClassicServer das Maß aller Dinge ist:
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.
Heute muß ich ergänzen: auch der Firebird-ClassicServer hat in der Version 2.5.0 Bugs und Engpässe.
Unbedingt Firebird 2.5.1 einsetzen! Die Bugfixees zur Version 2.5.0 beheben das Problem:
Ein Prozeß blockiert die Lock-Tabelle - möglicherweise erzeugt eine nicht ordentlich beendet Transaktion einen Lock auf Daten - und kein anderer Firebird-Prozeß kann noch auf Daten zugreifen
-genau wie der SuperServer hat der ClassicServer einen Bottleneck, der verhindert, daß ordentlich auf AvERP gearbeitet werden kann,
- die typische Situation, wenn mal wieder ein Server Down-Up gefordert wird.
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!)
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
Keine Kommentare:
Kommentar veröffentlichen