Firebird-Hardware-Leitfaden

von Alexey Kovyazin, zuletzt aktualisiert: 30. November 2015

In den technischen Support-Gruppen von Firebird sieht man oft die folgende Frage: „Welche Hardware ist die richtige für das Firebird-DBMS?“. Dieses Thema bleibt dauerhaft beliebt, da die Hardware-Anforderungen je nach Aufgabenstellung variieren und sich die Hardware selbst im Laufe der Zeit ändert.

Wir haben uns entschieden, diesen Leitfaden zu schreiben, um jedem, der wirklich effektive Hardware für seine Firebird-Datenbank auswählen möchte, das notwendige Wissen zu vermitteln. Dazu müssen Sie einige grundlegende Details darüber lernen, wie Firebird, das Betriebssystem und natürlich die Hardware funktionieren.

Ein wenig Theorie

Um herauszufinden, welche Hardware am besten zu Ihrer Firebird-Datenbank passt, müssen wir verstehen, wie Firebird seine Komponenten nutzt: CPU, RAM, HDD/SSD und wie diese Komponenten mit dem Betriebssystem (z. B. mit dem Dateicache) interagieren.

Funktionale Module des Firebird-Servers

Zunächst werden wir uns die funktionalen Module von Firebird mit Hilfe von Abbildung 1 ansehen:

Abbildung 1. Firebird-Module

Firebird umfasst die folgenden Hauptfunktionsmodule:

Metadatenobjekte: Sichten, Tabellen, Indizes, Trigger, gespeicherte Prozeduren und andere Datenbankobjekte. Metadatenobjekte befinden sich im Adressraum des Firebird-Prozesses (dies kann fbserver, fb_inet_server oder firebird.exe sein).
Der Cache der Seitenpuffer enthält Datenbankseiten, die von der Festplatte gelesen wurden, und befindet sich im Adressraum des Serverprozesses. Der Mechanismus des Cachens von Seiten ist ziemlich komplex, daher werden wir nur feststellen, dass Firebird die am häufigsten verwendeten Datenbankseiten cached.
Firebird sortiert Datensätze im Speicher (im Adressraum des Serverprozesses), bis die Menge des Speichers, der für alle gleichzeitigen Sortiervorgänge verwendet wird, das durch den Parameter TempCacheLimit (firebird.conf) festgelegte Limit erreicht. Sobald dieses Limit überschritten wird, wird eine temporäre Datei (mit dem entsprechenden Betriebssystem-Flag) im Ordner für temporäre Dateien erstellt und für die Sortierung verwendet. Wenn im System freier RAM vorhanden ist, wird die Sortierdatei vom Betriebssystem zwischengespeichert und die Sortierung im Speicher durchgeführt.
Globale temporäre Tabellen (GTTs) werden als temporäre Dateien im Betriebssystem erstellt. Wenn das Betriebssystem über freien Speicher verfügt, werden Operationen mit GTTs im RAM ausgeführt.

Grundlegende Operationen mit Hardware

Sehen wir uns an, wie die funktionalen Module von Firebird während der Arbeit mit Datenbanken mit Hardware-Komponenten interagieren.

Sobald Firebird gestartet wird, belegt der Serverprozess die minimale Menge an RAM (einige Megabyte) und führt keine intensiven Operationen mit CPU oder RAM durch.

Wenn eine Verbindung zur Datenbank hergestellt wird, beginnt der Server, deren Metadaten zu lesen und die entsprechenden Objekte im Speicher zu erstellen. Dies führt dazu, dass der Prozess umso mehr Ressourcen beansprucht, je mehr Tabellen, Indizes, Trigger und andere Metadaten verwendet werden. Die Speichernutzung steigt, aber die CPU wird in dieser Phase praktisch nicht beansprucht.

Wenn der Client SQL-Abfragen (einschließlich gespeicherter Prozeduren) ausführt, führt der Server die entsprechenden Operationen unter Verwendung der Hardware durch. Es ist möglich, die folgenden grundlegenden Operationen zu unterscheiden, die eine Interaktion mit der Hardware beinhalten:

Lesen von Datenbankseiten von der Festplatte,
Schreiben von Datenbankseiten auf die Festplatte,
Lesen von Datenbankseiten aus dem Cache,
Schreiben von Datenbankseiten in den Cache,
Lesen von Daten aus und Schreiben von Daten in globale temporäre Tabellen,
Verarbeiten von SQL-Abfragen (z. B. JOINs),
Sortieren von Datensätzen in Resultsets.

Jede dieser Operationen erfordert eine bestimmte Menge an Systemressourcen. Die folgende Tabelle zeigt den Ressourcenverbrauch in intensiven Einheiten (1 bedeutet am wenigsten intensiv, 10 bedeutet am intensivsten):


	Seite von der Festplatte lesen	Seite auf die Festplatte schreiben	Seite aus dem Seitenpuffer-Cache lesen	Seite in den Seitenpuffer-Cache schreiben	Aus einer GTT lesen	In eine GTT schreiben	Datensätze sortieren	SQL-Abfragen verarbeiten
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
Festplatten-I/O	10	10	1	1	1	1	1	1

