Announcement

**Thomas Steinmaurer** · 01.12.2003, 15:29

Hallo Jochen, 
gleich mal vorweg, Firebird kann auch auf "alter" Hardware laufen (z.B. wenig RAM - so steht 16 MB im Firebird 1.5 Factsheet drinnen ;-), schwache CPU, ...). Wie nun der optimale Server f�r eine Firebird Installation aussehen kann, h�ngt nat�rlich sehr stark vom Einsatzzweck ab. 
Beginnen wir mal mit der zu verwendenden Architektur von Firebird. Wie Du vermutlich wei�t gibt es den Classic und den Super Server.
 
Der SuperServer ist ein multi-threaded Proze�, d.h. jede Verbindung zur Datenbank wird innerhalb des Serverprozesses als eigener Thread behandelt. So wird z.B. ein gemeinsamer Cache pro Datenbank verwendet, d.h. der Ressourcenverbrauch ist beim SuperServer in der Regel geringer als bei Classic, jedoch besitzt der SuperServer derweil noch den Nachteil, dass dieser nicht SMP/HT-tauglich ist, d.h. wenn Du den Nutzen aus mehreren CPUs ziehen m�chtest, dann ist auch in Firebird 1.5 der SuperServer noch die falsche Wahl. Ein Vorteil des SuperServers ist vielleicht, dass dieser einfacher zu administrieren ist, weil die Services API vollst�ndig verf�gbar ist, und auf dieser API setzen eigentlich alle Admin/Dev-Tools auf, um den Firebird Server zu administrieren, d.h. z.B. Benutzer anlegen, Backup/Restore, Validierung, usw ... 
Der Classic Server hingegen erzeugt f�r jede Verbindung einen eigenen Proze�, und daher ist diese Architektur von Grund aus SMP/HT-tauglich, weil es dem OS �berlassen ist, wie die unterschiedlichen Prozesse (sprich Datenbankverbindungen) auf mehrere (logische) CPUs aufgeteilt werden. Gerade in einer Umgebung mit sehr vielen aktiven Verbindungen ist der Classic Server besser skalierbar, sprich man kann z.B. eine sehr ressourcenintensive Abfrage ausf�hren, ohne damit die anderen Verbindungen ehrheblich zu blockieren. Der Nachteil von Classic ist, dass dieser erheblich mehr Ressourcen ben�tigt, da nicht ein Cache pro Datenbank, sondern pro Verbindung verwaltet wird, d.h. hier mu� man immer im Hinterkopf haben, dass z.B. das hinaufsetzen des Page Buffers jede Client-Verbindung betrifft, und man damit schneller mal an die Grenzen des verf�gbaren Hauptspeichers gelangt. Ein weiterer Nachteil ist, dass in Firebird 1.5 Classic die Services API nur teilweise vorhanden ist (dies ist neu in 1.5, d.h. z.B. in 1.0 ist unter Classic die Services API gar nicht vorhanden), somit kann es sein, dass Du f�r bestimmte administrative Zwecke die Kommandozeilentools verwenden mu�t, und nicht auf ein komfortables Admin/Dev-Tool zur�ckgreifen kannst. 
Bis jetzt viel Geschwafel, aber diese Unterschiede sind wichtig, dass man diese kennt. Das sch�ne an der Sache ist, dass man z.B. mit dem SuperServer anfangen kann, und sp�ter zum Classic migrieren kann, ohne dass man z.B. an der Datenbankdatei etwas �ndern muss. Einfach SuperServer deinstallieren, und Classic installieren. Wenn man die Newsgroups verfolgt, dann verwendet eigentlich jeder (inklusive die Entwickler), der ein etwas gr��eren System mit Firebird unter Linux verwendet, die Classic Architektur bevorzugt, diese zwar ressourcenintensiver ist (aber was kostet heute schon noch der Hauptspeicher), weil diese einfach besser skalierbar ist. Firebird 1.5 ist auch besser bei der Verwendung des Hauptspeichers geworden. Die meisten kennen z.B. die PageBuffers, aber 1.5 bietet nun z.B. auch einen Konfigurationsparameter um z.B. den max. zu verwendenden Speicher f�r das In-Memory-Sort Modul zu definieren. D.h. es gibt ein paar Tweaks, damit Firebird sich einfach etwas mehr RAM krallt. 
Der schlimmste Bottleneck bei so einer Installation ist aber in der Regel das I/O System, d.h. Zugriffe auf die Festplatte sind in der Regel das langsamste im System, und danach richtet sich auch die Performance. D.h., bei sehr intensiven HDD-getriebenen Aufgaben, ist ein RAID - nicht nur aus Sicht der Datensicherheit - unbedingt zu empfehlen, da man besser in ein schnelleres HDD-System investiert, als in eine hypermoderne CPU. 
Die Antwort zu wieviel RAM h�ngt von der verwendeten Architektur ab. Unter SuperServer kann man max. zu verwendenden Hauptspeicher f�r das Caching pro Datenbank wie folgt berechnen:
<pre>
PageSize * PageBuffers
</pre>
F�r Classic:
<pre>
PageSize * PageBuffers * Anzahl der Verbindungen
</pre>
D.h. Du siehst, mit Classic schadet es nicht, wenn man einiges mehr an RAM reinsteckt. Z.B. bei einer DB PageSize von 4096 Bytes und PageBuffers von 2.048 Bytes und 35 gleichzeitig aktiven Verbindungen, kann der Firebird Server unter Classic "theoretisch" ca. 280 MB f�r das Caching f�r die eine Datenbank verwenden. Mit diesen Parametern kann man dann spielen, z.B. viele Leute verwenden eine PageSize von 8192 Bytes, ... Bei SuperServer fehlt der Faktor der aktiven Verbindungen weg, weil der Cache pro Datenbank und nicht pro Verbindung verwaltet wird.
 
