<< White Paper: Warum typische Delphi Projekte oft scheitern | Dokumentation | Übersicht der Hauptzeichensätze in Firebird >>

Die deutschsprachige Dokumentation wird seit dem 26. Juli 2016 nicht mehr gepflegt. Aktuelle und vollständige Dokumentation finden Sie auf der englischsprachigen Webseite: IBExpert Documentation

Firebird Performance Empfehlungen: White Paper

Holger Klemt, Juni 2013

PDF Download

Dieses White Paper wurde nach einem Vor-Ort Performance Workshop, der die Analyse einer auf einer Firebird 2.5 basierten Anwendung als Ziel hatte, geschrieben. Das Unternehmen litt unter enormen Performance-Problemen, obwohl die Datenbank nur 10 GB groß war und jederzeit mit maximal 50 Clients lief.

Folgender Artikel beschreibt IBExpert Verbesserungsvorschläge, speziell als Lösungsansatz für die Probleme dieses Kunden. Wir haben uns für die Veröffentlichung dieses Artikels entschieden, da wir sicher sind, dass viele andere Unternehmen durch einige oder mehrere der folgenden Vorschläge profitieren könnten.

Sollten Sie Interesse an einer Analyse Ihrer Firebird-basierten Anwendung haben, wenden Sie sich bitte an sales@ibexpert.biz. Die Analyse kann vor Ort oder per Remote-Verbindung durchgeführt werden.

Software Probleme

Es gibt einige von der Software ausgeführten, nicht optimierten SQL Anweisungen, die eine viel höhere als notwendige Arbeitsbelastung auf dem Server verursachen. Das IBExpert Monitoring-Feature ermöglichte Einsicht in den meisten Anweisungen, und die Trace und Audit Funktion in IBExpert enthüllte gewisse zusätzliche Probleme.

Es gibt keine allgemeine Regelung, die zum Beispiel nur 1000 nicht indizierte Lesevorgänge, oder 1000 Seiten Lesevorgänge zulässt, aber wenn eine Anweisung mit einer derart schlechten Syntaxoptimierung, basierend auf der vom Softwarehersteller ausgesuchten O/R Mapping-Architektur, ausgeführt wird, hat die resultierende Arbeitsbelastung von einem einzigen Benutzer die gleiche Auswirkung für den Datenbankserver wie Dutzende Benutzer mit optimierter Syntax.

Aus meiner Sicht sollte es eine Qualitätskontrollebene innerhalb des Anwendungsentwicklungsprozess geben, welcher die Auswirkungen aller Anweisungen auf der Datenbank evaluiert, vor allem weil diese Datenbank große Mengen empirischer Daten der realen Welt und nicht nur eine kleine Entwickler-Datenbank darstellt.

Jeder SQL, der mehr als 100ms Ausführungszeit benötigt, jede Abfrage, die eine SORT oder NATURAL Anweisung im Plan hat, sollte überprüft werden.

Ergebnisse der Überprüfung könnten zu Veränderungen des Datenbankmodells führen, zum Beispiel die Definition neuer Tabellen, Änderungen vorhandener Tabellen, Hinzufügen von Indizes und die Beseitigung vorhandener Indizes, sowie auch das Entfernen und Ersetzen von Teilen von SQL-Anweisungen.

Die Firebird Datenbankserverplattform ist in der Lage die Arbeitsbelastung von Tausenden von Anwendern zu bewältigen. Ich berichtete von Kundenprojekten mit dieser Anzahl von Benutzern. Jedoch wenn jeder Benutzer eine Auslastung von 100 Nutzern erzeugt, kann dies nicht funktionieren (und wird auch nicht auf einem anderen Datenbankplattform funktionieren).

Wenn die vom Softwarehersteller verwendete O/R-Mapping-Architektur automatisch nichtoptimierte Anweisungen erzeugt, ist das resultierende Softwareprodukt von keinem Nutzen für Enterprise-Anwendungen, egal welche Vorteile es für die Entwickler bietet.

Der Schwerpunkt sollte auf dem Komfort und der Benutzerfreundlichkeit für den Endanwender mit den technischen Merkmalen der Software kombiniert werden. Wenn alle automatisch erstellten SQL-Anweisungen durch schlechte Syntax leiden, sollten sie durch optimierte Versionen ersetzt werden, um für Endbenutzer Komfort und Bedienbarkeit zu gewährleisten.

Fazit

Der Softwarehersteller sollte jede einzelne Anweisung optimieren, welche wir mit einigen Anweisungen während des Workshops gemacht haben. Sollte externe Hilfe erforderlich sein, bieten wir unsere Dienstleistungen mit Vor-Ort-Workshops bzw. Beratung auf Stundenbasis an.

Die Verwendung von nichtoptimierten SQL-Anweisungen, egal aus welchen Gründen, ist inakzeptabel. "Der O/R Mapper erstellt es automatisch" ist keine Entschuldigung für die Vergeudung von Arbeitszeit und Produktivität der User! Wie wir gesehen haben, verbessern kleine Änderungen die Geschwindigkeit drastisch und verringern die Serverauslastung deutlich.