Wie Sie sehen können, sind die ressourcenintensivsten Operationen diejenigen, die den Zugriff auf die Festplatte beinhalten, da Festplatten trotz der Fortschritte der letzten Jahre im Zusammenhang mit SSDs das langsamste Hardware-Element bleiben.

Dies führt zu einem der Wege zur Optimierung der Leistung, der vollständig hardwarebezogen ist - alle Lese-/Schreiboperationen in den RAM zu verlagern. Beachten Sie jedoch, dass der Ansatz, den Seiten-Cache zu vergrößern, nicht funktioniert. Wir werden uns mit diesem Thema im Abschnitt RAM im Detail befassen.

Gleichzeitig ausgeführte Operationen

Normalerweise ist es notwendig, Hardware für einen Server auszuwählen, der viele Clients bedienen wird. Daher ist es wirklich wichtig zu verstehen, wie die Parallelität von Operationen implementiert ist.

Aus Sicht der Hardware-Komponenten können wir über die parallele Nutzung von CPU, Festplatte und RAM sprechen. Moderne CPUs haben mehrere Kerne, die Befehlssätze parallel ausführen können. Der DBMS-Server verteilt daher Operationen auf die Kerne, was zu dem Schluss führt, dass je mehr Kerne die CPU hat, desto mehr Clients auf diesem Server arbeiten können.

Aus Sicht der Festplatten ist es nicht so einfach. Wenn herkömmliche Festplatten (HDDs) Informationen lesen, bewegen sie physisch den Kopf über das magnetische Material mit einer endlichen Geschwindigkeit. Eine Datenbank kann ziemlich groß sein, z. B. 3 Terabyte, und wenn SQL-Abfragen von Clients parallel auf Daten zugreifen, die sich in verschiedenen Bereichen der Festplatte befinden, springt der Kopf der Festplatte zwischen verschiedenen Bereichen hin und her, was die Lese- und Schreiboperationen erheblich verlangsamt. Dies erhöht die Festplatten-Warteschlange erheblich, während die übrigen Ressourcen (CPU, RAM) im Leerlauf sind. Natürlich gleicht der Festplatten-Cache (der Cache der HDD oder des RAID-Controllers) diese Verlangsamung bis zu einem gewissen Grad aus, aber er reicht nicht aus.

Im Gegensatz zu herkömmlichen HDDs sind Solid-State-Laufwerke (SSDs) viel weniger anfällig für Leistungseinbußen bei parallelem Datenzugriff. Der Vorteil einer SSD ist besonders beim parallelen Schreiben von Daten offensichtlich - unsere Tests zeigen, dass eine SSD 7-mal schneller ist als eine SATA-Festplatte (Link!). SSDs haben jedoch einige Probleme, die bei ihrer Verwendung berücksichtigt werden müssen (siehe Auswahl der Festplatten), um Verlangsamungen, vorzeitige Ausfälle und Datenverluste zu vermeiden.

Operationen mit RAM werden auf modernen Computern sehr schnell ausgeführt; sie sind praktisch nur durch die Bandbreite des Datenbusses begrenzt. Daher wirken diese Operationen selbst bei vielen parallelen SQL-Abfragen nicht als Engpass.

Datenflüsse

Während der Ausführung von SQL-Abfragen liest und schreibt Firebird eine große Menge an Daten, überträgt sie zwischen funktionalen Modulen und entsprechenden Hardware-Komponenten. Um mögliche Engpässe zu identifizieren, müssen wir verstehen, wie der Datenaustausch durchgeführt wird. Abbildung 2 unten wird uns dabei helfen:

Abbildung 2. Datenflüsse zwischen RAM und persistentem Speicher

Offensichtlich ist die Übertragung von Daten vom persistenten Speicher in den RAM und zurück die zeitaufwendigste Operation. Sie erzeugt zwei Datenflüsse: Lesen/Schreiben von Datenseiten aus Datenbankdateien und Lesen/Schreiben von Sortierdateien. Da es mehrere Sortierdateien geben kann und diese ziemlich groß sein können, können sie eine erhebliche Last auf die Festplatten ausüben. Daher ist es ratsam, diese Eingabe-/Ausgabeflüsse auf verschiedene Festplatten zu lenken.

Backup

Firebird bietet Ihnen zwei Backup-Methoden: verifiziertes Backup mit Hilfe des Dienstprogramms gbak und unverifiziertes inkrementelles Backup mit Hilfe des Dienstprogramms nbackup.

Wir empfehlen, diese Backup-Methoden zu kombinieren: Führen Sie nbackup häufig aus (z. B. jede Stunde, jeden Tag und jede Woche) und erstellen Sie jede Nacht mit gbak eine verifizierte Sicherungskopie.

Unabhängig davon, welche Backup-Methode Sie verwenden, wird die Datenbankdatei gelesen (ganz oder teilweise) und die Sicherungskopie (vollständig oder inkrementell) geschrieben. Schreiboperationen werden während des Backup-Prozesses sequenziell ausgeführt, was bedeutet, dass reguläre, kostengünstige Festplatten mit SATA-Schnittstelle (HDD SATA) für Backups geeignet sind, da sie sequenziell ziemlich schnell schreiben.

Auswahl der geeigneten Hardware

Nachdem wir nun eine Vorstellung davon haben, wie Firebird mit Hardware interagiert, sollten wir uns mit den Faktoren befassen, die die Wahl jeder einzelnen Komponente und ihrer Spezifikationen beeinflussen.