Das sch�ne ist, man f�ngt mal klein an, und baut dann kontinuierlich die Sache aus, durch z.B. mehr RAM oder die Verwendung einer unterschiedlichen Firebird Architektur.
 
Ich hoffe das hilft Dir etwas weiter.
 
Sch�ne Gr��e, 
Thoma

**Torsten Grundke** · 01.12.2003, 17:38

Hallo Thomas,

das ist ja eine superausf�hrliche Antwort. Meine Antwort w�re mit Sicherheit wesentlich k�rzer ausgefallen. ;-)

Gru�

Torste

**Thomas Steinmaurer** · 02.12.2003, 13:50

Hallo Torsten, 
ich fa� das einfach mal als Kompliment auf. ;-)
 
Sch�ne Gr��e, 
Thoma

**Jochen Reichenberg** · 02.12.2003, 14:20

Hallo Thomas und Torsten,

zuerst einmal: Vielen Dank f�r die wirklich ausf�hrliche Antwort. Da ich davon ausgegangangen bin, das Torsten antwortet, hab' ich die Frage etwas knapp gehalten. Torsten hatte mir zu FB bereits ein paar Fragen beantwortet.

Nun ja, da wir einen neuen Server f�r FB anschaffen, hilft es mir nicht wirklich weiter.
Diesen m�chte ich nicht von Anfang an unterdimensionieren. Aber RAID kommt auf jeden Fall rein. Ansonsten wird es wohl 'untere Mittelklasse' werden, mit Option zum Aufr�sten (sprich erst mal eine CPU + 1 GB RAM).

Ich h�tte auch schon fr�her geantwortet, aber heute morgen hat's hier ein paar Probleme gegeben, an denen ich bis gerade eben 'gebrasselt' habe.

Danke Jochen

P.S. Darfst Du definitiv als Kompliment auffassen. :

**Thomas Steinmaurer** · 02.12.2003, 14:29