Hardware Probleme

Die Verwendung eines Firebird Servers mit der Datenbank auf einem externen SAN/NAS-Laufwerk ist keine gute Idee, da die Geschwindigkeit eines Firebird Datenbankservers abhängig von der Geschwindigkeit des Zugriffs auf einzelne 4K-Blöcke auf dem Gerät ist. Wie bereits erwähnt, sind externe SAN/NAS-Laufwerke hervorragend für die Übertragung hunderte MB von Daten von einem Speicherort zu einem anderen. Doch der Firebird Server überträgt hunderttausende von kleinen Seiten zwischen Speicher und physische Festplatte auf verschiedene Dateioffsets.

Auf einer klassischen, mechanischen Festplatte ist die Zugriffszeit der Festplatte als limitierter Faktor zu betrachten, da ein Commit die Daten in sehr unterschiedliche Dateioffsets schreibt. Ein RAID verbessert diese nicht, denn die Kopfposition muss sich in der gleichen Weise ändern. Caching RAIDS kann es verbessern, aber mit einer hohen Arbeitsbelastung können sich eventuell die Probleme verschlimmern.

Klassische Festplatten haben mindestens 5ms durchschnittliche Suchzeit, die in maximal 200 IOPS resultiert, dem neuen Messstandard schneller Geräte.

Eine SSD (insbesondere Enterprise SSD) erlaubt viel mehr IOPS (bis zu 500.000 auf PCIe-basierter Hardware). Eine in dem dedizierten Datenbankserver eingebaute SSD, die nicht virtualisiert ist, beitet die optimale Lösung für maximale Leistung.

Beispielkonfiguration

• CPU: Intel Xeon E3 oder E5 (non-threaded Versionen sind OK)
• RAM: 8GB oder mehr (ECC ist OK, jedoch nicht notwendig)
• DRIVES: Alle SSDs sollte auf Enterprise-Ebene vom Hersteller zertifiziert sein: 1 SSD für das Betriebssystem, 1 SSD für den Datenbankserver, 1 Hot-Plug-SSD für einen aktiven Shadow, optional 1 Hot-Plug-SSD für einen Teilzeit-Shadow als Backup-Ersatz. Wenn der Datenbankserver und Shadow SSDs 2 Jahre alt werden, sollten sie ersetzt werden, um ein ungeplanter Ausfall (in Server-Systemen empfehlen wir dasselbe für klassische Festplatten) zu vermeiden. Die Größe der SSDs sollte 400% der aktuellen Datenbankgröße oder höher sein.
• OS: Win7 Pro 64 ist OK, keine Dateifreigaben oder andere MS Dienste außer RDP sollten aktiv sein, kein Antivir, kein Online-Backup oder Imaging-Software usw. Alle nicht benutzten Services sollten deaktiviert werden, vor allem Windows-Updates. Zugriff auf das Dateisystem sollte von einem FTP-Server verwaltet werden, zum Beispiel FileZilla, um Backup-Dateien auf die externe Backup-Lösung des Unternehmens zu übertragen. Linux ist auch OK, aber es hat eine viel breitere Palette von möglichen Problemen. Wir bevorzugen abgestreifte Win7x64 Systeme. Win2008R2x64 ist auch OK.
• RAMDISK: Für LCK und TMP-Verzeichnis ist eine RAM-Disk sehr nützlich. Für RAM-Disk Verwendung sollte der physische Speicher auf 16GB oder 32GB erhöht werden. Mehr ist nicht erforderlich. Eine freie RAM-Disk-Software kann auf Anfrage empfohlen werden.
• REPLIKATION: Optional: Ein von IBExpert implementiertes Replikationssystem kann transaktionssicheres Clustering gewährleisten. Eine Backup- oder Shadowlösung erfordert Adminoperationen, um den Server auf einem zweiten Server im Falle eines schweren Hardwareausfalls neu zu starten.

Ein replizierter Cluster ermöglicht die Arbeit auf dem Backupserver ohne Datenverlust. Dies erfordert einige Änderungen in der Datenbank und eventuell auch in der Systemarchitektur. IBExpert unterstützt den Softwarehersteller bei dem Umsetzungsprozess. Eine Replikationslösung auf Basis unserer Technologie ist ein eigenständiges Projekt.

Wichtig

Ein Firebird Datenbankserver sollte ein dedizierter Server und, um maximale Leistung zu gewährleisten, lediglich für den Firebird Datenbankdienst zuständig sein. Virtuelle Server büßen zwischen 20% und 80% ihrer Geschwindigkeit unter einer hohen Last auf einer VM ein. Jeglicher Vorteil eines VM-basierten Firebird Servers wird durch zusätzliche Durchführungszeit bei Erledigung der Aufgaben von allen Mitarbeitern teuer bezahlt.

zurück zum Seitenanfang
<< White Paper: Warum typische Delphi Projekte oft scheitern | Dokumentation | Übersicht der Hauptzeichensätze in Firebird >>