Manchmal beeinflussen die tatsächlichen Statistiken einer bestimmten Datenbank die Wahl der Hardware-Komponenten stark. Daher werden wir Tools von HQbird (dem professionellen Distributionspaket von Firebird von IBSurgeon) verwenden, um diese Statistiken zu erhalten. Sie können die Testversion von HQbird unter http://hqbird.com/en/hqbird/ herunterladen.

CPU

Bei der Auswahl der CPU sollten Sie die folgenden drei Dinge berücksichtigen:

Welche Abfragen in der Anwendung vorherrschen,
Die Anzahl der aktiven Verbindungen zur Datenbank im Durchschnitt und unter Spitzenlast,
Firebird-Version und -Architektur.

Welche Abfragen überwiegen in der Anwendung?

Firebird führt immer eine Abfrage auf einem Kern aus. Komplexe und schlecht optimierte Abfragen können daher einen Kern zu 100 % auslasten und andere Abfragen auf weniger ausgelastete Kerne verdrängen. Je mehr Kerne vorhanden sind, desto geringer ist die Wahrscheinlichkeit, dass die gesamte CPU ausgelastet wird und Benutzer eine Leistungsverschlechterung in der Anwendung bemerken.

Wenn die Anwendung hauptsächlich einfache, kurze SQL-Abfragen ausführt, alle Abfragen gut optimiert sind und keine Ad-hoc-Abfragen generiert werden (z. B. für Berichte), stellt die CPU keinen Engpass für die Leistung dar und Sie können eine CPU der unteren Preisklasse mit weniger Kernen wählen.

Wenn die Anwendung einen Berichtsgenerator oder viele langsame Abfragen enthält, die eine große Datenmenge zurückgeben, benötigen Sie eine CPU mit mehr Kernen.

Die Anzahl der aktiven Verbindungen zur Datenbank im Durchschnitt und unter Spitzenlast

Die Anzahl der Verbindungen (aktive Benutzer) beeinflusst ebenfalls die Wahl der CPU. Leider haben selbst Anwendungsentwickler keine genaue Vorstellung davon, wie viele Verbindungen, Abfragen und Transaktionen zu einem bestimmten Zeitpunkt aktiv sind. Um genauere Informationen darüber zu erhalten, empfehlen wir, das MON$ Logger-Tool von HQbird zu verwenden und während des Betriebs einige Momentaufnahmen zu machen, in denen Sie sehen, wie viele Verbindungen tatsächlich aufgebaut sind.

Abbildung 3. MON$ Logger: Anzahl der Verbindungen

Hier sehen Sie beispielsweise, dass die Anzahl der Verbindungen 296 beträgt. Offensichtlich ist es zu optimistisch, in diesem Fall eine Quad-Core-CPU zu verwenden, während eine 24-Kern-Lösung durchaus angemessen wäre. Es ist auch ratsam, die Anzahl der gleichzeitig laufenden Abfragen zu zählen, da Verbindungen im Leerlauf sein können, ohne dass SQL-Abfragen ausgeführt werden.

Sie können den Satz von 10 bis 30 Verbindungen pro Kern verwenden, um die notwendige Anzahl von Kernen in Ihrer CPU grob abzuschätzen. 10 Verbindungen pro Kern für eine Anwendung mit überwiegend komplexen und langsamen Abfragen, 30 Verbindungen pro Kern für eine Anwendung mit überwiegend einfachen, gut optimierten Abfragen.

Firebird-Version und -Architektur

Wenn Sie Firebird Version 2.5 verwenden, beachten Sie, dass Sie die Classic- oder SuperClassic-Architektur verwenden sollten, um die Verarbeitung auf mehrere Kerne verteilen zu können. In Version 2.5 kann die SuperServer-Architektur nur einen Kern für eine Datenbank verwenden. Daher sollte sie nicht in Systemen verwendet werden, die viele Ressourcen verbrauchen.

In Firebird Version 3.0 nutzen SuperServer, Classic und SuperClassic die Funktionen von Multi-Core-CPUs. Firebird 3.0 SuperServer zeigt die beste Leistung.

RAM

Bei der Auswahl des RAM sollten Sie auf zwei Dinge achten:

Das Speichermodul muss über einen Fehlerkorrekturcode verfügen (ECC-RAM)
Die Menge des RAM muss korrekt berechnet werden

ECC-RAM

ECC-RAM reduziert die Anzahl der Fehler, die bei der Arbeit mit dem Speicher auftreten, erheblich und wird für den Einsatz in industriellen Systemen dringend empfohlen.

Berechnung des benötigten Arbeitsspeichers

Um die Speichermenge zu berechnen, müssen wir uns die Besonderheiten der verschiedenen Firebird-Architekturen ansehen. Firebird 2.5 Classic und Firebird 3.0 Classic starten einen separaten Prozess für jede Verbindung, SuperClassic startet einen separaten Thread für jede Verbindung, aber praktisch mit derselben Speicherverbrauchsstruktur - jede Verbindung hat ihren eigenen unabhängigen Seitenpuffer.

Firebird SuperServer läuft als ein Prozess mit einem Seitenpuffer für alle Verbindungen.

Somit beeinflussen die folgenden Parameter den gesamten Speicherverbrauch:

