Welche Hard- und Software ist für einen prof. Firebirdserver notwendig?

**IBExpert**

Moin,

ich hab in den letzten Wochen durch einige Kundenaufträge häufiger mal das Problem eine reproduzierbaren Firebird Benchmarks gehabt und dafür haben wir mittlerweile eine ganz gute Benchmark Lösung, die sowohl Multiuserbetrieb als auch Singleuser Betrieb gut abbildet. Man kann die Ergebnisse relativ kurz Zusammenfassen (alle Tests auf schnellen und aktuellen i7 CPUs):

-Bei extrem schnellen Datenträgern verliert man durch Virtualisierung bis zu 70% der Datenbankleistung (ja, wirklich, der Benchmark schafft virtualisiert nur ca. 1/3 der Leistung gegenüber dem gleichen Benchmark auf gleicher Hardware und OS ohne VMWare Virtualisierung. Extrem schneller Datenträger ist in diese Fall eine Ramdisk innerhalb bzw außerhalb der vm).

-Bei Betrieb der DB auf einer sehr schnellen SSD (SATA3 ocz Agility3 240 GB) verliert man durch Virtualisierung ca. 50% Leistung

-Bei Betrieb auf einer Festplatte ist der Unterschied zwischen Virtualisierung und Nicht Virtualisierung nicht so groß, ca. 10-20 %

-Ein paar Richtwerte des Benchmarks auf einem Intel i7, 32GB, 3TB HDD, 120 GB SATA3 SSD
-Betrieb ohne Virtualisierung 10 Clients auf Festplatte mit Superclassic ca. 900 opm (opm=Order pro minute, 1 opm entspricht ca. 15 inserts und updates und ca 30 selects)
-Betrieb ohne Virtualisierung 10 Clients auf ocz SSD mit Superclassic ca. 12000 opm
-Betrieb ohne Virtualisierung 10 Clients auf Ramdisk mit Superclassic ca. 45000 opm
-Betrieb ohne Virtualisierung 10 Clients auf Festplatte mit Superserver ca. 2200 opm
-Betrieb ohne Virtualisierung 10 Clients auf ocz SSD mit Superserver ca. 45000 opm
-Betrieb ohne Virtualisierung 10 Clients auf Ramdisk mit Superserver ca. 225000 opm
-Betrieb mit Virtualisierung 10 Clients auf ocz SSD mit Superserver ca. 22000 opm
-Betrieb mit Virtualisierung 10 Clients auf Ramdisk mit Superserver ca. 65000 opm

Was ich persönlich am wenigsten erwartet hatte: Den Bestwert hatte der Benchmark ohne Virtualisierung mit dem Superserver erreicht, obwohl 10 Clients parallel auf dem FB Server eingedroschen haben, der als Superserver ja nur eine CPU benutzt. Durch die erheblich höhere I/O Last des Superclassics hat sich der Vorteil der mehreren benutzten CPUs nicht positiv bemerkbar gemacht. Im Taskmanager sieht man auch erst bei ssd bzw ramdisk eine signifikante CPU Leistung beim Firebird Superclassic Server, weil der ansonsten fast nur auf den Datenträger wartet. Wer genauere Infos zu den Benchmarks haben möchte, der kann die benutzten Skripte gerne bei uns

hier bekommen.

