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 von IBExpert:

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 von Perlsau:

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.