Firebird SuperClassic Performanceprobleme

[dataspider]

Hi,

ich habe auf einem neuen Server eine FB 2.52 Superclassic 64 bit installiert.
Bisher lief 2.15 Superserver 32 bit.

Hintergrund:

Mehrmals täglich werden Daten aus verschiedenen Systemen importiert.
Meist automatisch, bei Bedarf auch manuell.
Dabei ist die Datenmenge oft extrem hoch (bis zu 100.000 Datensätze, wobei nicht jeder importiert wird, aber geprüft).

Bisher war es so, das dieser Import (als EXE auf anderem Server) das Arbeiten stark behindert hat.
Auf dem Datenbankserver war dann 100% CPU - Last, und erst, wenn der Import beendet war, konnte man flüssig weiterarbeiten.

Jetzt - mit 2.52 Superclassic ist diese Problem behoben, dafür habe ich ein neues :(

Bisher dauerte ein Import z.B. 7 Minuten auf 2.15. Jetzt auf 2.52 dauert der gleiche Import 20 Minuten.
Auf dem neuen Server ist auch kaum CPU - Last zu verzeichnen.

Hat jemand eine Idee, woran das liegen kann?

Frank

[nahpets]

Bei dieser Konstellation wäre mein erster Blick in Richtung Festplattenanbindung.

Der Vorgang dürfte etliche Festplattenzugriffe erforderlich machen. Ist der langsamer als beim "alten" System, geht die Laufzeit in die Höhe, auch wenn der "neue" Server eigentlich leistungsfähiger ist.

Und wartet der "neue" Server auf die Festplatte, so kann die CPU mal ein Päuschen einlegen, die CPU-Last geht also runter.

Könnte ein Grund sein, muss aber nicht.

Andere Indexorganisation?
Mehr Full-Table-Scans erforderlich?
Könnte auch ein Grund sein.

Also mal nach den IO's schauen.

[IBExpert]

Hast du die Cache Buffers in der Datenbank bzw in der Firebird.conf angepasst? Der Superclassic hast als default 75, das ist viel zu wenig, der Superserver 2048

Bei Superclassic solltest du Mindestens 1000 einstellen, je nach verfügbarem Speicher und Anzahl Connections auch mehr

Einstellen für die DB geht in IBEpert für die DB im Menü Services.database properties oder mit gfix

Der Superclassic ist nur von Vorteil wenn du sehr schnelle Laufwerke hast, kaum CPU Last deutet auf langsame Platte hin

[Perlsau]

Ich würde mir das so erklären, vorausgesetzt, die Hardware ist dieselbe: Wenn bei der älteren FB-Version der Import so flott vonstatten ging, daß dadurch die CPU bis zum Anschlag ausgereizt wurde, könnte man das nur daduch beheben, daß man den Import langsamer gestaltet, ihm also nicht die höchste Priorität zuweist. Bei deiner neuen FB-Version scheint das der Fall zu sein (wodurch auch immer, es wurden bereits Cache- oder Buffer-Einstellungen erwähnt): Es verbleiben noch ausreichend CPU-Ressourcen für die Alltagsarbeit mit dem Server. Würdest du nun den Import beim neuen System wieder so beschleunigen, wie er zuvor beim alten war, hättest du mit ziemlicher Sicherheit wieder das alte Problem ... Die einzige Lösung, die mir einfällt, wäre ein schnellerer Rechner mit SSD-Platten.

[dataspider]

Zitat:

Zitat von IBExpert (Beitrag 1225250)

Hast du die Cache Buffers in der Datenbank bzw in der Firebird.conf angepasst?

Ja, habe ich mit IBExpert auf 5000 eingestellt.

Das komische dabei ist, dass z. B. Statistiken, welche vorher 60 Sekunden gedauert haben, jetzt nach 40 Sekunden fertig sind.

Aber ich habe mir das System noch mal angesehen.
Beim Blick in die Hardware habe ich XENSRV als Bezeichnung der Platte.
Bedeutet, es ist ein virtualisierter Server (Citrix).

Ich weiß nur, das es ein leistungsfähiges System (IBM Server - schnelle Platten mit RAID 10 ...) ist.

Frank

[dataspider]

Zitat:

Zitat von Perlsau (Beitrag 1225251)

Würdest du nun den Import beim neuen System wieder so beschleunigen, wie er zuvor beim alten war, hättest du mit ziemlicher Sicherheit wieder das alte Problem

Jein...

Der Superclassic kann mit allen CPU' s arbeiten. Ich habe momentan 8 zur Verfügung. Der Import bremst also nur noch eine Sitzung von 8.

Frank

[IBExpert]

Leistungsfähig mit anderer Software heisst leider noch lange nicht auch schnell mit Datenbanken und schon gar nicht schnell mit Firebird.

Und Virtualisierung ist für Datenbanken immer negativ! Das ist Fakt und das kann ich aufgrund richtig großer Systeme bei diversen Kunden
immer wieder feststellen. Du wirst auch niemand bei Oracle oder MSSQL finden, der bei absehbar hoher Last virtualisert, es sei denn er
hat keine Ahnung.

Probier einfach mal die gleiche Operation auf einem dedizierten System aus, möglichst i7 (3000 oder 4000 Serie) oder ähnlich leistungsfähig
mit sehr schneller Platte, besser SSD oder für Test auch Ramdisk und gleicher Firebird Version. Dann kannst du einen möglichen Referenzwert
definieren.

Kunden mit Servern, die 5-6 stellige Summen gekostet haben, standen meist mit ziemlich blödem Gesicht da, wenn mein Laptop schneller
war als deren High End Server, insbesondere wenn der dann im Multiusertest komplett eingebrochen ist.

Wichtiger als reine CPU Leistung ist die Latenzzeit beim Dateizugriff und wenn das bei Virtualisierung eine externe Storage ist, dann
kannst du das für Datenbanken vergessen, weil die eben nicht für für viele kleine wahlfreie Zugriffe auf kleine Pages optimal sind.
Das ist nichts anderes als Physik ...

Ist aber bei den meisten Läden mit superschlauen Administratoren nicht so einfach zu erklären, weil ja jeder glaubt das beste System
auf dem Markt gekauft zu haben und keiner zugibt, das die teure Kiste für den gewählten Zweck eine teure Fehlanschaffung war.

[dataspider]

Holger,

vielen Dank für die umfassende Aufklärung.
Ich werde heute die 2.5' er Version auf dem alten Datenbankserver installieren (wo bis jetzt die 2.15' er lief).
Dann habe ich den direkten Vergleich und weiß ganz sicher, dass es an der Virtualisierung liegt.

Frank

[dataspider]

Wie es aussieht, besteht das Problem nur bei dem 64 - bit Server.

Ich habe auf dem alten Server FB 2.52 32 bit installiert.
Import dauert nur 7 Minuten anstatt 22 - Alles im grünen Bereich.

Jetzt habe ich auf einer anderen dedizierten 64 bit Maschine mit FB 64 bit getestet.
Der gleiche Performance Einbruch.

Ich habe schon gelesen, dass es Probleme mit der Nutzung des Filesystem - Cache geben soll.
Kennt jemand das Problem und hat eine Lösung?

Frank

[Blup]

Bleib beim 32Bit-Server.
Es gibt nur wenige Gründe die für den Einsatz von 64Bit-Software sprechen (auch im Datenbankbereich).
Die Beschränkung auf 2(oder 3)GB Adressraum heist ja nicht das die Anwendung nicht mehr Speicher verwenden kann.

[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