Optimieren von Firebird und Linux für eine Datenbank mit einer Größe von 691 GB und mehr als 1000 Benutzern

Firebird ist in Russland ein sehr beliebtes offenes DBMS und wird trotz fehlender lauter Marketingkampagnen in einer Vielzahl kritischer Systeme, insbesondere in medizinischen und staatlichen Automatisierungssystemen, eingesetzt.

Die Größe der Datenbank und die Anzahl der aktiven Benutzer in solchen Systemen sind in der Regel recht groß. In diesem Artikel werde ich daher auf die Erfahrungen mit der Optimierung von Firebird- und Linux-Einstellungen anhand spezifischer Beispiele für große Firebird-Datenbanken in BeZdorov (Ingosstrakh), AlfaZdrav , eingehen und auf die Erfahrungen anderer Optimierungsunternehmen eingehen Firebird + Linux.

Schauen wir uns das Thema Optimierung genauer an - Firebird 3.0.5 DBMS (mit HQbird-Erweiterungen), dient (derzeit) einer 691 GB großen Datenbank mit 1000 bis 1100 täglichen Benutzern, läuft unter Linux CentOS 7, der Server verwendet ein HP DL380-Eisen. Die Replikation auf den Sicherungsserver ist für die Datenbank konfiguriert (die Frage der Replikation liegt außerhalb des Geltungsbereichs dieses Artikels).

Das DBMS bedient das medizinische Informationssystem Infoklinika (hergestellt von der russischen Firma Smart Delta Systems ), eines der beliebtesten medizinischen Informationssysteme in Russland.

Werfen wir einen Blick auf die Details (die Screenshots stammen später von HQbird) des Betriebs dieser Datenbank:

Die Daten werden intensiv in die Datenbank eingefügt - ein täglicher Zuwachs von ca. 0,4 - 0,5 GB



1000-1100 Verbindungen sind die übliche tägliche Belastung:



Trotz intensiven Wachstums und aktiver Arbeit enthält die Datenbank keine nennenswerte Menge an Speicherbereinigungsversionen von Datensätzen - sowohl dank Anwendungen, die mit guten Kenntnissen der Architektur mit mehreren Versionen geschrieben wurden, als auch aufgrund der ordnungsgemäß konfigurierten Speicherbereinigung:



Transaktionsmarker in der grünen Zone:



Beachten Sie übrigens, dass die Daten in der Datenbank Zeichenfolgen sind, Blobs vorhanden sind, aber nur wenige - nur 10 GB von 690 GB der Gesamtgröße.

Die Art der Datenbanklast ist gemischt, 75% der Leseoperationen und 25% der Schreiboperationen:

Eisen

Der Server, der dieses System bedient, ist nicht schlecht, aber alles andere als top:

HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards 

Das Festplattensubsystem besteht aus zwei Teilen: einer lokalen 745-GB-Festplatte und einer dualen 2-Fibre-Channel-Verbindung zum SAN mit einer 1,8-TB-Partition.

Operationssystem

Unter CentOS 7, Kernelversion:

 Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019 

Auf die logische Frage, warum der modernste Kernel und CentOS 8 nicht verwendet werden, ist die Antwort ebenfalls logisch: Die Migration kritischer Systeme erfolgt erst nach der Veröffentlichung mehrerer Nebenversionen und strengen Tests. Dies ist einer der Fälle, in denen ein bekannter Fehler besser ist als zwei Unbekannte.

Es sollte jedoch beachtet werden, dass das System bis 2017 auf CentOS 6.x lief und nach der Migration eine signifikante Verbesserung der Leistungsindikatoren festgestellt wurde.

Linux-Setup

Eine unverzichtbare Linux-Anpassung für Firebird

Auf allen Linux-Servern, auf denen Firebird ausgeführt wird, müssen zwei Parameter erhöht werden: die Anzahl der virtuellen Speicherbereiche (VMA) und die Anzahl der geöffneten Dateien für den Firebird-Prozess.

1. VMA

Die Standard-VMA-Nummer ist 64 KB, sie muss viermal erhöht werden. Fügen Sie dazu die Zeile in sysctl.conf hinzu

 vm.max_map_count=262144 

Verwenden Sie den Befehl, um den aktuellen Wert zu überprüfen

 sysctl vm.max_map_count 

2. Max. Offene Dateien

Firebird öffnet für jede Verbindung zur Datenbank bis zu 20 Deskriptoren (Datei-Handles) (unter Linux sehen alle Ressourcen wie Dateien aus), sodass die maximale Anzahl der standardmäßig geöffneten Dateien (normalerweise 4096) sehr schnell ausgeschöpft werden kann.

