Kontakte
IBSurgeon
Diese Seite wurde maschinell übersetzt. Lesen Sie das englische Original. English

IBSurgeon-Bibliothek

23 weitere Möglichkeiten, Firebird zu beschleunigen

Alexey Kovyazin, IBSurgeon, [email protected], 08.01.2019

Übersetzungen: Portugiesisch

Warum „23 mehr"?

Einige von Ihnen erinnern sich an den Artikel « 45 Ways To Speed Up Firebird», der im Mai 2016 veröffentlicht wurde. Jetzt ist es an der Zeit, die nächste Serie von Tipps und Tricks zu veröffentlichen, die größtenteils auf der Erfahrung mit der Optimierung und Wartung von Firebird-Datenbanken und -Servern mit einer hohen Anzahl von Verbindungen (1000+) basieren.

1. Stellen Sie die Energieoptionen in Windows Server 2016 und 2019 auf Hohe Leistung

Standardmäßig ist in Windows Server der Energiesparplan auf „Ausbalanciert" eingestellt, was für Datenbankserver nicht geeignet ist. Stellen Sie ihn auf „Hohe Leistung" und gewinnen Sie etwa +20 % Leistung bei CPU-intensiven Operationen. Dies kann online, ohne Neustart oder Reboot, eingestellt werden. Das folgende Bild zeigt den CPU-Graphen, der den Vorteil des Energiesparplans „Hohe Leistung" demonstriert:

Weitere Details zu unseren Tests mit Windows-Energiesparplänen finden Sie hier.

2. Aktivieren Sie „Interact with desktop" bei Classic unter Windows

Wenn Sie Firebird mit der Classic-Architektur unter Windows verwenden, aktivieren Sie das Kontrollkästchen „Allow service to interact with desktop". Ohne diese Einstellung ist die Ressource „desktop heap" durch Windows begrenzt, und Firebird kann nicht mehr als 250-300 Verbindungen öffnen (abhängig von den Metadaten der Datenbank und dem damit verbundenen Speicherverbrauch) - es wird einen Out-Of-Memory-Fehler geben.

3. Vorsicht: Domain Controller

Das Problem besteht darin, dass Windows mit der Rolle Domain Controller den Schreibcache auf dem Datenträger mit der Active-Directory-Datenbank deaktiviert.

Dies wirkt sich auf verschiedene Weise auf Firebird aus (wie natürlich auch auf andere Anwendungen), und es zeigt eine deutlich schlechtere Leistung als auf Servern ohne Active-Directory-Rollen.

Bitte beachten Sie, dass dieses Problem auch so populäre Windows-Versionen wie Windows Small Business Server 2011 sowie andere Versionen mit DC betrifft.

4. Erhöhen Sie das Limit „max open files" unter Linux

Wenn Sie Linux als Datenbankserver verwenden, vergessen Sie nicht, die Limits für Firebird anzupassen. Prüfen Sie die Limits für Ihren Firebird-Prozess (SuperServer oder SuperClassic) mit dem folgenden Befehl:

Code 
cat /proc//limits

und achten Sie auf die Zeile mit der maximalen Anzahl geöffneter Dateien.

Firebird kann bis zu 4 Handles pro Verbindung verwenden, und wenn Sie etwas wie dies haben:

Code 
Max open files 4096 4096 files

bedeutet das, dass die Gesamtzahl der vom Firebird-Prozess bedienten Verbindungen auf etwa 1000 begrenzt wird.

Bitte beachten Sie - wenn Sie 4 Datenbanken auf dem Server haben, wird die Verbindung für jede Datenbank gezählt.

Setzen Sie mehr - ich empfehle 65535.

Vergessen Sie nicht, nach dem Neustart des Firebird-Prozesses erneut zu prüfen: wurde es angewendet oder nicht.

Bei der Classic-Architektur ist es notwendig, die Limits für den Benutzer „firebird" zu prüfen und zu erhöhen.

5. Verwenden Sie modernes Linux

Ja, ich verstehe, dass dieser Ratschlag trivial ist, aber ich habe viele Male die gute Leistungsverbesserung nach der Migration von CentOS 6 auf 7, Ubuntu 12 auf 16 (auf derselben Hardware!) gesehen, daher ist es jetzt die unverzichtbare Empfehlung für Datenbankserver mit mehr als 250-300 Verbindungen. Das moderne Linux ist eine Voraussetzung vor weiteren Optimierungsschritten.

Empfohlene Linux-Versionen: CentOS 7.x und Ubuntu 16, 18.

6. Reservieren Sie 40 % RAM für den Dateicache unter Windows

Der OS Memory Manager hat Auswirkungen auf die Speicherzuweisung, und standardmäßig benötigt Windows 40 % des RAM für den Dateicache.

Leider zeigt das schlechte Tool Windows Task Manager den Speicher, der für den Dateicache verwendet wird, als „frei" an, und einige Administratoren versuchen, Firebird dazu zu bringen, all diesen freien Speicher zu verbrauchen, indem sie den Parameter DefaultDBCachePage in firebird.conf auf sehr hohe Werte setzen, was normalerweise zu Swapping führt.

Verwenden Sie immer das Tool RAMMap, um die tatsächliche Speichernutzung unter Windows zu sehen.

Die empirische Regel für Windows Server (dediziert für die Verwendung als Firebird-Server) ist die folgende: Der Firebird-Speicher (Working Set) sollte weniger als 40 % des Gesamt-RAM betragen. Wenn die Gesamtgröße der Working Sets für alle Prozesse mehr als 50 % beträgt, kann Windows mit dem Swapping beginnen.

Bitte beachten Sie: „Reservieren" bedeutet hier nicht nur „nicht zu viele Seitenpuffer in Firebird setzen", sondern auch - und das ist wichtig - die Speichernutzung anderer Software einzuschränken. Wenn Sie beispielsweise MS Exchange oder MSSQL auf demselben Server wie Firebird haben, stellen Sie sicher, dass Sie deren Speicherhunger einschränken.

Wenn Sie Details dazu wissen möchten, habe ich ein Webinar aufgezeichnet, das sich dem Speichermanagement in Firebird widmet:

7. Reservieren Sie 30 % des RAM für den Dateicache unter Linux

Linux arbeitet mit dem Dateicache auf eine andere Weise als Windows, und im Allgemeinen kann die für den Dateicache verwendete RAM-Menge deutlich geringer sein als unter Windows, ohne spürbare Leistungseinbußen bei Firebird. Um jedoch eine hohe Leistung des Systems mit der hohen Anzahl von Verbindungen zu gewährleisten, insbesondere bei Classic und SuperClassic, ist es eine gute Idee, 30 % des RAM für den Dateicache zu reservieren.

8. Verwenden Sie irqbalance unter Linux

irqblalnce verbessert oft die Firebird-Leistung und die CPU-Lastverteilung auf Servern mit einer hohen Anzahl von Kernen.

9. Für virtuelle Maschinen - hüten Sie sich vor Memory Overcommit

Eine virtuelle Maschine kann so konfiguriert werden, dass sie mehr Speicher hat, als physisch auf dem Host-Rechner vorhanden ist - mit einer Funktion namens Memory Overcommit (der Name kann auf den verschiedenen Virtualisierungssystemen unterschiedlich sein). Das bedeutet, dass im Falle einer Spitze des Speicherverbrauchs (auf der VM mit dem Datenbankserver oder auf der benachbarten VM) das Swapping beginnen kann, was zu erheblichen Verzögerungen führt. Für eine Hochleistungs-VM, die für einen Datenbankserver vorgesehen ist, sollte der gesamte Speicher statisch sein.

10. Für virtuelle Maschinen - prüfen Sie die VM-Limits

Oft werden VMs mit Standard-CPU- und IO-Limits erstellt, die sehr niedrig sein können, wie 50 IOPS und 10 % CPU. Prüfen Sie die Einstellungen Ihrer Server-VM und entfernen Sie alle Limits - ein Hochleistungs-Datenbankserver sollte über alle möglichen CPU-, Bandbreiten- und IO-Ressourcen verfügen.

11. Bereinigen Sie die temporären Dateien von Firebird

Firebird erstellt viele temporäre Dateien für verschiedene Operationen: Sortieren, BLOB-Verarbeitung, Tracing. Diese Dateien werden an den folgenden Orten gespeichert: unter Windows C:\ProgramData\firebird, unter Linux / tmp / firebird

Normalerweise sollten diese Dateien automatisch bereinigt werden, manchmal geschieht dies jedoch nicht (zum Beispiel im Falle eines Server-Neustarts).

