Wie bekomme ich einen performanten Firebird?

[Union]

Hier mal die wichtigsten Eckdaten:

Zitat von 3DM2:

Server:
2x Intel Xeon E5620 @2,40 Ghz
24566 MB Speicher
5371 MB frei
Auslastung zwischen 0-4%
fb_inet_server belegt 22020Kb
Schreibgeschwindigkeit in FDB schwankt zwischen 500.000 - 1.600.000 B/s 58-160 ms Antwortzeit

Controller: LSI 3Ware Liberator
Firmware: FHX 5.12.00.007
Driver: 5.01.00.018
BIOS: BE9X 5.11.00.006
Memory: 488 MB
Bus Type: PCIe
Bus Width: 4 Lanes
Bus Speed 2.5 Gbps/Lane
Unit 0: Raid 5 1,82TB
Stripe: 64kb
Volumes: 1
Subunits 3
HDs: WDC WD1003FBYX-01Y7B0 931,51 GB SATA
Letzter Verify: 19.04.2014 19:20, OK
Keine Fehler seit 16.02.2013 (weiter reicht das Log nicht zurück).

[jsheyer]

Hallo,

es war sehr viel Text, habe es aber auch mit Freuden bis zum Ende gelesen

Übrigens, das System, das bei einem Kunden die Performance Problem bei schreiben hatte, war auch ein Dell, Zufall????
Auch hier konnte nicht festgestellt werden, absolut rätselhaft.
Man konnte den Effekt sogar beim kopieren von grossen Dateien nachstellen, also mal 5 GB kopiert, so ab 500 MB ging die Geschwindigkeit teilweise auf 200 kB / Sek runter.
Und wie gesagt, nirgendwo irgendeine Fehlermeldung.

[mikhal]

Zitat:

So, das reicht aber auch nun, keine Ahnung ob so lange Post überhaupt von den meisten bis zum Ende gelesen werden

Ich hab's auch bis zum Ende gelesen und mir so meine Gedanken zur Firmendatenbank unseres ERP gemacht. Hier ist es zwar eine Oracle-Datenbank mit ca. 100 GByte Tablespace, aber auch hier ist der Effekt schlechter Performance zu erkennen. Hier ist im SAN (über FibreCat angesteuert) ein RAID 5 Verbund gegeben und die Performance ist hier schlechter wie bei der Kopie für die Entwickler, die ohne RAID auf einem Testserver zugreifen (und das nicht nur, weil dann deutlich weniger Mitarbeiter im System arbeiten).

Auf jeden Fall sind ein paar technische Fragen bei mir hochgekommen, wie man es verbessern kann - aber das ERP wird nächsten Monat durch ein ein anderes ersetzt...
Trotzdem: Danke Holger, hat mir tiefe Einblicke gegeben und wird mir bei meinem zukünftigen Weg weiterhelfen.

Mikhal

[Union]

Zwischenbericht
Dank der Hilfe von Euch Allen und besonders Holger Klemt konnte ich das Problem jetzt lokalisieren. Es lag an der Write-Cache-Policy des Controllers. Diese war sehr konservativ eingestellt. Der in IBExpert eingebaute Benchmark meldete nach dem Aktivieren einer mehr auf Performance setzende Policy 120-fach höhere Performance!

Der Import der Buchungstabelle war nach 5:53 abgeschlossen, also ca. doppelt so schnell wie vorher.

Ich habe nun den nächsten Importlauf gestartet, diesmal mit deaktivierten Indizes. Es sieht auf den ersten Blick so aus als wäre das nochmals ca. 5-10 Mal schneller.

Als nächsten Test werde ich einmal das ISql direkt auf dem Server starten und sehen ob durch den Wegfall der TCP-Übertragung noch etwas herauskommt.

Im letzten Schritt werde ich durch mein Export-Tool mal ein Script erzeugen lassen, das die EXTERNAL TABLE Definitionen für die zu importierende Tabelle erzeugt und eine Importdatendatei mit festen Feldlängen passend dazu.

Ich weiss nur noch nicht was ich mit evtl. vorhandenen Memos machen soll.

