Firebird und Geschwindigkeit mit SSD

[BUG]

Zitat von Hansa:

Noch nie erlebt, dass auf USB-Sticks Daten nicht richtig geschrieben waren ? Dafür gibts ja sogar "Hardware sicher entfernen".

Das hat aber eher mit dem Schreibpuffer und Plug'n'Play zu tun ... aber schon eine statische Entladung reicht manchmal, um einen USB-Stick zu entschärfen.
Man weiß nie genau, wie es in der SSD wirklich aussieht und was der Controller so treibt

[Dumpfbacke]

Hallo Leute,
ich muss leider noch mal nachfragen, da ich es einfach nicht hinbekomme.

Ich habe schon geändert:
Einen RamDisk mit 1 GB angelegt Laufwerk R:

Umgebungsvariabele : FIREBIRD_LCK R:\Temp

Dann in der Firbird Conf

TempDirectories = R:\Temp 200000000;D:\Temp
DefaultDbCachePages = 10240
RemoteServicePort = 3051

#CpuAffinityMask = 1 habe ich nicht geändert, da ja die Version 2.5 mit mehr als einem Proz können soll

Firebird läuft als Dienst

C:\Programme\Firebird\Firebird_2_5\bin\fb_inet_ser ver.exe -s DefaultInstance -m

Die DB habe ich auf die RAMDisk gelegt und nun das Ergenis. Auf Festplatte dauert es ca. 33 Minuten und auf der RAM Disk 30 Minuten. Ich dachte so wie Ihr es mir beschrieben habt das hier nun die Kuh fliegt, jedoch 3 Minuten schneller ?
Das ganze geht auch nur so schnell, da keine neuen Daten vorhanden sind wenn dann noch Daten geändert oder neue hinzugefügt werden dauert es locker 3 Stunden.

Ich habe eine Datei mit ca. 5 Milionen Daten aus welche ich 178404 herausfiltere und diese dann mit den Daten in der DB vergleicht und ggf. Update mitteles einer StoredProcedure.

Könnt Ihr mir hier bitte noch mal helfen ?

Daten zu meinem System:
Dell Server, 8GB Hauptspeicher, 2 Intex Xeon 3.20 GHZ Prozessoren. Das Programm lauft in einer Terminalsitzung auf dem selben Server und greift per TCIP zu .

Danke Dumpfbacke

[himitsu]

Wenn/falls der DB-Server so schlau war und die entsprechende Tabelle in der Zwischenzeit in seine Cache (ebenfalls im RAM) geladen hatte, dann treten beim Lesen keine/kaum noch Dateizugriffe auf, was dann also keinen großen Unterschied zwischen SSD und normaler HDD ausmacht.

[Phoenix]

File I/O ist bei Dir nicht der Flaschenhals. Es hilft übrigens nahezu nie, die Datenbank lediglich auf eine schnellere Platte zu legen. Die Datenbanken selber optimieren schon selber so gut, dass die ganzen Indices über die die Abfragen laufen eh schon in Memory gecached liegen. Die Tabellen auf denen viel gearbeitet wird liegen dazu auch meist komplett in Memory. Eben um den potentiellen Flaschenhals File I/O von vorneherein auszuschliessen. Das heisst Du hast etwas wegoptimiert, was die Datenbank schon von sich aus wegoptimiert

[MarcoWarm]

schon dran gedacht?

teste bitte mal, ob deine Queries auch optimiert laufen. Ein richtiger Index hie und da macht aus ner halben stunde manchmal ne halbe Minute.

Gruß Marco

[RP12Biker]

Das war eben auch meine erste Idee - wenn das Selektieren der Daten schon so lange dauert, kann auch eine RAM-Disk das nicht immens beschleunigen. Hier zeigt sich der Geschwindigkeitszuwachs eher beim Rückschreiben in die Datenbank.

Was sich im Laufe der Zeit (Bereich viele Monate bis Jahre) auch negativ bemerkbar macht ist die Fragmentierung der Datenbank. Oder selektierst Du Blobs mit? Das ist auch einen mögliche Bremse.

[IBExpert]

ich würde auch einfach mal so behaupten, das es bei 5 Millionen Datensätzen keinen Grund gibt, das irgendeine
Operation 30 Minuten dauert. Stored Procs kann man genauso schlecht programmieren wie alles andere auch.

Hast du dir die Performance Analyse in IBExpert Vollversion oder Trial nach dem Ausführen der Stored Proc mal
angesehen? Der Ansatz, die internen Operationen zu optimieren ist wesentlich erfolgversprechender als an der
Hardware rumzuschrauben.

Eventuell postest du einfach mal die wichtigsten Metadaten, bei Bedarf kannst du auch gerne mal eine leere
DB (backup nur metadaten) an meine email (support at ibexpert punkt com) senden, dann kann man deutlich
mehr Hinweise geben