Wir haben gerade eine Agility3 60 GB SSD von OCZ im Dauerbetrieb mit dem Benchmark am laufen und versuchen dabei, mal die Dauerhaltbarkeit zu eruieren, mal schauen wann die abraucht (wird aktuell mit 10 Clients am Superclassic mit ca. 150 TB pro Tag im Lesebetrieb und 80 TB pro Tag schreibend mißbraucht. Fakten sind da besser als Gerüchte

Bisher läuft das seit einigen Tagen ohne Probleme. Samsung gibt für die 830 Serie eine Schreibleistung von 9PBfür die 240gb Version an, das würden wir in ca. 110 Tagen erreichen. Schaun mer mal

OCZ hat zugesagt, das die bei Ausfall auf jeden Fall getauscht wird. Sobald möglich werden wir das auch noch mal mit den Enterprise PCIe SSDs testen, laut technischer Daten sollten die nahezu Ramdisk Speed erreichen und trotzdem sehr haltbar sein, nur leider auch sehr teuer (ab ca. 4000 €). Je nach Anzahl der wartenden User ist das aber sicherlich eine sehr gute Investition.

Fazit: CPU ist fast egal, da ist alles in der oberen Liga was intel oder amd aktuell absolut schnell genug, solange es nicht gerade ein Atom Prozessor ist, wenn man einen sehr schnellen Datenträger hat. Dermacht den Unterschied!

**mjustin**

Zitat von p80286:

Zitat von Furtbichler:

Ergo: Nutzen = 0, wenn eh nur eine DB/Anwendung vorhanden ist. Bei größeren Netzwerken macht sich dann die Flexibilität bemerkbar.

Mit dem Netzwerk hat dies erst einmal nichts zu tun.
Aber Du hast natürlich Recht, wenn es nur um eine Db/Anwendung geht brauchst Du keine VM.

Ausnahmen bestätigen die Regel

Auch wenn es nur eine DB und keine anderen Server (Webserver/Applicationserver) gibt, hat eine VM den enormen Vorteil, dass man Skalierung durch Start beliebig vieler weiterer Instanzen erreichen kann.

Das ist eines der Argumente dafür, ein System das gelegentlich Leistungsspitzen verkraften muss, in einer Cloud unterzubringen.

**jobo**

Zitat von mjustin:

Das ist eines der Argumente dafür, ein System das gelegentlich Leistungsspitzen verkraften muss, in einer Cloud unterzubringen.

Das ist in der Tat ein Nutzen, allerdings teuer erkauft, besonders wenn wirklich nur ein System virtualisiert wird.

Mal ab von der Cloudthematik nur zur Virtualisierung:
Wenn ich mich nicht ganz irre, liegt die Geschichte und Erfolg einer der größten VM Anbieter (VMWare) in der Vergangenheit als Hardwarelieferant (Speicherlösung) für Oracle DB.
Im Fall Oracle ist es bspw. die Lizensierung mittels CPU / Prozessorkernen die eine wichtige Rolle spielt.
Will (Muss) man hier Spitzenlasten berücksichtigen, hat man im Ergebnis ein teures, Enterprise lizensiertes System, das auf einer überdimensionierten Hardware großteils vor sich hin idelt.
Die Veränderungen in der (lowcost) Hardware-Architektur (i86 Multicore) durch thermische und physikalische Grenzen ist ein anderer Baustein der Virtualisierung. (Ein weiterer nebenbei die Tatsache, dass gängige Compiler bzw. Programmiertechniken nachwievor single thread basiert arbeiten und per se ein Multicore System nicht auslasten -können)
Virtualisierung rechnet sich so vor allem dann, wenn man mehrere solche Systeme fahren muss. Hier spart man allein mächtig an Oracle Enterprise Lizenzen. Einen verhältnismäßig kleinen Teil der Ersparnis kann man dann in die VM Lizensierung stecken.
Man hat in dieser Konstellation im Ergebnis Systeme, die eine Menge Vorteile bieten. Alle sind happy, außer Oracle.
Solche Systeme bestehen aber aus mindestens 2 Hosts, auf denen idR doch mehr als 1 System läuft.
Arbeitet man mit freien OS, stören hier die Kosten nicht. Arbeitet man mit Software, die nicht CPU basiert lizensiert werden, spielt dieser ganze Kostenapparat keine Rolle.
Usw. usw.

Meine Erfahrungen mit den kostenlosen VMware Server Produkten ist leider, dass sie mittlerweile reine Teaser sind, Spielzeug eben.

Unter diesen Aspekten ist der TE im Mittelstandsbereich mit einer klassischen Hardwarelösung nicht schlecht aufgehoben.

Zitat von p80286:

Mit dem Netzwerk hat dies erst einmal nichts zu tun.

Nastürlich nicht, ich meinte eher "Großes Netzwerk -> Viele Server-Anwendungen

Zitat von mjustin:

Auch wenn es nur eine DB und keine anderen Server (Webserver/Applicationserver) gibt, hat eine VM den enormen Vorteil, dass man Skalierung durch Start beliebig vieler weiterer Instanzen erreichen kann.

Wenn ich nur eine DB und keine anderen Server habe, dann habe ich 100% meines Servers für die Anwendung reserviert. Was will man da noch skalieren?

@jobo: Endlich verstanden,

Es dreht sich also u.A. um die Tatsache, das viele Serverlösungen die Hardware nicht auslasten können und daher eine geschickte VM-Strategie die Lösung herbeiführt.

Würde Geld keine Rolle spielen oder die Serverapplikationen die CPUs ausreizen, bräuchte man das nicht zu tun bzw. müsste dann eher nachdenken, wozu eine VM-Lösung gut ist (bei sehr wenigen Serveranwendungen).

Bezüglich des auszuwählenden RDBMS sollte man dann nicht auch z.B. PostGres in Betracht ziehen, das sich offenbar gut hinsichtlich Multicore skalieren lässt?

Die Benchmarks von IBExpert sind sehr interessant. Wie verhält sich Firebird im multi-CPU-Betrieb im Vergleich zu PostGres oder MSSQL?

**jobo**

Zitat von Furtbichler:

Es dreht sich also u.A. um die Tatsache, das viele Serverlösungen die Hardware nicht auslasten können und daher eine geschickte VM-Strategie die Lösung herbeiführt.

Naja, viele können es schon, lahme DB sind ja nicht selten

Es geht eher um die benötigte Resourcen Bandbreite. Die Anforderungen an das System sind ja dynamisch, u.U. sehr dynamisch (bspw. Monatsabschluss peak usw). Eine pure Hardwarelösung muss das leisten und ist demnach zu anderen Zeiten unterfordert, kostet aber trotzdem (z.B. Oracle CPU Lizenzen). Virtualisierung schafft die Möglichkeit, freie Kapazität anderen Systemen zur Verfügung zu stellen.

Zitat von Furtbichler:

Bezüglich des auszuwählenden RDBMS sollte man dann nicht auch z.B. PostGres in Betracht ziehen, das sich offenbar gut hinsichtlich Multicore skalieren lässt?

Ich will nicht sagen, das Oracle schlecht skaliert. Es spielt bei der Virtualisierung eine besondere Rolle (Mutterrolle sozusagen), weil es CPU basiert lizensiert wird.
Auf einer 128 CPU Maschine kann ich per Virtualisierung ein System schaffen, für das ich nur eine 2-CPU-Oracle Enterprise Lizenz zahle. Installiere ich das direkt auf der 128 CPU Maschine, muss ich alle CPU lizensieren (Kostet vermutlich einen 6er im Lotto).
Diese ganze Thematik spielt bei der Virtualisierung von kostenloser Software (Firebird, Postgres) überhaupt keine Rolle!

Zitat von jobo:

Es geht eher um die benötigte Resourcen Bandbreite. Die Anforderungen an das System sind ja dynamisch, u.U. sehr dynamisch (bspw. Monatsabschluss peak usw). Eine pure Hardwarelösung muss das leisten und ist demnach zu anderen Zeiten unterfordert, kostet aber trotzdem (z.B. Oracle CPU Lizenzen). Virtualisierung schafft die Möglichkeit, freie Kapazität anderen Systemen zur Verfügung zu stellen.

Also konfiguriert man wöchentlich/täglich? Oder lässt das machen, denn es gibt ja mittlerweile für alles eine App.

**mjustin**

Zitat von jobo:

Zitat von mjustin:

Das ist eines der Argumente dafür, ein System das gelegentlich Leistungsspitzen verkraften muss, in einer Cloud unterzubringen.

Das ist in der Tat ein Nutzen, allerdings teuer erkauft, besonders wenn wirklich nur ein System virtualisiert wird.

Niemand wird eine Private Cloud betreiben um ein einziges System von 1 auf 100 CPUs skalieren zu können

Vorteile gibt es natürlich nur, wenn sich viele eine Cloud teilen können, und Spitzenlast halbwegs gleichmäßig verteilt auftritt, oder sogar planbar ist (man also CPU- oder RAM Zuteilung tageszeitabhängig für geplante Jobs steuern kann). ... Ein Hauptgrund für die Einführung von Virtualisierung ist auch der Stromspareffekt (und daran gekoppelt weniger Abwärme).

**jobo**

Zitat von mjustin:

Niemand wird eine Private Cloud betreiben um ein einziges System von 1 auf 100 CPUs skalieren zu können

Natürlich sollte das niemand machen, es ist aber letztlich das Thema hier geworden. Denn eigentlich hat der TE genau davon: "1 System" gesprochen und anschließend das ganze Virtualualisierungsthema um die Ohren (Augen) gehauen bekommen.
Ich habe es natürlich auch Größenordnungen genommen, die die Problematik verdeutlichen.

Was die Konfigurationsmöglichkeiten der kostenpflichtigen VMWare Produkte angeht kann ich leider nichts beitragen, da wir sie aus Kostengründen nicht einsetzen. Eine Online oder Schedule Priorisierung, Taktrate, etc. sollte aber minimal möglich sein.
Viel naheliegender ist- wie schon genannt- die "Paarung" von Systemen mit gegenläufigen Peaks.

Vielleicht gibt es aber durchaus Prodsysteme, wo ständig (nach)geregelt wird.
"Scotty, lenken Sie alle Energie auf die Bugschirme!"
"ey ey captain!"

**vagtler**

Zitat von jobo:

[...] Denn eigentlich hat der TE genau davon: "1 System" gesprochen und anschließend das ganze Virtualualisierungsthema um die Ohren (Augen) gehauen bekommen. [...]

Naja, ganz genau genommen hat der TE selbst in seinem Eröffnungsbeitrag das Virtualisierungsthema angesprochen:

Zitat von Chemiker:

[...] der FB-Server soll in eine virtuelle Maschine laufen [...]

Von "um die Ohren (Augen) gehauen bekommen" kann also nicht die Rede sein.

**p80286**

Auch wenn es es unfair ist die ganze Arbeit so zu reduzieren

Zitat von IBExpert:

Fazit: CPU ist fast egal, da ist alles in der oberen Liga was intel oder amd aktuell absolut schnell genug, solange es nicht gerade ein Atom Prozessor ist, wenn man einen sehr schnellen Datenträger hat. Dermacht den Unterschied!

Noch ein wenig Speicher dazu gepackt, und es geht.

Gruß
K-H