Prüfen Sie diese Ordner regelmäßig und bereinigen Sie alte Dateien - es können viele GB veralteter Dateien fb_NNN vorhanden sein, und deren Bereinigung gibt Speicherplatz auf dem Systemlaufwerk frei.

12. Vergessen Sie nicht, den Dateicache bei großem Firebird-Cache zu aktivieren

Wie Sie wissen, wird der Firebird-Cache (auch „Seitenpuffer" genannt) durch den Parameter DefaultDBCachePages in firebird.conf/databases.conf oder direkt im Header der Datenbank angegeben.

In Firebird 3 SuperServer kann die Größe dieses Caches sehr hoch eingestellt werden, aber es ist wichtig, sich an einen anderen Parameter zu erinnern: FileSystemCacheThreshold.

Wenn FileSystemCacheThreshold kleiner ist als DefaultDBCachePages oder die Seitenpuffer, wird der Dateicache des Betriebssystems nicht verwendet, was zu Leistungsproblemen führen kann.

In 99 % der Fälle ist es besser, den Dateicache aktiviert zu haben.

Um dies sicherzustellen, setzen Sie die Parameter immer nach der folgenden Regel:

  • DefaultDBCachePages = X
  • FileSystemCacheThreshold = X+ N, N>1

Es gibt seltene Fälle, in denen das Deaktivieren des Dateicaches die Leistung verbessert - wenn Sie ein solches Beispiel haben, kontaktieren Sie mich bitte - [email protected]!

13. Beschleunigen Sie die Sicherheitsdatenbank

Jede Verbindung zur Firebird-Datenbank stellt die Verbindung zur Sicherheitsdatenbank her (security3.fdb im Falle von Firebird 3) und führt mehrere Lese- und Schreibvorgänge durch (Transaktionsseiten, Header-Seite). Wenn Sie häufige Verbindungen haben, kann die Leistung Ihrer Sicherheitsdatenbank zu einem Problem werden.

Als Minimum können Sie Folgendes tun:

  • Erhöhen Sie die Seitenpuffer für securityN.fdb (empirisches Optimum ist 256 Puffer)
  • Verschieben Sie security3.fdb auf das schnelle Laufwerk (es ist eine Standardfunktion in Firebird 3, in 2.5 erfordert es eine Neuinstallation)

Dann können Sie Forced Writes OFF für die Sicherheitsdatenbank setzen - die geringe Wahrscheinlichkeit einer Beschädigung ist in diesem Fall kein Problem.

Der radikalste Weg ist, die Sicherheitsdatenbank schreibgeschützt zu machen - dies eliminiert alle Schreibvorgänge darauf.

Wenn Sie Benutzer in der Sicherheitsdatenbank nicht oft ändern, ist dies die beste Lösung.

14. Probieren Sie SuperClassic auf Firebird 3

In Firebird 3 wurde die SuperServer-Architektur stark als die ultimative Leistungslösung beworben, aber es gibt einige Lasttypen, die mit SuperClassic eine bessere Leistung zeigen (aber nicht Classic - es arbeitet immer langsamer als SuperServer/SuperClassic).

Wie führt man dieses Experiment auf sichere Weise durch? Befolgen Sie die folgenden Schritte:

Um SuperClassic auszuprobieren

  1. Setzen Sie in firebird.conf
  2. ServerMode=SuperClassic
  3. DefaultDbCachePages=1024
  4. gfix -buff 0
  5. Starten Sie Firebird neu

Um zu SuperServer zurückzukehren

  1. Setzen Sie in firebird.conf
  2. ServerMode=SuperServer
  3. DefaultDbCachePages=N # N*page size*databases_count < 25% RAM
  4. FileSystemCacheThreshold = N+1
  5. gfix -buff 0
  6. Starten Sie Firebird neu

Bitte schreiben Sie mir ([email protected]) über die Ergebnisse des Experiments, ich bin gespannt auf die Ergebnisse.

15. Große Datenbank? Erhöhen Sie die Seitengröße

Standardmäßig haben Firebird-Datenbanken die folgenden Seitengrößen:

  • 2.5 - 4096 Bytes
  • 3.0 - 8192 Bytes

Die maximale Seitengröße ist jedoch 16K (in 4.0 - 32K).

Für Datenbanken mit mehr als 100 GB ist es in 95 % der Fälle besser, die höchstmögliche Seitengröße zu haben, um:

  • Die Tiefe der Indizes zu verringern. Es wird empfohlen, Indizes mit einer Tiefe von weniger oder gleich 3 zu haben. Indizes mit Tiefe 4 und 5 sind viel langsamer
  • Die Auslastung des RAM zu erhöhen. Der Firebird-Cache wird in Seiten angegeben, 1000 Seiten mit 8K Seitengröße sind 8 MB tatsächlicher Speicher, und mit 16K - 16 MB.
  • Die Anzahl der Systemseiten zu verringern. Dies beschleunigt den Zugriff auf die Datensätze der großen Tabellen (weniger Sprünge Pointer-Pointer-Datenseite) und hilft bei der Vorbereitung der großen SQL-Abfragen. Um die Seitengröße der Datenbank zu erhöhen, sollte die Datenbank mit dem gbak-Tool gesichert und dann mit dem Parameter -page wiederhergestellt werden ( gbak -c -page 16384).

Bitte beachten Sie: Wenn Sie eine Datenbank mit vielen kleinen Blobs haben, kann das Erhöhen der Seitengröße entweder die Fragmentierung verringern oder die Fragmentierung erhöhen, und es ist schwierig vorherzusagen, ob sie die Leistung erhöht oder verringert.

16. Verwenden Sie nicht das no_reserve-Flag

Das Flag no_reserve bewirkt, dass Firebird keinen freien Speicher (30 %) auf Datenseiten für die möglichen Datensatzversionen reserviert, die nach UPDATE oder DELETE auftreten. Dieses Flag ermöglicht es, die Daten kompakter zu speichern (und die Größe der Datenbank ist ebenfalls geringer), aber im Falle von UPDATE/DELETE gehen alle Änderungen auf die neue Datenseite. Infolgedessen sind in der Datenbank mit dem no_reserve-Flag UPDATE/DELETE-Operationen langsamer.

Wenn Ihre Datenbank also nicht schreibgeschützt ist, empfehle ich, das Flag no_reserve zu entfernen.

Wie man prüft, ob es gesetzt ist oder nicht - siehe Zeile Attributes in der Ausgabe von

Code 
gstat -h database

Wie man es deaktiviert:

Code 
gfix -use reserve database

Nach diesem Befehl werden die neuen Datenseiten mit reserviertem Speicher erstellt.

Um jedoch den vollen Effekt zu erzielen, ist es notwendig, eine Datenbank mit gbak zu sichern und dann wiederherzustellen; in diesem Fall werden alle Datenseiten mit reserviertem Speicher versehen.

Bitte beachten Sie: Die Datenbankgröße wird nach dem Entfernen des no_reserve -Flags und der Sicherung/Wiederherstellung wachsen.

17. Setzen Sie eine hohe Anfangsgröße für die Firebird-Sperrtabelle

Die Sperrtabelle ist der Mechanismus von Firebird, der zur Synchronisierung des Zugriffs auf die internen Engine-Objekte verwendet wird.

Die Firebird-Sperrtabelle kann automatisch wachsen, aber ihr Wachstum ist eine langsame Operation, die zu Mikro-Freezes führen kann. Die Sperrtabelle kann nur wachsen, ausgehend von der Anfangsgröße (sie wird in firebird.conf festgelegt).

Um mehrere Runden der Vergrößerung der Sperrtabelle zu vermeiden, ist es eine gute Idee, die Größe der Sperrtabelle am Ende des Arbeitszeitraums (Tag, Woche usw.) zu beobachten und sie dann als Anfangsgröße in firebird.conf festzulegen.

LockMemSize=99999999

Zur Orientierung: LockMemSize liegt auf Hochlastsystemen mit ~1000 Benutzern normalerweise unter 200 MB.

18. Verwenden Sie fb_lock_print, um die Anzahl der Verbindungen zur Datenbank zu zählen

Das Ermitteln der Anzahl der Datenbankverbindungen ist eine häufige Aufgabe für Datenbankentwickler: Sie kann beispielsweise für Lizenzierungszwecke erforderlich sein.

Oft verwenden Entwickler die Abfrage SELECT count(*) FROM MON$ATTACHMENTS, um diesen Wert zu erhalten, aber das ist nicht der optimale Weg: Häufige Abfragen auf MON$-Tabellen können eine Belastung für die Datenbank darstellen, daher sollte besser die Alternative verwendet werden:

Führen Sie

fb_lock_print -d database_name | alias

aus und prüfen Sie den Wert Owners – er zeigt die aktuelle Anzahl der Verbindungen zur Datenbank an.

19. Vermeiden Sie unnötige LEFT JOINs

Oft sehe ich Abfragen mit Konstruktionen wie dieser:

T1 LEFT JOIN T2 ON (…) WHERE T2.Field_condition

Im Wesentlichen schließt die Bedingung auf T2 NULLs aus der Ausgabe von LEFT JOIN T2 aus, sodass es möglich ist, LEFT JOIN in INNER JOIN zu ändern – dies wirkt sich nicht auf das Ergebnis der Abfrage aus.

INNER JOIN gibt dem Firebird-Optimizer mehr Freiheit, und in den modernen Versionen von Firebird wird er viel besser optimiert als LEFT.

Besonders sinnvoll ist dies in den folgenden Fällen:

  • Keine Bedingung für T1 in der WHERE-Klausel
  • T2 ist eine kleine Tabelle

20. Vermeiden Sie unnötiges Zählen von Datensätzen

Ein weiterer häufiger Fehler in komplexen Datenbankabfragen und Stored Procedures ist die Verwendung von select count(), nur um die Existenz des Datensatzes zu prüfen.

Die folgende Abfrage liest alle Datensätze gemäß condition1:

Code 
(select count(*)…. where condition11) >0

Verwenden Sie stattdessen besser diese Konstruktion

Code 
Exists(select first 1 id where condition1)

Wenn condition1 mehr als 1 Datensatz zurückgibt, ist die vorgeschlagene Variante viel schneller, da sie nicht alle Datensätze liest, sondern nach dem ersten abgerufenen Datensatz stoppt.

21. Vermeiden Sie unnötiges Sortieren in Stored Procedures

Die Sortierung der Abfrageergebnisse innerhalb der Stored Procedure sollte durch die Geschäftslogik gerechtfertigt sein.

Im Beispiel der unten stehenden Stored Procedure ist die ORDER BY-Klausel aus Sicht der Geschäftslogik beispielsweise nutzlos, fügt aber eine unnötige Sortieroperation hinzu.

Code 
create or alter procedure NEW_PROCEDURE
returns (
    SUMX double precision)
as
declare variable _amount double precision;
begin
for select T1.amount from Table1 t1 where ....
    order by id
    into :_amount
    do
    begin
     sumx=sumx+_amount
    end;
  suspend;
end

Prüfen Sie Ihren PSQL-Code auf ähnliche Situationen und entfernen Sie nutzlose ORDER BY (sowie distinct und UNION).

22. Halten Sie Abfragen nicht ohne Notwendigkeit im vorbereiteten Zustand

Oft sehen wir 500-1000 vorbereitete Statements in jeder Verbindung (dies kann mit MON$-Abfragen überprüft werden).

Die überwiegende Mehrheit von ihnen wird nur einmal ausgeführt und liegt dann einfach im RAM, wodurch der Working Set von Firebird größer wird und MON$-Abfragen verlangsamt werden.

Die Empfehlung ist, SQL-Abfragen nur dann im vorbereiteten Zustand zu halten, wenn sie viele Male gestartet werden sollen oder wenn ihre Vorbereitungszeit groß ist (was bei sehr großen Abfragen mit vielen Joins und Zugriff auf riesige Tabellen der Fall sein kann).

23. Schließen Sie Abfragen mit großer Sortierung immer

Solange eine SQL-Abfrage mit Sortierung (ORDER BY, GROUP BY, UNION, distinct) nicht geschlossen ist, behält Firebird die sortierten Datensätze im Speicher. Die für die Sortierung zugewiesene Speichergröße wird durch den Parameter TempCacheLimit in firebird.conf festgelegt; standardmäßig beträgt sie 64 MB.

Selbst bei erhöhtem TempCacheLimit werden lang laufende Abfragen mit einer großen Anzahl sortierter Datensätze irgendwann die gesamte zugewiesene Menge verbrauchen, und infolgedessen wird die Sortierung auf temporäre Dateien (d. h. auf die Festplatte) ausgelagert. Das kann zu erheblicher Langsamkeit führen.

Die Empfehlung ist, alle solche Abfragen rechtzeitig zu schließen.

Fragen?

Bitte kontaktieren Sie mich bei Fragen gerne unter: [email protected]!