Firebird bei Masseninsert (DBPump) seeeehr langsam

[Lemmy]

Hallo,

bei einer Firebird-Anwendung werden Stammdaten bei den Kunden verteilt/aktualisiert, in dem die Stammdaten in einer eigenen fdb an die Kunden geliefert werden und diese Daten dann per DataPump (von UIB, das eigentlich verdammt schnell ist) in die andere DB übernommen.

Wir haben jetzt immer wieder den Fall, dass dieses Update sehr lange braucht, inzwischen auch einen Rechner bei uns im Haus. Da haben wir dann festgestellt, dass beim Schreiben der Daten diese mit ca. 400-500 kB/s auf die HDD tröpfeln (zippen einer größeren Datei läuft mit 8-10 MB/s, also ca. 20x schneller).

Das Verhalten lässt sich auf der Maschine unter Win7 und auch unter WIn XP (in einer virtuellen Maschine) reproduzieren.

Wir haben auf unseren Backup-Restore-Zyklus nach dem DataPump mal verzichtet um in eine schon große DB zu schreiben ob evtl. die Dateivergrößerung ne Rolle spielt, aber ohne Erfolg.

Definierte Indizes bei den betroffenen Tabellen spielen keine Rolle.

Ich bin mit meinem Latein jetzt am Ende. Hat mir jemand noch nen Tipp was wir probieren können? Ich will jetzt mal einen Masseninsert mit isql versuchen, um ein Problem der verwendeten Bibliotheken auszuschließen...

Grüße

[mkinzler]

-Alles in einer Transaktion?
-Gleichzeitig andere Vorgänge?
Ich hatte hier auch den Fall, dass es am Raid-Controller lag. Nach Bündelung von Schreibzugriffen wurde der Zugriff erheblich schneller.

[Lemmy]

Hi,

Transaktionsmanagement schließe ich jetzt einfach mal aus, weil es bei dem Großteil der eingesetzten Installationen kein Problem gibt. Ich schau aber mal nach, wie das UIB das intern macht.

Ob was anderes läuft... gut, Virenscanner wär noch ne Option das abzuschalten. Ansonsten: Da das Problem auf dem Rechner auf 2 Installationen (win 7 und XP) vergleichbar langsam abgeht hätte ich ein Hardwareproblem vermutet...

Wegen deinem Raid-Controller: Was meinst Du mit Bündelung der Schreibzugriffe?

Grüße

[tsteinmaurer]

Neben Transaktions-Handling, der Einsatz von Prepare Statement etc. wäre natürlich noch die Frage nach der Dateiendung der DB-Datei ein Schuss ins Blaue. .gdb (aus der alten InterBase Zeit) ist zum Beispiel keine gute Idee.

Das Non-Plus-Ultra in Bezug auf Import-Performance wäre natürlich der Weg über Firebird's EXTERNAL TABLE.

[Blup]

Wenn das bei vergleichbaren Installationen nur vereinzelt auftritt, denke ich zuerst an verweiste Transaktionen (der DB-Server hat den Verbindungsabbruch nicht bemerkt, älteste aktive Transaktion). Wenn so eine Transaktion über einige Stunden/Tage/Wochen weiter läuft, wird die Arbeit mit der Datenbank immer langsamer.
Vor solch einem Masseninsert/DataPump die Datenbank runterfahren und wieder hochfahren.

[Lemmy]

hi,

Danke für die Anregungen:

* Endung ist fdb
* verwaiste Transaktionen / Fehler im Management: Problem tritt auch mit einer neuen FDB auf (Backup/Restore)


@Thomas: External Table: wären die wirklich so viel schneller? Das wäre dann wirklich ein verdammt guter Ansatz. Anstelle einer fdb liefern wir ne handvoll external Tables aus, die wir dann nach belieben reinfüttern können.

Leider kann ich noch nichts über das Verhalten bei einem größeren SQL-Script schreiben, weil mir aktuelle Infos dazu fehlen...

Grüße

[Hansa]

Ja, external Table ist das schnellste, was es momentan gibt. Vor allem aber wird der komische Effekt wohl nicht mehr auftauchen. Hoffe es zumindest.

[nahpets]

Wir hatten mal das Problem, dass Datenbanken (diverser Hersteller) in virtuellen Maschinen deutlich langsamer waren, als auf "richtiger" Hardware.
Je mehr virtuelle Maschinen auf eine Hardware, um so langsamer.
Der Flaschenhals lag irgendwo in der "Kommunikation" zwischen virtueller Maschine und der Hardware.
Bei zu massiven Problemen blieb uns nur eine Lösung: Datenbank auf eigene Hardware ohne virtuelle Maschine.

Bei Windowssystemen war ein wesentliches Problem:

Wenn die virtuelle Maschine auslagert und das zu einer Auslagerung des Hostsystemes führt geht jede Hardware in die Knie, da dann die Festplattenzugriffe zum Engpass werden.

Tritt das Problem nur bei Systemen auf virtuellen Maschinen auf? Dann wäre das Problem eventuell in dem Bereich zu suchen.

[tsteinmaurer]

