Firebird SuperClassic Performanceprobleme

[tsteinmaurer]

Ich hatte etwas ähnliches bei einer Troubleshooting Sache wo mir der Kunde in einer ersten Schilderung versichert hat, dass der andere/dezidierte vermeintlich schnellere Server brutal langsamer war, als eine ältere Kiste. Letztendlich hat sich herausgestellt, dass der RAID-Controller des Servers im Argen war. D.h. ich würde mir mit einem I/O Benchmark mal ansehen, ob es I/O-technisch zwischen den beiden keine groben Unterschiede gibt.

Das Problem mit dem Windows Cache unter 64-bit und Firebird ist in Firebird 2.5.x und 2.1.5+ gefixt. Bzgl. Firebird 32-bit vs. 64-bit kann ich mir ehrlich gesagt nicht vorstellen, dass es hier solch grobe Unterschiede geben soll.

SuperClassic, durch dessen Single-Prozessmodell, als 32-bit zu betreiben ist halt doch ein Kompromiss, da sich RAM Usage des Firebird Page Cache mit der Anzahl der Connections multipliziert. Wenn 32-bit, dann vielleicht doch lieber Classic, zumindest in Produktionsumgebungen.

[dataspider]

@Thomas,

ich habe das ganze auf 2 unterschiedlichen Servern getestet.
Der erste hatte nur 1 CPU, der zweite 16.
Die Server sind auch neuer als der alte, wo der Import schnell geht.

Ich habe allerdings nicht den Installer bemüht, sondern das ZIP - Kit kopiert und install_superclassic.bat (übrigens nach deiner Anleitung) den Service erzeugt.

Wenn ich dich richtig verstehe, brauche ich keine Anpassungen in der firebird.conf (FileSystemCacheThreshold, FileSystemCacheSize) vorzunehmen?

Frank

[tsteinmaurer]

Zitat:

Wenn ich dich richtig verstehe, brauche ich keine Anpassungen in der firebird.conf (FileSystemCacheThreshold, FileSystemCacheSize) vorzunehmen?

Mit Firebird 2.5 sehe ich jetzt keine unmittelbare Notwendigkeit. Sonst schau mal mit der Trace API wo die Zeit liegen bleibt.

[QuickAndDirty]

Wir haben massive Slowdowns erfahren, wenn auf dem Server Rechner ein DomainController betrieben wurde.
Auf solchen Rechnern lief Firebird wieder schnell, wenn man die Datenbank Datei und das Temp Verzeichnis auf eine andere Partition als die Betriebssystem Partition gelegt hat.
Es war ein Unterschied wie zwischen Himmel und Hölle. (Ist auch cool, wenn die Kunden auf einmal ob der vielfach schnelleren Arbeitsgeschwindigkeit am Telefon in Jubel ausbrechen...)

[dataspider]

Auf dem Server lief natürlich kein Domaincontroller.
Thomas und Holger haben schon recht. Ich habe mit verschiedenen Benchmark - Tools wie von Thomas Steinmaurer empfohlen - die Systeme verglichen.
Und tatsächlich bricht der Virtuelle Server besonders beim Schreiben von 4 k Blöcken gegenüber dem Altsystem (dedizierter Server) ein.
Er ist hier ca. 8 mal langsamer.
Wir betreiben die DB nun erst mal auf einem dedizierten Server.

An dieser Stelle erst mal vielen Dank für die Hinweise, besonders an Holger und Thomas.

Frank

[hstreicher]

Ich vermute mal ins Blaue hinein dass das RAID Array schuld ist ,

RAID packen die Daten in GROSSE Verwaltungeinheiten die sie dann jedesmal gesamt lesen oder schreiben müssen,
aus der einfachen 4KB PageSize der Datenbank macht der RAID Controller dann mal eben 64KB oder mehr die für jedes Update dann
gelesen und geschrieben werden müssen, bei einem 3 Disk RAID 5 wären das 96KB bei RAID10 würden dann sogar 128KB über die Leitung rauschen

siehe Eintrag StripeSize in dem als Beispielconfig angehängten Bild

hth Hannes