Um die verfügbare Anzahl von Dateien für Firebird zu überprüfen, sollten Sie sich die Grenzen der ausführbaren Firebird-Datei ansehen:

 cat /proc/$(pgrep firebird)/limits 

Hier können Sie den Wert für "Max Open Files" überprüfen und gegebenenfalls erhöhen.

Um den Parameter Max Open Files für Firebird zu erhöhen, haben wir die Zeile zur Datei firebird-superserver.service im Abschnitt [service] hinzugefügt:

 LimitNOFILE=49999 

Optionales Linux-Setup

Auf diesem Server haben wir auch die folgenden Einstellungen vorgenommen

1. Reduzierte Swapiness

Da der Server ausschließlich für Firebird-DBMS reserviert ist und wir den Arbeitsspeicher im DBMS-Cache und im Dateicache des Betriebssystems effizient nutzen möchten, reduzieren wir die Auslagerungsrate von standardmäßig 60% auf 10%. Dazu haben wir sysctl.conf hinzugefügt

 vm.swappiness=10 

2. Die minimale reservierte Speichergröße für spezielle Betriebssystemprozesse wurde erhöht

 vm.min_free_kbytes=1048576 

1 GB Speicher. Diese Einstellung wirkt sich indirekt auf die Speicherdefragmentierung aus.

Bitte beachten Sie, dass diese Einstellung individuell ist - da 320 GB RAM zur Verfügung stehen, ist 1 GB nicht so viel, aber bei einer kleinen Speicherkapazität (z. B. 32 GB) kann 1 GB zu viel sein.

3. Reduziertes Keepalive

Firebird verwendet Keepalive-Intervalle, um den Verbindungsstatus zu überprüfen. Der Standardwert für Keepalive kann sehr groß sein. Wenn wir es auf 300 Sekunden beschränken, werden wir hängende Verbindungen los

 net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_probes=5 net.ipv4.tcp_keepalive_intvl=15 

Mehr Linux-Tuning

Warum sind wir auf so wenige Linux-Einstellungen beschränkt?

Erstens verfolgen wir einen konservativen Ansatz bei der Optimierung von Servern mit Linux (das mit jeder neuen Version immer besser wird), und zweitens ist diese Firebird-Datenbank weder extrem groß noch die am meisten ausgelastete, und Linux bewältigt die angegebenen Einstellungen mit Ihren Aufgaben.

Natürlich gibt es noch ein paar Einstellungen, mit denen die Arbeit von Firebird unter Linux optimiert werden kann - zum Beispiel wurden in der Präsentation über die 3 TB Firebird-Datenbank (RedBaza) im Federal Bailiff Service einige interessante Dinge vorgestellt.

Konfigurieren Sie Firebird

Die Konfigurationsdateien der Firebird-Community mit firebirdsql.org werden sehr konservativ konfiguriert. Auf einem mehr oder weniger leistungsstarken Server müssen Sie die Konfigurationsdateien ändern und die verwendete Architektur sorgfältig auswählen (in Firebird 3.0 gibt es zwei Arten von Verbindungen: Embedded und NetworkServer sowie drei Arten von Architekturen: SuperServer , SuperClassic, Classic).
Außerdem müssen Sie die Einstellungen für jede Datenbank verwenden - d. H. kritische Einstellungen in database.conf mit Bezug auf eine bestimmte Datenbank setzen.

In unserem Fall haben wir die SuperServer-Architektur gewählt, die in Version 3.0 am beliebtesten ist, weil Es verwendet effizient Multi-Core-Prozessoren und verfügt über einen Cache, der für alle Verbindungen gemeinsam genutzt wird (jedoch für jede Datenbank separat).

Im Folgenden sind die Konfigurationsdateien aufgeführt (nur leistungsbezogene Werte):

firebird.conf - Konfigurationsdatei für alle Datenbanken auf dem Server

 DefaultDbCachePages = 50K # pages FileSystemCacheThreshold = 300K # pages TempBlockSize = 2M # bytes TempCacheLimit = 20480M # bytes LockMemSize = 30M # bytes LockHashSlots = 30011 WireCompression = true ServerMode = Super ExtConnPoolSize = 500 # HQBird ExtConnPoolLifeTime = 14200 # HQBird SortDataStorageThreshold = 8192 #HQbird reports queries 

In Bezug auf die Leistung sind die wichtigsten Parameter hier:

1. DefaultDbCachePages = 50 KB # wird in Seiten in einer Datenbank auf Seite 16 KB = 0,8 GB gemessen

Die Größe des Seitencaches "DefaultDbCachePages" in der Datei "firebird.conf" ist standardmäßig auf 800 MB festgelegt, damit die versehentlich überfüllte Testdatenbank auf dem Server nicht versucht, sehr viel RAM zu belegen.

2. FileSystemCacheThreshold = 300 KB # Seiten