Hallo Jochen, 
Torsten, Lucas und ich teilen uns hier die Arbeit, aber irgendwer ist in der Regel immer da. ;-)) 
RAID ist gut, aber damit man auch einen Performancegewinn erzielen kann, reicht es nicht, wenn es eine reine RAID 1 (aka Mirroring) L�sung ist. D.h., wenn m�glich sollte es schon RAID 5 sein, dies bedeutet h�here Durchsatzraten + Ausfallsicherheit (Mirroring). Ansonsten bist Du mit einer CPU + 1GB RAM mal gut bedient, sofern sich z.B. eine zweite CPU hineinstecken l��t. Wie gesagt, ich kenne Deine genauen Anforderungen nicht, aber etwas Spielraum noch oben w�rde ich mir an Deiner Stelle schon offen lassen. 
Ein konkretes Beispiel bzgl. SuperServer und Classic. Wir entwickeln hier am Institut derzeit unseren neuen Intra/Internet Auftritt mit Firebird als Backend. Da SuperServer einfacher zu administrieren ist (auch f�r die Studenten), haben wir nun einfach mal SuperServer unter Linux laufen, und f�r den Produktionsbetrieb werden wir dann auf Classic umsteigen. 
Sch�ne Gr��e, 
Thoma

**Torsten Grundke** · 02.12.2003, 15:46

Hallo Thomas,

Du darfst das auf jeden Fall als Kompliment auffassen. Das Lucas hier besonders aktiv ist kann man aber nicht gerade sagen. Daf�r ist er an andere Stelle sehr aktiv (im Gegensatz zu mir). Sogesehen ist es schon eine "Arbeitsteilung". Und Du bist hyperaktiv. Im beantworten von Fragen im Entwickler Forum beschr�nke ich mich aber nicht nur auf IB/FB.

In der Firma hatten wir bis vor kurzem unter Linux den SS 1.02 laufen (ohne mein Wissen - lokal l�uft bei mir 1.5 classic bzw. SS unter Windows). Mit dem Linux - SS haben wir bei umfangreichen Skripts erhebliche Probleme gehabt. Der Server ist beim Disconnect abgeschmiert und hat gleich die Datenbank mit ins Nirvana genommen. Beim Classic-Server geht der Disconnect zwar auch gelegentlich schief aber die Datenbank wird nicht besch�digt. Mit FB 1.5 hatte ich leider noch keine Zeit f�r umfangreiche Tests.

Tschau

Torste

**Jochen Reichenberg** · 02.12.2003, 16:01

Hallo Thomas,

selbstverst�ndlich RAID 5, (sogar SCSI). Aufr�stung einer zweiten CPU ist m�glch, Speicher aufr�stbar auf 4 GB (ECC-Speicher). Auf das RAID-Array soll nur die Datenbank. Deshalb wird es erst mal mit drei Platten (U160 oder U320, 36GB, 10000 U/Min) auskommen m�ssen.

Zu den Anforderungen kann ich nicht so viel sagen, da ich die bestehenden Paradox-Datenbanken nicht als Ma�stab nehmen kann. Ich habe bei den Paradox Tabellen auf etliches verzichtet, um das Ganze halbwegs schnell zu halten.

Ich denke die Hauptarbeit f�r die Firebird wird in der Bereitstellung bestimmter Daten bestehen, die aber zum gro�en Teil aus unserer informix DB stammen. Diese Tabelle besteht im Schnitt aus 1000 bis 1500 Datens�tzen (knapp 40 Felder, inklusiv mehrerer gr��erer char Felder) und soll alle 5 Minuten komplett neu aufgebaut werden. Mit Paradox dauert das ca. 60 Sekunden, wobei die meiste Zeit tats�chlich f�r das Einf�gen der neuen Datens�tze verbraucht wird.

Danke nochmals und sch�ne Gr��e an Torsten,

Joche

**Torsten Grundke** · 02.12.2003, 16:23

Hallo Jochen,

sch�nen Gru� zur�ck.

Torste

**Thomas Steinmaurer** · 02.12.2003, 19:57

Hallo Jochen, 
dann hast Du einen Server, den sich vermutlich einige (viele) Personen f�r eine Firebird-Server-Installation w�nschen w�rden. ;-)
 
Sch�ne Gr��e, 
Thoma

Announcement

Firebird - auf welcher Hardware?

Firebird - auf welcher Hardware?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment