Welche Seitengröße bei FB 2.1

[JKR]

Hallo,

ich habe mal eine Frage.
Welche Seitengröße sollte man bei Firebird 2.1 wählen.
FB läuft unter Windows 2003 SP 2, 4GB RAM, 4 Intel Xeon Prozessoren.
Zur Zeit ist die Seitengröße 2048 eingestellt.
Kann eine Vergrößerung erfolg bringen, wenn ja, kann man die
Seitengröße über ein Backup/Restore machen.

[Heiko Luettge]

Hallo,

4kB sollten es auf jeden Fall sein (entspricht der Page-Size von Windows).

Schau mal hier
http://ibdeveloper.blogspot.com/2008...use-in-my.html

Und hier
http://www.ib-aid.com/articles/item104


Die maximale Feldlänge eines Index ist u.a. von der Seitengrösse abhängig.

Ansonsten ausprobieren.

Und ja, es geht eh nur über Backup/Restore.


Heiko

[Klemmo]

ich glaub nicht das du als seitengröße 2048 eingestellt hast, denn das geht bei Firebird 2.1 gar nicht mehr (1k und 2k wurden abgeschafft und ggf automatisch durch 4k ersetzt. Den realen wert siehst du in der Datenbankstatistik.

Was du meinst ist sicherliche der Wert in der Firebird Conf Datei für die Cache Buffers. Bei 4 GB RAM kannst du denn auf jeden Fall höher setzen, zum Beispiel 20000, wenn du dann noch 16k pagesize beim Backup/Restore einstellst, dann nimmt der Firebird Server 320MB Ram als Cache pro Datenbank, das sollte meist ausreichen.

Vielleicht klärst du uns noch mal auf welchen Wert du denn genau meinst.

Gruß

Holger
www.ibexpert.com

[Thomas Steinmaurer]

Hallo Holger,

was dann gleich mal mit der Anzahl der Connections explodiert, wenn Classic Server verwendet wird, weil dann der Cache nicht mehr pro Datenbank sondern pro Datenbank pro Connection ist. ;-)


Thomas

[Klemmo]

korrekt, aber das problem ist beim classic aber auch mit 2048 bei vielen Connections ähnlich kritisch. Ich gehe immer davon aus, das jemand der keine Ahnung hat, den Superserver auswählt, denn der ist eben die default option im Installer. 2048 pages gilt als default auch nur für superserver, bei classic ist der default 75 cache buffers, wie wir ja beide wissen ;-) (aber viele andere Leser sicherlich nicht).

Gruß

Holger
www.ibexpert.com

[Thomas Steinmaurer]

SuperServer als Default-Installation ist natürlich ein Argument.

Thomas

[mvv]

Welche Seitengröße bei FB 2.1

Hallo,

wie viele Page-Buffers sind denn nun beim Superserver unter FB 2.1.3 sinnvoll? An verschiedenen Stellen habe ich jetzt gelesen, dass mehr als 10000 Buffers nicht sinnvoll sind.

Bisher habe ich (seit FB 2.0) bei unseren Kunden immer 100000 eingestellt. Jetzt habe ich aber gemerkt, dass einzelne Abfragen bei 10000 Buffers deutlich schneller ablaufen (speziell FB-Prozeduren mit Schreibvorgängen).

Die Page-Size ist immer 4096. Die Datenbanken sind 100-700 MB groß und es arbeiten max. 20 User gleichzeitig.

Deshalb hier nochmal de Frage:
Gilt diese Aussage (max. 10000 Buffers für Superserver) auch noch für FB2.1.x?

Gruß Michael

[Thomas Steinmaurer]

Hallo,

hierzu gibt es keine generelle Faustregel, schon gar nicht, um so größer der Cache desto besser (wie du ja auch bemerkt hast). Hier heißt es selbst einfach Tests machen. Eine wichtige Unterscheidung ist mit Sicherheit die Art der Verwendung der Datenbank. Lese vs. Schreibintensiv. Bei leseintensiven Aufgaben (z.B. OLAP-Szenarien, wo wenig Daten geändert werden), macht vermutlich ein größerer Cache mehr Sinn, als bei schreibintensiven Datenbanken, wo dann die Datenseiten im Cache auf "invalid" gesetzt werden muss, wenn sich die darunterliegenden Daten geändert haben.

Dann natürlich auch noch die Unterscheidung SuperServer vs. Classic. Ein zu hoher Cache bei Classic je Connection kann schon mal bedeuten, dass man in den Swapping-Bereich des Betriebssystem vorstößt, vor allem auch wenn sich mehrere Datenbanken auf dem Server befinden.

lg,
Thomas
www.upscene.com

[Klemmo]

erstmal Zustimmung zur Thomas und noch ein kleiner zusätzlicher Tip: Die cachegröße wird mit einem schnellem Datenträger immer unwichtiger. Wenn du richtig Speed rausholen willst lass die Datenbank auf einer schnellen SSD laufen, das bringt wesentlich mehr als so manches RAID System und für ca. 300 Euro bringt das richtig Vorteile, gerade im Multiuserbetrieb. Der Hauptvorteil ist neben den schnellen Schreib/Leseraten (ca 200MB/s Lesen und Schreiben auch bei kleinen Blöcken statt ca 80-20MB/s bei schnellen Festplatten) in erster Linie die extrem niedrige durchschnittliche Zugriffszeit (statt 8-10ms z.B. 0.1 ms). Ein Test (Initall(10000) der DB1 Demodatenbank in IBExpert) auf meinem laptop ergab für die eingebaute 500GB HDD 22 Sekunden, auf der SSD 9,5 Sekunden.

Gruß
Holger
www.ibexpert.com
www.firebird-conference.com

[mvv]

Hallo nochmal,

also ich habe mir jetzt einen PC mit SSD zusammengebaut. Mit Holgers DB1-Datenbank (Initall =10000) komme ich unter FB 2.1.3 Superserver auf folgende Werte:

SSD-Server, Intel C2D 8500 (2x 3,16 GHz), 4GB DDR2-RAM PC800,
Board Asus P5QL-VM, 1xSATA-SSD (Intel X25-M G2, 80 GB), AHCI aktiv
Windows XP Prof. SP3
--> 12,60 Sekunden

zum Vergleich ein fast identischer PC mit schnellen SATA-Festplatten:

SATA-Server, Intel C2D 8500 (2x3,16 GHz), 4GB DDR2-RAM PC800,
Board Asus P5QL-E, 2xSATA-HD als Raid 1 (Samsung Spinpoint F1 1TB), AHCI aktiv, Windows XP Prof. SP3
--> 13,16 Sekunden


Hier ist der Unterschied also erstmal nicht allzu groß.
@Holger: welche SSD und CPU benutzt du, um 9,5 Sekunden zu erreichen?

In unseren Anwendungen schlägt sich die SSD aber schon deutlich besser.
z.B. eine identische Auswertung dauert beim ersten Durchlauf auf der SSD 4,8 Sek., auf der HD 29,5 Sekunden. Beim 2. Durchlauf (Cache ist jetzt gefüllt) dauert es auf der SSD 4,2 und auf der HD nur noch 4,6 Sekunden.

Hierbei gab es auch nur minimale Unterscheide, wenn der Cache von 10.000 auf 100.000 Buffers geändert wurde. Die SSD war mit großem Cache geringfügig langsamer, aber nur beim 1. Durchlauf.

Bei anderen Tests waren die Unterschiede nicht so extrem, die SSD war aber immer schneller als die HD.


Mein Fazit:
Die SSD lohnt sich vor allem in Verbindung mit dem Classic-Server, da hierbei generell mit kleineren Cache-Größen gearbeitet wird. Aber auch der Superserver arbeitet teilweise deutlich schneller, vor allem bei vielen Schreiboperationen.


Hat jemand von Euch schon SSD-Server im Produktiv-Einsatz? Gibt es Erfahrungen mit dem Problem, dass die SSD mit zunehmenden Füllstand langsamer wird?

Gruß Michael

[Klemmo]

ich hab eine corsair 128 GB in meinem Laptop, auf dem das in 9,5 Sekunden durchläuft. (dell vostroh 1700, ich glaub 2,2 Ghz, 4 GB Ram).

Die Intel M Serie ist beim Lesen sehr schnell, aber beim Schreiben langsamer (kommt in den meisten Tests auf 80MB/s Schreiben, Lesen ca 170MB/s). Meine corsair schafft laut tests bei diversen benchmarks aber auch in der realität ca 150-200MB pro Sekunde lesend und schreibend. das erklärt die Differenzen. Der Knackpunkt gegenüber Festplatten wird im DB1 Test nur begrenzt deutlich, weil FB21 wesentlich effektiver schreibt als ältere Versionen.
Bei FB15 ist der Untershcied noch extremer.

Wenn man die Arbeit des fbservers mal mit dem sysinternals filemon beobachtet, dann sieht man auch warum die ssd vorteile hat. Sämtliche Schreibvorgänge hüpfen immer in den Offsets der db hin und her, im Normalbetrieb meist deutlich mehr als beim db1 test. Und jede wechselnde positionierung kostet die Zugriffszeit der HDD, bei schneller Platte durchschnittl. vielleicht 8-10ms, bei ssd 0,1 ms.Das erklärt die Geschwindigkeit eurer Auswertung. Wenn dafür soviel Daten geholt werden müssen, das die nicht mehr in den Buffer passen muss ausgelagert werden, was aber ggf später noch mal gebraucht wird.

Mit einer SSD ist das relativ egal, die geht zum Beispiel auch beim classic server mit 250 Buffers noch gut los, mit einer Festplatte wird das schon ätzend. Bei IBExpert auch gut in der Performanceanalyse zu sehen am Wert Reads und Writes (Anzahl der gelesenen und geschriebenen Datenpages von der Platte in den Speicher und umgekehrt). Wenn der Wert für ein bestimmtes SQL immer sehr hoch ist ist der Cache zu klein. Und wenn dann im Netz das noch mehrere User machen wird das noch heftiger. da bringt SSD noch mehr.

Ich war heute bei einem Kunden in Süddeutschland, der arbeit mit einem SAN (http://de.wikipedia.org/wiki/Storage_Area_Network) mit Firebird, das kommt insbesondere beim sequentiellen Lesen und Schreiben auf Werte, die ich auch mit schnellen Raids noch nicht gesehen hab (600-700 MB pro Sekunde). Ein Vergleich zur SSD haben wir uns gespart, das Ding war tierisch teuer und dann hinterfragt man bei Großunternehmen nicht, ob eine 300 Euro Investition doch schneller wäre. Das wird ja auch nicht nur für Firebird eingesetzt und hat noch andere Features, die den Preis rechtfertigen sollen.

Wenn SSDs vollgemüllt sind, dann werden die wirklich lahm, jedenfalls die einfachen. Ich hab nie mehr als 70 GB von den 128 GB belegt gehabt, daher habe ich das noch nie gemerkt. Wenn du das vermeiden willst, dann nimm statt Intel M die Intel E Serie. die hat das Problem nicht, kostet aber auch deutlich mehr (ca. das dreifache). Dafür kannst du auch 2 halbgefüllte Standard SSDs nutzen.

Ich weiss zumindest von einem Kunden, das dessen DB aufgrund ähnlicher Wete wie bei deinen Tests nun auch auf einer SSD liegt und die Anwender dort sind hochzufrieden. Er hat zwar gegenüber der Geschäftsleitung gelogen und behauptet, das das an seinr brillianten Idee liegt, das auf einem anderen Weg zu programmieren, aber scheinbar hat das keiner hinterfragt. Warum auch, wenn das schneller ist als vorher kann man das immer besser verkaufen als wenn man viel Geld investiert und es wird langsamer als vorher. Auch das hatten Kunden schon, hab ich schon oft auf Roadshows erzählt. Ich nenne hier aber keine Namen ;-)

Kleiner Trick noch am Rande: Achte drauf das das Temp directory auch auf der SSD liegt. Bringt zum Beispiel richtig Geschwindigkeitsvorteile beim Backup/Restore. Warum das so ist erzähl ich zum Beispiel in München auf der Firebird Konferenz, www.firebird-conference.com, 19.-21.11.2009, Eintritt am 21. nur 69 Euro.

Schöne Grüße

Holger