@Sir Rufo: Ja, der Server ist leider auch ein DC. Der Cache wird schon ab Windows Server 2003 immer dann ausgeschaltet, wenn Windows auf der betreffenden Disk das AD hat und auf dem Controller keine BBU erkennen kann. Was dann passiert hängt in der Tat von der Qualität des Treibers ab. Ich habe daher beim Bootvorgang dskcache eingebunden um die Laufwerk-Richtlininen zu ändern. Wenn die Cache-Befehle nicht durchgereicht werden (dann gibt auch dskcache einen Fehler aus), der Treiber also eigentlich schlecht programmiert ist, dann ist alles in Ordnung.

[IBExpert]

Da merkt man ja, das mein Text durchaus einige Male gelesen wurde.

Lasst euch von den Hardwareheinis keinen vom Pferd erzählen, Ihr könnt tausende Euros für Pseudosicherheit ausgeben, die bei Datenbanksystemen so viele negative Einflüsse haben, das man das gar nicht glaubt. Meistens ist weniger mehr.

Falls Ihr schon mit Firebird arbeitet, dann gibt es noch einen anderen sehr einfach Test.

Erzeugt mit dem Befehl

Code:

"CREATE SHADOW 1 ''C:\db\db.shd'"

mal ein Shadow der Datenbank und messt die Zeit, die der dafür braucht. Das Shadow sollte auf der selben Platte liegern wie die DB. Nachdem das Shadow erzeugt wurde, könnt ihr mit

Code:

"DROP SHADOW 1"

das shadow wieder löschen. Achtung: das Shadow ist fast genau so groß wie die Orginal Datenbankdatei.

Gestern beim Kunden auf dem neuen Server aktuell gemessener Bestwert waren ca. 6 Sekunden pro GB, die 5,5GB große Datei wurde von Firebird 2.5 dabei page für page innerhalb von ca. 30 Sekunden kopiert. Mit einem Trick konnten wir den Wert sogar noch auf 20 Sekunden herunterbringen und das Shadow haben wir dann als automatisierte Datensicherung genommen, die ab sofort alle 30 oder 15 Minuten ausgeführt wird, obwohl beim Erstellen des Shadow aktive Verbindungen auf der Datenbank auch schreiben können, während das Shadow erstellt wird.

Falls euer Server also beim Shadow erzeugen die auf Festplatten und RAIDs üblichen 3-5MB pro Sekunde schafft, dann sollte Ihr die Eignung als Datenbakserver einfach mal hinterfragen. Meistens braucht man ja nur messbare Argmente, damit die Hardwareheinis mal aufhören mit deren Klugscheißereien und den Schweigefuchs zu machen: Öhrchen auf und Schnäuzchen zu.

[vagtler]

Zitat von Union:

[...] @Sir Rufo: Ja, der Server ist leider auch ein DC. [...]

Ein DC ist ein DC, kein Datenbankserver.

[Union]

Unabhängig davon ob es jetzt die "richtige" Maschine oder Server ist: Mir ging es darum FireBird genauso schnell oder schneller zu sehen als das bisher eingesetzte DB-System bei gleicher Hardware. Das ist gelungen.

8,364,632 records

Verbindung	Index	Dauer hh:mm
remote	aktiviert	05:53
remote	deaktiviert	02:05
lokal	deaktiviert	00:21

Den Test mit dem external file spare ich mir:

1. Wird die Datei riesengroß weil sie eine feste Feldlänge haben muss
2. Habe ich keine Idee wie ich dort Memos und NULL Werte verarbeiten kann

Vielen, vielen Dank nochmals an alle Helfer!

[jobo]

Spannende Infos von IBExpert!

Auch wenn ich auf einem Laptop mit einem kommerziellen Standard DB System auf ähnliche oder bessere Werte komme (jenachdem wie man's macht) als hier genannt (4 Mio records ca 6 Minuten oder 11 Minuten):

Zitat von Union:

8,364,632 records

Verbindung	Index	Dauer hh:mm
remote	aktiviert	05:53
remote	deaktiviert	02:05
lokal	deaktiviert	00:21

Es zeigt doch, wie sehr es sich lohnt, sich mit den Interna eines DB Systems auseinanderzusetzen!
Mich wundert immer wieder mal, wie egal das vielen hier scheinbar meist ist.

Mich würde für einen genaueren Vergleich noch der originale Tabellenaufbau interessieren und ob dort ein Primärschlüssel definiert ist. Oder ist "Index deaktiviert" gleich "nicht mal Primärschlüssel"?