Anzahl der Verbindungen
Datenbank-Seitengröße
Metadatenumfang (proportional zur Anzahl der Tabellen, Trigger, gespeicherten Prozeduren usw.; nicht einstellbar; durch die physische Nutzung bestimmt)
Für Classic und SuperClassic - pro Verbindung
Für SuperServer - pro Instanz einer geöffneten Datenbank
Seitenpuffergröße (bestimmt durch die Parameter im Datenbank-Header oder in firebird.conf oder in den Eigenschaften einer bestimmten Verbindung)
Für Classic und SuperClassic - pro Verbindung
Für SuperServer - pro Instanz einer geöffneten Datenbank
Sortierpuffergröße (bestimmt durch den Parameter in firebird.conf). Beachten Sie, dass der Speicher für die Sortierung nicht auf einmal, sondern nach Bedarf zugewiesen wird.
Für Classic - pro Verbindung
Für SuperServer und SuperClassic - pro Prozess (d. h. ein Sortierpuffer)
Für Classic/SuperClassic - Sperrtabellengröße (sie ist normalerweise klein, daher lassen wir sie aus unserer Berechnung heraus).

Die Firma IBSurgeon führte einige Tests durch und ermittelte eine Reihe optimaler Werte für die Anzahl der Seiten im Firebird-Seitenpuffer:

Classic/SuperClassic - von 256 bis 2000 Seiten
SuperServer 2.5 - 10000 Seiten
SuperServer 3.0 - 100000 Seiten

Basierend auf diesen Tests haben wir optimierte Firebird-Konfigurationsdateien für Server mit 4-6 GB Speicher erstellt. Sie können diese hier herunterladen: /de/optimized-firebird-configuration/

Formeln zur Berechnung des benötigten Arbeitsspeichers

Nachfolgend sehen Sie Formeln zur Schätzung der ungefähren Speichermenge, die Firebird benötigt. Der tatsächliche Speicherverbrauch kann abweichen, da diese Schätzung den Speicherbedarf für Metadaten, für Bitmasken von Indizes usw. nicht berücksichtigt, was den Speicherverbrauch erhöhen kann. Es wird jedoch auch angenommen, dass der Sortierspeicher in allen Verbindungen vollständig genutzt wird, was normalerweise nicht der Fall ist.

Wenn Ihre Datenbank bereits in Betrieb ist, können Sie die durchschnittliche Speichernutzung des Firebird-Prozesses betrachten (mit Hilfe des Task-Managers oder ProcessExplorer).

Schätzung für Classic:

Anzahl der Verbindungen * ( (Anzahl der Seiten im Puffer * Seitengröße) + Sortierpuffergröße )

Beispiel für Classic: Angenommen, wir erwarten 100 aktive Benutzer, die Datenbank-Seitengröße ist auf 8 KB eingestellt und die Anzahl der Seiten im Seitenpuffer ist auf 256 eingestellt, die Sortierpuffergröße wird von 8 MB (der Standardwert für Classic und SuperClassic) auf 64 MB erhöht:

((256.8 KB)+64) = 6600 MB

Schätzung für SuperClassic:

Anzahl der Verbindungen * (Anzahl der Seiten im Puffer * Seitengröße) + Sortierpuffergröße

Beispiel für SuperClassic: 100 Benutzer, die Datenbank-Seitengröße beträgt 8 KB, die Anzahl der Seiten im Seitenpuffer beträgt 256, die Sortierpuffergröße beträgt 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

Schätzung für SuperServer:

(Anzahl der Seiten im Puffer * Seitengröße) + Sortierpuffergröße

Beispiel für SuperServer (Firebird 2.5): 1 Datenbank, 100 Benutzer, die Datenbank-Seitengröße beträgt 8 KB, die Anzahl der Seiten im Seitenpuffer beträgt 10000, die Sortierpuffergröße beträgt 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Beispiel für SuperServer (Firebird 3.0): 1 Datenbank, 100 Benutzer, die Datenbank-Seitengröße beträgt 8 KB, die Anzahl der Seiten im Seitenpuffer beträgt 100000, die Sortierpuffergröße beträgt 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Überschüssiger Speicher”

Firebird wird oft für ineffektive Speichernutzung kritisiert - wenn der laufende Prozess des Servers eine kleine Menge RAM verbraucht und der Rest des Speichers angeblich ungenutzt bleibt.

Eigentlich ist das nicht wahr. Diese Schlussfolgerung beruht im Wesentlichen auf einem Missverständnis der Funktionsweise des Firebird-Caching-Mechanismus und auf der Unvollkommenheit der Überwachungswerkzeuge des Betriebssystems.

Zunächst einmal müssen Sie sich absolut im Klaren sein, dass Firebird den Dateicache des Betriebssystems intensiv nutzt. Wenn eine Seite in den Firebird-Seitenpuffer geladen wird, durchläuft sie den Dateicache des Betriebssystems. Wenn Firebird eine Seite aus seinem Seitenpuffer entlädt, behält das Betriebssystem diesen Teil der Datenbank in seinem RAM, sofern genügend freier Speicher vorhanden ist.

Abbildung 4. Cache-Ebenen: Firebird, Betriebssystem und Speicher