External Tables mußt du dir so vorstellen, dass du da alles auf den Server verlagern kannst und dadurch zum Beispiel das Firebird-Remoteprotokoll komplett eliminiert (gut, ein INSERT INTO oder SP-Aufruf wirst halt trotzdem wo, z.b. vom Client, triggern müssen) werden kann.

Dann macht man z.B. einfach etwas in der Form:

insert into real_table select * from external_table

und ab geht die Post. Wenn es nicht so einfach mit einem INSERT INTO geht, dann kann man natürlich auch eine SP darauf los lassen. Aber auch hier, die Sache läuft auf dem Server.

Schneller gehts ned.

Wichtig ist halt zu wissen, dass EXTERNAL TABLEs gewissen Restriktionen unterworfen sind, z.B. nur INSERT in eine EXTERNAL TABLE (ja, das geht auch!), keine Indizes, kein Transaktionsupport, keine BLOBs. Aber z.B. für einen Einweg-Import perfekt.

[Lemmy]

Zitat:

Zitat von nahpets (Beitrag 1202435)

Tritt das Problem nur bei Systemen auf virtuellen Maschinen auf? Dann wäre das Problem eventuell in dem Bereich zu suchen.

Nope, auf "normalen" Maschinen. Die VM haben wir nur zu Testzwecken eingesetzt ob es evtl. am Betriebssystem liegt...

Grüße

[Lemmy]

so, neue Info...

ein Script dauert im IBExpert auf dem Rechner auch gut doppelt so lange wie auf anderen Rechnern. Wenn man die Datenbank auf eine USB-HDD auslagert ist die Geschwindigkeit vergleichbar mit anderen Rechnern, d.h. deutlich schneller als auf der internen HDD!

Somit hängt es irgendwie an Firebird in Verbindung mit der HDD. Die Festplatte allein kann es nicht sein, da das zippen ja mit einer normalen Geschwindigkeit vor sich geht...

[Blup]

"Forced Writes" kann z.B. in Verbindung mit SSD-Festplatten zu extremen Geschwindigkeitseinbrüchen führen.
Falls vor dem Masseninserts eine Datensicherung angelegt wird, kann man überlegen, dieses während der Aktion abzuschalten.

[Morphie]

Zitat:

Zitat von Lemmy (Beitrag 1202449)

Somit hängt es irgendwie an Firebird in Verbindung mit der HDD. Die Festplatte allein kann es nicht sein, da das zippen ja mit einer normalen Geschwindigkeit vor sich geht...

Schon mal mit dem ProcessMonitor geprüft, was da so passiert?

[franktron]

Zitat:

Zitat von Lemmy (Beitrag 1202449)

so, neue Info...

ein Script dauert im IBExpert auf dem Rechner auch gut doppelt so lange wie auf anderen Rechnern. Wenn man die Datenbank auf eine USB-HDD auslagert ist die Geschwindigkeit vergleichbar mit anderen Rechnern, d.h. deutlich schneller als auf der internen HDD!

Somit hängt es irgendwie an Firebird in Verbindung mit der HDD. Die Festplatte allein kann es nicht sein, da das zippen ja mit einer normalen Geschwindigkeit vor sich geht...

Platte kaputt ?
Ich würde die mal Testen Platten haben oft Probleme die die Performance rapide reduziert.

Leider merken die User das nicht da das Phänomen sich langsam aufbaut.

[Lemmy]

Zitat:

Zitat von Morphie (Beitrag 1202559)

Schon mal mit dem ProcessMonitor geprüft, was da so passiert?

wir haben die Sache mit dem RessourcenManager verfolgt. Der Virenscanner schraubt etwas rum (den wir auch schon mal komplett deaktiviert hatten), die Auslagerungsdatei lagert, aber alles völlig unkritisch. Ich kann auch ohne Probleme (d.h. ohne dass es hier nennenswerte Änderungen bei der Geschwindigkeit kommt) nebenher im selben Verzeichnis eine 150 MByte große Datei zippen (mit der 20-fachen Geschwindigkeit).

Daher gehe ich aktuell auch davon aus, dass die HDD nicht defekt ist - wir werden das aber noch prüfen um auch das auszuschließen. Aktuell schraubt der Admin an der Kiste rum (Chipsatztreiber aktualisieren und so Zeug), mal schauen was der dann noch meint...


Grüße

[Lemmy]

Lösung: der SATA-Treiber wars... nach der Aktualisierung rennt das Teil wie gewünscht!

Danke für die Aufmerksamkeit :-)

Grüße

[tsteinmaurer]

Wäre interessant gewesen, was z.B. HDTune vor und nach dem SATA-Treiber-Update ausgespuckt hätte.

[Morphie]

OT:
Lemmy: 1.111 Beiträge
tsteinmaurer: 333 Beiträge

Wer von euch gibt jetzt einen aus? :-)

[jobo]

Nur weil Karneval ist, ist das noch lange kein Grund hier unsachlich zu werden!:wink:

[tsteinmaurer]

Auf gut Österreichisch :cheers:

[Lemmy]

eigentlich wollte ich nicht mehr posten und das für die Nachwelt erhalten, aber wenn Thomas mit gutem Beispiel vorangeht, dann lass ich ne Runde Trollinger springen :party: