Alexey Kovyazin, 14. Juli 2014

Wie Sie sich aus unseren vorherigen Artikeln erinnern, haben wir Mythen über die Leistungsminderung von Firebird untersucht ( /de/articles/firebird-performance-degradation-tests-myths-and-truth/), wobei wir mehrere Datenbanken von 9 GB bis 30 GB erstellt und auch eine sehr große Firebird-Datenbank (1,7 Terabyte) getestet haben (/de/articles/more-details-about-1-7-terabyte-firebird-sql-database/).

Alle Tests wurden auf derselben Hardware durchgeführt, die eine eher kostengünstige Konfiguration darstellt: CPU AMD-FX8350, RAM 16 GB, SATA-Software-RAID1 2x4 TB HDD Seagate-Laufwerke, Betriebssystem Windows Server 2008R2 (2008R2 ist 64-Bit), und mit derselben Firebird-Konfiguration: Es handelte sich um Firebird 2.5.2 64-Bit, SuperServer, mit erhöhten Seitenpuffern und TempCacheSize. Sie können diese SuperServer-Konfigurationsdatei kostenlos von folgendem Ort herunterladen: /de/optimized-firebird-configuration/

Als Ergebnis hatten wir folgendes Bild der Datenbankleistung:


Abbildung 1. Leistungsminderung von 9 GB auf 30 GB und 1,7 TB

Punkt #11 ist eine Leistungsmarke für die 30-GB-Datenbank und #12 für die 1,7-Terabyte-Datenbank - die Datenbankgröße ist um das 60-fache gewachsen (von 30 GB auf 1813 GB), der Leistungsverlust betrug das 2,4-fache (von 407 auf 169 Punkte).

Die Frage ist also: Können wir die Firebird-Leistung auf derselben Hardware durch Konfigurationsoptimierung verbessern?

Und die Antwort ist: Ja!

FirebirdSQL optimieren

Wie Sie sich erinnern, haben wir in diesem Test 20 gleichzeitige Verbindungen ausgeführt, die intensive INSERTs und weniger intensive UPDATEs durchführen.

Alle SELECTs sind kurz und klar definiert, mit effektiven SQL-Ausführungsplänen, sodass dies eine typische OLTP-Anwendung (Online-Transaktionsverarbeitung) ist. Für solche Anwendungen ist die parallele Verarbeitung das Wichtigste für die Leistung. Firebird SuperServer 2.5.2 ist nicht gut für die Multithread-Verarbeitung geeignet - er nutzt effektiv nur 1 Kern pro Datenbank, und diese Tatsache macht SuperServer keine sehr gute Wahl für OLTP-Anwendungen.

Daher müssen wir die Firebird-Architektur auf Classic oder SuperClassic umstellen, die Multithread-Verarbeitung unterstützen und mehrere CPU-Kerne nutzen (es gibt 8 Kerne in der CPU AMD-FX8350).

Dann ist eine gewisse Optimierung erforderlich, da die Standardkonfiguration für Firebird nicht optimal für unser Testsystem ist.

Parameter in firebird.conf optimieren

Seiten-Cache

Um die OLTP-Leistung zu verbessern, haben wir uns also entschieden, Classic- und SuperClassic-Architekturen auszuprobieren. Einer der Schlüsselparameter für Classic und SuperClassic ist die Anzahl der Seitenpuffer im Cache. Im Gegensatz zu SuperServer weisen Classic und SuperClassic den Seiten-Cache pro Verbindung zu.

Weitere Details zu den Firebird-Architekturen in 2.5 finden Sie in dieser Tabelle: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf

Es gibt eine einfache Formel zur Berechnung der Speichernutzung des Seiten-Caches für verschiedene Firebird-Architekturen:

1. 1. SuperServer - ein einzelner Seiten-Cache pro Datenbank. Die Standardgröße des Seiten-Caches beträgt 2048 Seiten, die allgemeine Empfehlung liegt bei 10000 Puffern. In unserem Fall betrug der Cache 16k (Seitengröße) x 10000 ~= 160 MB. Dies gilt für alle Verbindungen.
2. 2. Classic und SuperClassic - die Engine weist jeder Verbindung einen Seiten-Cache zu. Die Standardgröße beträgt 75 Seiten, also 16 KB (Seitengröße) x 75 = ~= 1,17 MB pro Verbindung.