Es ist wichtig, diesen Parameter auf einen Wert größer als DefaultDBCachePages festzulegen, um die Verwendung des OS-Dateicaches zu ermöglichen.

3. TempCacheLimit = 20480M # Bytes

Dieser Parameter legt die Speichergröße für Abfragen mit Sortierungen (und einigen anderen Vorgängen) fest und ist für jedes System individuell.
Als Ergebnis der Überwachung der Sortengröße haben wir festgestellt, dass 20 GB für diese Datenbank optimal sind.

4. LockMemSize und LockHashSlots - Parameter der Sperrtabelle

Diese Parameter bestimmen die Anfangsgröße der Sperrtabelle und die Anzahl der Slots zur Berechnung der Hash-Funktion.

5. WireCompression = True

Das Konfigurieren des Datenverkehrs zwischen Clients und Servern ist besonders bei intensiven Execute Statement On External-Vorgängen hilfreich, bei denen die Clientanwendung ausgeführt wird.

Die restlichen Parameter sind in der firebird.conf selbst und der zugehörigen Dokumentation von Firebird und HQbird beschrieben.

Die wichtigsten Einstellungen haben wir in der database.conf mit der genauen Datenbank vorgenommen

 database1 = /data/database1.fdb { DefaultDbCachePages = 14080K # 16K pages, 220 GB FileSystemCacheThreshold = 15361K TempSpaceCacheThreshold=2G #HQbird only, track big sorts LockHashSlots = 40099 LockMemSize = 50M } 

Wie Sie sich vorstellen können, besteht die Hauptschwierigkeit in diesem Fall darin, die von unserer großen Datenbank zugewiesene Speichergröße korrekt zu berechnen.

Für Firebird 3.0 mit SuperServer-Architektur gibt es zwei Ansätze - konservativ. Diese Methode wird auf Servern mit einem geringen RAM-Anteil (bis zu 32 GB einschließlich) verwendet, bei denen nicht mehr als 25% RAM für den Seiten-Cache reserviert werden und ansonsten das Dateibetriebssystem verwendet wird Systeme und Feinabstimmung, wenn wir die optimale Größe für Sortierungen genau bestimmen, dem Betriebssystemkern eine bestimmte Speichergröße zuweisen, eine bestimmte Speichermenge für umfangreiche Dateivorgänge reservieren (z. B. Sicherung), der Rest für den Seiten-Cache zugeordnet.

Im zweiten Fall ist es nicht möglich, sofort die optimale Cachegröße zu erhalten, da die Art der Last für verschiedene Datenbanktypen sehr unterschiedlich sein kann. Nach mehreren Iterationen können Sie jedoch ein hervorragendes Ergebnis erzielen.

Häufige Fehler bei der Konfiguration von Firebird

Typische Fehler sind:

1) Die Größe des Seitencaches, der explizit auf der DB-Headerseite angegeben ist und die in firebird.conf und databases.conf angegebenen Werte überschreibt.

Besonders häufig tritt dieser Fehler auf, wenn die Architektur von Classic / SuperClassic auf SuperServer geändert wird. Wenn die Cache-Größe für die Classic / SuperClassic-Verbindung bei einer deutlich angegebenen kleinen Größe (500-2000 Seiten) einwandfrei funktioniert, wird für SuperServer ein viel größerer Cache benötigt.
Führen Sie zum Überprüfen den Befehl aus

 gstat -h databasepathname 

und überprüfen Sie den Page Buffers Wert - er sollte 0 sein, dann verwendet Firebird die Werte aus database.conf oder firebird.conf.

Führen Sie den Befehl aus, um die Einstellung für den Seitencache auf der Headerseite zurückzusetzen

 gfix -buff 0 databasepathname 

2) Wenn sie den Seiten-Cache erhöhen, vergessen sie, den FileSystemCacheThreshold zu erhöhen, was zur Trennung des Datei-Cache führt, was die Leistung verringert.

3) Verwenden Sie die Standardseitengröße der Datenbank (4096 oder 8192), während Sie für große Datenbanken 16 KB verwenden müssen.

Fazit

Im Allgemeinen arbeiten mehr als 1000 Firebird-Benutzer auf Eisen, die der von Linux konfigurierten und von Firebird konfigurierten Last entsprechen, ohne Probleme. Auf diesem Server gibt es eine Leistungsreserve, die bei Spitzenlasten für bis zu 1500-1800 Benutzer getestet wurde.

Unter den Linux-Distributionen für die Firebird-Datenbank mit einer ähnlichen Last ist CentOS 7 am beliebtesten, die empfohlene Version ist Firebird 3.0.

Bei Fragen stehe ich Ihnen gerne in den Kommentaren oder per E-Mail unter ak@ibase.ru zur Verfügung.