Wenn Sie jedoch nur darauf schauen, zeigt das Betriebssystem den für den Dateicache zugewiesenen Speicher nicht als belegt an. Hier ist zum Beispiel die typische Situation der Speicherverteilung, wenn der Firebird-Server läuft, wie sie vom Task-Manager angezeigt wird:

Abbildung 5. Der Task-Manager zeigt die Dateicache-Nutzung nicht an

Es sieht so aus, als wären nur 6,3 GB von 16 GB belegt.

Wenn Sie jedoch das RAMMap-Tool (von SysInternals von Microsoft) verwenden, sieht alles viel logischer aus:

Abbildung 6. RAMMap zeigt Details zur Speichernutzung: zugeordnete Dateien sind gecachte Datenbanken

Datenbankdateien (dbw350.fb252x64.fdb und dbw250.fb252x64.fdb) werden vom Betriebssystem gecacht und belegen den gesamten Speicher, den der Task-Manager als frei deklariert:

Abbildung 7. RAMMap: Details zur Dateicache-Nutzung

Daraus schließen wir, dass das Betriebssystem den gesamten verfügbaren Speicher effektiv nutzt, um die Datenbank zu cachen, bis die Datenbank vollständig in den Speicher geladen ist.

Festplatten-Subsystem

Die korrekte Konfiguration des Festplatten-Subsystems spielt eine wichtige Rolle bei der Auswahl und Konfiguration von Hardware für Firebird, da Fehler in diesem Schritt zu größeren Ausfällen führen können, die schwer zu beheben sind.

Separate Festplatten für alles

Um die Konkurrenz um den Festplatten-Eingang/Ausgang zwischen Operationen mit der Datenbankdatei zu verringern und die Wahrscheinlichkeit eines gleichzeitigen Verlusts von Datenbank und Backup zu verringern, wird empfohlen, drei verschiedene Festplatten (oder RAID-Verbünde) zu verwenden: eine für die Datenbank, eine für temporäre Dateien und eine für die Erstellung und Speicherung von Backup-Kopien.

Wenn wir “separate Festplatten” sagen, bedeutet das, dass die Datenströme durch verschiedene Eingangs-/Ausgangskanäle laufen müssen. Wenn Sie drei logische Festplatten auf einer physischen Festplatte erstellen, wird es keine Leistungssteigerung geben. Wenn Sie jedoch drei logische Festplatten auf einem Speichergerät mit mehrkanaligen Controllern einrichten, wird die Leistung höchstwahrscheinlich gesteigert, da das Gerät die Datenströme auf die Controller verteilen kann. Manchmal wird auch gesagt, dass die Dedizierung einer separaten Festplatte für die Speicherung von Betriebssystemdateien und der Auslagerungsdatei des Betriebssystems die Leistung erhöht.

SSD für eine Datenbank

SSD ist die beste Wahl für die Arbeit mit einer Datenbank, da sie eine hervorragende Skalierung bei parallelem Eingang/Ausgang gewährleisten. Es ist ein Muss, Enterprise-Festplatten mit erhöhter Anzahl von Lese-/Schreibzyklen zu verwenden, andernfalls ist es sehr wahrscheinlich, dass Sie Daten aufgrund eines SSD-Ausfalls verlieren.

Vor einiger Zeit neigten SSDs zu erhöhtem Verschleiß, wenn nur wenig freier Speicherplatz auf der Festplatte verblieb (weniger als 30%). Einfach ausgedrückt wird jede Änderung auf einer SSD in eine neue freie Zelle geschrieben, sodass der Mangel an freiem Speicherplatz zu erhöhtem Verschleiß der verbleibenden freien Zellen und zu einer kürzeren Lebensdauer der Festplatte führte.

Hersteller moderner SSD-Controller erklären, dass dieses Problem durch das präventive Verschieben statischer Daten gelöst wurde und der Verschleiß der Zellen nun mehr oder weniger ausgeglichen ist. Die genauen Spezifikationen und Betriebsalgorithmen von SSDs werden jedoch von den Herstellern geheim gehalten, daher empfehlen wir weiterhin, 30% des Speicherplatzes auf SSDs frei zu lassen sowie ihre erwartete Lebensdauer zu reduzieren und zu planen, sie mindestens einmal in drei Jahren zu ersetzen.

Angenommen, die Größe Ihrer Datenbank beträgt derzeit 100 GB und wächst um 1 GB pro Monat. In diesem Fall sollten Sie keine SSD mit Mindestgröße (120 GB) kaufen, sondern besser das nächste Gerät in der Produktlinie wählen - 250 GB. Gleichzeitig wäre der Kauf einer 512-Gigabyte-SSD eine Geldverschwendung, da es ratsam ist, die Festplatte in drei Jahren zu ersetzen.

Die beste Praxis ist, eine SSD ausschließlich für die Arbeit mit der Datenbank zu reservieren, da jede Eingangs-/Ausgangsoperation die Lebensdauer der Festplatten verkürzt.

Festplatte für temporäre Dateien

Da temporäre Dateien nur dann auf der Festplatte erscheinen, wenn nicht genügend RAM vorhanden ist, ist der beste Weg, diese Situation natürlich ganz zu vermeiden. Es ist möglich, die Anzahl und Größe temporärer Dateien in einem Produktionssystem nur durch Überwachung des Ordners mit temporären Dateien zu bewerten. FBDataGuard aus dem HQbird-Verteilungspaket führt diese Art der Überwachung durch. Sobald Sie wissen, wie viele temporäre Sortierdateien auf der Festplatte erstellt werden und wann sie erstellt werden, können Sie die Menge an RAM erhöhen und die Konfiguration in firebird.conf ändern.

In jedem Fall verlangt Firebird, dass Sie den Ordner angeben, in dem temporäre Dateien gespeichert werden. Normalerweise wird die Standardeinstellung beibehalten, d. h. der Ordner des Betriebssystems für temporäre Dateien wird verwendet. Wenn der freie RAM ausreicht, ist dies eine gute Wahl.

Es gibt jedoch ein weiteres wichtiges Problem bezüglich der Platzierung temporärer Dateien auf der Festplatte - die Erstellung von Indizes beim Wiederherstellen einer verifizierten Backup-Kopie (erstellt mit dem gbak-Dienstprogramm). Wenn ein Index erstellt wird, wird auch eine temporäre Datei erstellt, die alle Schlüssel aus diesem Index enthält. Wenn die Datenbank ziemlich groß ist, kann die Größe des Index für eine große Tabelle ebenfalls ziemlich groß sein. Zum Beispiel beträgt der Index der größten Tabelle mit 3,2 Milliarden Datensätzen in einer 1-Terabyte-Datenbank 29 GB, aber es wurden 180 GB freier Speicherplatz benötigt, um diesen Index zu erstellen:

Um den Mangel an freiem Speicherplatz auf der Systemfestplatte zu verhindern, ist es möglich, eine weitere Festplatte als zusätzlichen reservierten Speicherplatz in firebird.conf anzugeben:

TempDirectories =C:\temp; H:\Temp

Wenn auf der ersten Festplatte kein Speicherplatz mehr vorhanden ist, verwendet Firebird weiterhin die zweite Festplatte für temporäre Dateien usw.

HDD für Backups

Reguläre HDDs mit SATA- oder nSAS-Schnittstelle sind für die Erstellung und Speicherung von Backup-Kopien geeignet. Sie gewährleisten schnelle sequenzielle Schreib- und Leseoperationen für Backup-Dateien und sind billig genug, um nicht an ihrer Größe zu sparen und mehrere Backup-Kopien aufzubewahren.

Festplatten für Backup-Kopien müssen immer zusätzlichen freien Speicherplatz aufweisen: die Größe der neuesten Backup-Kopie + 10%. In diesem Fall ist es möglich, eine frische Backup-Kopie zu erstellen, sicherzustellen, dass der Backup-Prozess erfolgreich abgeschlossen ist (dieser Prozess kann für eine Datenbank mit einer Größe von mehreren Terabyte mehrere Stunden dauern) und erst danach die vorherige Backup-Kopie zu löschen.

Wenn Sie die vorherige Backup-Kopie löschen, bevor die neue erstellt wird, ist es möglich, dass keine neue Backup-Kopie erstellt wird, während die alte bereits gelöscht ist und die Datenbank beschädigt wird, z. B. aufgrund eines Festplattenausfalls.

Wenn Sie die oben empfohlene Backup-Methode verwenden (die Kombination aus inkrementellem Drei-Ebenen-Backup und verifiziertem Backup einmal täglich, wobei nur die neueste Kopie aufbewahrt wird), verwenden Sie die folgende Formel zur Berechnung des Mindestspeicherplatzes für Backups:

Datenbank_größe*3+0.2.Datenbank_größe

Betrachten wir die folgende Beispielberechnung des für Backups notwendigen Speicherplatzes:

Angenommen, wir haben eine Datenbank von 100 GB, für die wir ein Drei-Ebenen-Inkremental-Backup (Woche-Tag-Stunde - je eine Kopie) und eine Kopie des täglichen verifizierten Backups speichern. In diesem Fall nehmen die Backup-Kopien den folgenden Speicherplatz ein:

Nbackup_level_0.wöchentlich - 100 GB
Nbackup_level_1.täglich - 5 GB (ungefähr)
Nbackup_level_2.stündlich - 200 MB (ungefähr)
Tägliches verifiziertes Backup - 100 GB (ungefähr)
Plus benötigen Sie reservierte 110 GB, um die nächste Backup-Kopie erstellen zu können.

Total - 316 GB.

! Die Größe der inkrementellen Datei der ersten Ebene oder höher hängt von der Anzahl der geänderten Seiten seit dem letzten Ausführen von nbackup ab. Die Größe dieser Dateien kann nur experimentell bestimmt werden, da das Ausmaß der Änderungen in einer Datenbank von den Anwendungen abhängt.

Natürlich sollte die Schätzung des Speicherplatzes für Backups auch einen möglichen abnormalen Anstieg der Datenbankgröße berücksichtigen und entsprechend die Menge an freiem Speicherplatz erhöhen, da der Backup-Prozess sonst unerwartet aufgrund von Speichermangel unterbrochen werden kann.

Natürlich werden intelligente Backup-Tools (FBDataGuard von HQbird) den fehlenden Speicherplatz für Backup-Kopien bemerken und die entsprechende Nachricht an den Administrator senden.

HDD für eine Datenbank

Eine SSD könnte sich als zu teure Lösung erweisen oder die Datenbank könnte zu groß sein, sodass Sie auf kostengünstigere Methoden zurückgreifen müssen. In diesem Fall sollten Sie eine HDD mit SAS-Schnittstelle verwenden. Wenn das nicht möglich ist, verwenden Sie SATA-Festplatten mit nSAS-Schnittstelle oder die günstigste Option - normale SATA-Festplatten.

Um die Geschwindigkeit (und auch die Zuverlässigkeit - siehe unten) der Festplatten zu erhöhen, sollten Sie sie zu RAID10 kombinieren. RAID10 ist eine Kombination aus gespiegelten (RAID1) und gestreiften (RAID0) Blöcken. Ein guter und richtig konfigurierter RAID-Controller mit großem Cache ist eine gute Alternative zu SSDs.

Zuverlässigkeit und RAID

Natürlich ist es notwendig, die Zuverlässigkeit des Festplatten-Subsystems durch die Kombination von Festplatten in RAID in allen oben genannten Varianten zu erhöhen (außer bei der Festplatte, die ausschließlich für temporäre Dateien reserviert ist).

• Stellen Sie bei SSDs sicher, dass Sie RAID1 verwenden - d. h. zwei gespiegelte Festplatten, auf die Änderungen gleichzeitig geschrieben werden, wodurch die Chancen, alle Daten zu verlieren, erheblich geringer werden. RAID 10 aus SSDs wird höchstwahrscheinlich überflüssig sein, da der RAID-Bus den Durchsatz begrenzt. Beispielsweise hat die 6-Gbit/s-Schnittstelle einen Durchsatz von 600 Megabyte pro Sekunde, während moderne einzelne SSDs diese Geschwindigkeit bereits erreicht haben. Somit erhalten wir für RAID 10 dieselbe Grenze von 600 MB/s.

Außer dass Sie PCI Express 3.0 verwenden können, um SSDs in RAID 10 zu kombinieren, da der Durchsatz dieses Busses bereits 16 Gigabit pro Sekunde und mehr beträgt.

• Wenn Sie HDDs für Backup-Zwecke verwenden, reicht RAID1 aus, das die Sicherheit der Backup-Kopien und eine akzeptable Lese- und Schreibgeschwindigkeit gewährleistet.

• HDDs, die für eine Datenbank verwendet werden, sollten in RAID10 (mindestens 4 Festplatten) kombiniert werden, das die optimale Kombination aus Kosten, Zuverlässigkeit und Leistung bietet. Einige Benutzer verwenden auch RAID5 und opfern Leistung für mehr Speicherplatz.

RAID-Konfiguration für Firebird

Zunächst sollten Sie sicherstellen, dass sich eine ordnungsgemäß geladene Backup-Batterieeinheit (BBU) im RAID befindet. Wenn keine solche Batterieeinheit vorhanden ist, schalten die meisten RAIDs in den sicheren Schreibmodus (der Festplatten-Cache ist vollständig deaktiviert), der eine geringere Eingabe-/Ausgabegeschwindigkeit bietet als eine normale SATA-Festplatte!

Diese Tatsache verursacht die meisten frustrierten Nachrichten an den technischen Support von Benutzern, die einen teuren Server gekauft haben und festgestellt haben, dass er langsamer arbeitet als ein Desktop-Computer. Leider enthalten einige Anbieter Batterieeinheiten nicht standardmäßig, weshalb dies das Erste ist, das Sie überprüfen und bei Bedarf beheben sollten.

Dann sollten Sie den Lese- und Schreibcache konfigurieren. Oft ist der Cache standardmäßig deaktiviert, und wenn Sie RAID ziemlich schnell machen möchten, müssen Sie den Cache aktivieren.

Neben der Aktivierung des Caches sollten Sie überprüfen, wie er funktioniert - er kann “write through” oder “write back” sein. Die schnelle Methode zur Arbeit mit dem Cache ist “write back” - in diesem Fall werden alle Änderungen in den Cache-Controller geschrieben und nach einer Weile direkt auf die Festplatte.

Sie können Tools von Herstellern verwenden, die mit RAID geliefert werden, um Batterieeinheit, Cache und Modus zu überprüfen.

Moderne RAID-Controller können den Cache auch fein abstimmen - er kann angepasst werden, um das Lesen oder Schreiben zu erleichtern. Normalerweise wird er 50%/50% für Lesen und Schreiben aufgeteilt.

Um herauszufinden, wie genau Sie den Cache konfigurieren können, können Sie auch das MON$ Logger-Tool aus dem erweiterten HQbird-Verteilungspaket verwenden. Es zeigt das Verhältnis von Lese- und Schreiboperationen zueinander (aggregiert ab dem Moment der ersten Verbindung zum Server):

Abbildung 8. HQbird MON$Logger: Lese-/Schreibverhältnis

Wie Sie sehen können, gibt es in diesem Beispiel viel mehr Leseoperationen als Schreiboperationen, daher ist es sinnvoll, den RAID-Controller für 80% Leseoperationen und 20% Schreiboperationen zu konfigurieren.

SAN und Datenbanken