Offensichtlich sollte die Größe des Seiten-Caches erhöht werden, da 75 Seiten pro Verbindung zu niedrig sind. Wir zeigen unten die Ergebnisse mehrerer verschiedener Werte für die Größe des Seiten-Caches.

LockHashSlots

Intern verwendet die Firebird-Engine eine Sperrtabelle, um Sperren für interne Objekte in der Datenbank anzufordern und zu erwerben. Für Classic und SuperClassic gibt es den Parameter LockHashSlots (Standardwert ist 1009). Er sollte bei hoher Last erhöht werden, um Hash-Ketten in der Sperrtabelle zu verringern. Nun, “hohe Last” scheint jede reale Mehrbenutzeranwendung zu sein, daher haben wir ihn auf 30011 gesetzt (für alle Tests).

LockMemSize

Der Parameter LockMemSize wird verwendet, um die anfängliche Größe der Sperrtabelle festzulegen (Standardwert ist 1048576). Die Engine kann die Tabellengröße bei Bedarf erhöhen. Die Vergrößerung der Sperrtabelle ist jedoch teuer in Bezug auf CPU und andere Ressourcen, da sie durch Speicher-Neuzuordnung erfolgt. Daher haben wir sie auf 7 MB gesetzt, um Zeit und CPU-Ressourcen zu sparen.

Testläufe

Wir haben mehrere Testläufe mit verschiedenen Werten für den Seiten-Cache durchgeführt, mit den folgenden Ergebnissen:

Seitenpuffer	Classic, Testpunkte	SuperClassic, Testpunkte
256	299	372
512	371	359
768	362	386
1024	312	387
1500	390	392
2048	285	284

Tabelle 1. Testläufe für Classic und SuperClassic

Wie Sie sehen können, sind Classic und SuperClassic für diese Aufgabe viel effektiver als Firebird SuperServer: Die Testergebnisse verbesserten sich von 169 Punkten auf 300-400, was nahe an den Ergebnissen liegt, die wir für die 30-GB-Datenbank hatten!

Es ist besser, die Ergebnisse im folgenden Diagramm zu sehen:

Abbildung 2. Testergebnisse für die 1,7-Terabyte-Datenbank

Sie können sehen, dass die beste Leistung (sowohl bei Classic als auch bei SuperClassic) bei 1500 Seiten pro Verbindung lag, sodass die Größe des Seiten-Caches pro Verbindung betrug:

1500x16k ~= 23,4 MB

Bei 2000 Seiten pro Verbindung nahm die Leistung deutlich ab. Es scheint, dass irgendwo zwischen 1500-2000 Seiten der Vorteil des Cachings geringer wurde als der Overhead, der durch Sperrtabellen-Interaktionen zwischen Prozessen zur Synchronisierung von Seiten in den Caches jedes Serverprozesses verursacht wird. Offensichtlich wird dies bei einer höheren Anzahl von Verbindungen früher eintreten, weshalb Classic/SuperClassic-Server normalerweise mit Werten wie 256-512 Seiten konfiguriert werden.

Es gibt auch einen Abfall der Classic-Leistung bei etwa 768-1000 Seiten-Caches - wir sind uns nicht sicher, warum das passiert ist.

Zusammenfassung

Unsere Experimente bestätigen, dass die Firebird-Leistung durch die richtige Auswahl der Firebird-Architektur (SuperServer, Classic oder SuperClassic) und durch eine angemessene Optimierung mehrerer wichtiger Parameter für die jeweilige Architektur gesteigert werden kann.

Als Ergebnis kann eine riesige 1,7-TB-Firebird-SQL-Datenbank auf kostengünstiger Hardware mit ausreichend guter Leistung arbeiten. Als praktisches Ergebnis dieser Tests haben wir mehrere Konfigurationsdateien für alle Firebird-Versionen und alle Architekturen erstellt. Natürlich sind sie nicht auf die spezifische Anwendung und/oder Hardware abgestimmt, aber sie sind besser als die Standardkonfigurationsdateien, die für sehr moderate Last ausgelegt sind.

Vollständiger Satz optimierter Firebird-Konfigurationsdateien: /de/optimized-firebird-configuration/

Zögern Sie nicht, Fragen zu stellen: [email protected]

Was kommt als Nächstes?

Wir arbeiten an einem umfassenden Test, der die Leistung von Firebird 2.5 und Firebird 3.0 vergleicht, mit realistischer Lastsimulation und einer großen Anzahl von Verbindungen. Bleiben Sie dran!