Integrierte Speichersysteme sind in letzter Zeit beliebt geworden. Sie umfassen ein flexibel anpassbares Festplatten-Array (alle RAID-Typen) mit erweiterten Caching-Funktionen. Normalerweise haben SANs mehrere Eingabe-/Ausgabe-Controller, was es ermöglicht, mehrere Server gleichzeitig zu bedienen und ziemlich schnell zu arbeiten.

Viele Organisationen kaufen SANs und verwenden sie in ihrer Arbeit mit Firebird-Datenbanken. Wenn ein SAN richtig konfiguriert ist, kann eine gute Leistung erzielt werden. Sie sollten die folgenden Punkte berücksichtigen, wenn Sie SAN verwenden:

Mehrere leistungsstarke Festplatten-Controller, die einen mehrkanaligen Datenaustausch ermöglichen, müssen verfügbar sein.
Backup-Batterieeinheiten (BBU) müssen vorhanden sein, wenn sie konstruktionsbedingt vorgesehen sind.
Datenbank-Festplatten müssen in RAID10 kombiniert werden.
Der Cache muss aktiviert sein, der Schreibmodus muss auf “write back” umgestellt werden.
Wenn mehrere Computer mit dem SAN verbunden sind, muss jeder seinen eigenen Controller haben.
Die neuesten SAN-Treiber sind installiert. Wir sind auf Fälle gestoßen, in denen spätere Treiber eine Leistungssteigerung von 30% brachten.
Wenn es mehrere logische Festplatten auf einem SAN gibt (für Datenbanken, Backup-Kopien, Betriebssystem), haben diese unterschiedliche Eingabe-/Ausgabekanäle. Ein Versuch, einen Kanal für alle Festplatten zusammen zu verwenden, führt zu geringerer Leistung.
Ebenso kann die Leistung geringer sein, wenn mehrere Server und Datenbanken gleichzeitig ein SAN verwenden, aufgrund der erhöhten Bandbreite der Eingabe-/Ausgabe-Controller.
Häufig werden kombinierte Methoden verwendet - wenn das Betriebssystem und temporäre Dateien auf lokalen Festplatten gespeichert werden, während die Datenbank- und Backup-Dateien auf einem SAN gespeichert werden.

Oft werden SANs als “zwei Server - ein SAN” verwendet, um einen ausfallsicheren Cluster zu erstellen. Es sollte beachtet werden, dass ein solcher Cluster nur Probleme lösen kann, die mit Hardware-Ausfällen auf einem der Server zusammenhängen, indem sofort auf den zweiten Server umgeschaltet wird. Wenn das Problem mit dem SAN oder der Datenbank selbst zusammenhängt, hilft diese Lösung nicht.

Um eine wirklich ausfallsichere Lösung zu erstellen, sollten Sie Lösungen verwenden, die Daten zwischen zwei Datenbankinstanzen replizieren. Sie können [email protected] kontaktieren, um weitere verfügbare Lösungen für Firebird zu erfahren.

Kurze Schlussfolgerungen und Empfehlungen

Lassen Sie uns Schlussfolgerungen und Empfehlungen für Firebird bezüglich Hardware zusammenfassen.

Multi-Core-CPUs müssen verwendet werden, um eine große Anzahl von Benutzern zu bedienen.
Die Mindestmenge an RAM wird auf der Grundlage der Anzahl der Benutzer und der Datenbankkonfiguration berechnet; die überschüssige Menge an RAM wird vom Betriebssystem effektiv zum Caching der Datenbankdatei verwendet.
Verwenden Sie separate Festplatten für Datenbanken, temporäre Dateien und Backup-Dateien.
Verwenden Sie eher SSDs für Datenbanken.
Reservieren Sie mindestens 30% freien Speicherplatz auf SSDs.
Es ist ratsam, eine Festplatte für die Datenbank zu reservieren.
Verwenden Sie Enterprise-SSDs (mit vielen Schreib-/Lesezyklen).
Stellen Sie sicher, dass Sie RAID verwenden.
Für SSD - RAID 1, für HDD - RAID10, für Backup-HDD - RAID1. i. SAS, SATA, nSAS
Stellen Sie sicher, dass die RAID-Batterie vorhanden und geladen ist.
Stellen Sie sicher, dass sie auf “write back” umgestellt ist.
Einige RAID-Controller haben die Cache-Größe bereits konfiguriert, z. B. 75% für Lesen, 25% für Schreiben oder 50/50 usw. Daher ist es notwendig, MON$Logger zu installieren - die Software, die RAID-Parameter steuert, das Lese-/Schreibverhältnis überwacht und die RAID-Einstellungen ändert.
Es gibt Vor- und Nachteile bei der Verwendung von SANs. Um das Beste daraus zu machen, sollten Sie das SAN richtig konfigurieren.
Um eine ausfallsichere Lösung zu erstellen, müssen Sie Lösungen mit Replikaten verwenden, die auf verschiedenen Servern laufen.

Kontakte

Die Firma IBSurgeon/IBase.ru entwickelt ein erweitertes HQbird-Verteilungspaket für Unternehmen, bietet komplexen technischen Support für Firebird und entwickelt maßgeschneiderte Verteilungspakete sowie die Lösung anderer komplexer Probleme.

IBSurgeon bietet auch den Firebird-Optimierungsservice an, um die Leistung von Firebird-Datenbanken zu verbessern.

Kontaktieren Sie uns: [email protected]