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-Jan-2019

Übersetzungen: Portugiesisch

Warum „23 weitere"?

Einige von Ihnen erinnern sich an den Artikel « 45 Wege, um Firebird zu beschleunigen», der im Mai 2016 veröffentlicht wurde. Jetzt ist es Zeit, die nächste Serie von Tipps und Tricks zu veröffentlichen, die hauptsächlich auf Erfahrungen mit der Optimierung und Wartung von Firebird-Datenbanken und Servern mit einer hohen Anzahl von Verbindungen (1000+) basiert.

1. Energieoptionen auf „Höchstleistung" in Windows Server 2016 und 2019 einstellen

Standardmäßig hat Windows Server einen Energiesparplan „Ausbalanciert", der für Datenbankserver nicht geeignet ist. Stellen Sie ihn auf „Höchstleistung" und gewinnen Sie etwa +20% Leistung für CPU-intensive Operationen. Dies kann online ohne Neustart oder Reboot eingestellt werden. Das Bild unten zeigt die CPU-Grafik, die den Vorteil des „Höchstleistung"-Energiesparplans demonstriert:

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

2. „Interaktion mit dem Desktop" bei Classic für Windows aktivieren

Wenn Sie Firebird mit Classic-Architektur unter Windows verwenden, aktivieren Sie das Kontrollkästchen „Dienst darf mit dem Desktop interagieren". Ohne diese Einstellung wird die Ressource „Desktop-Heap" von 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 ein Out-Of-Memory-Fehler auftreten.

3. Vorsicht: Domänencontroller

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

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

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

4. „Max open files"-Limit unter Linux erhöhen

Wenn Sie Linux als Datenbankserver verwenden, vergessen Sie nicht, die Limits für Firebird anzupassen. Überprü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 offener Dateien.

Firebird kann bis zu 4 Handles pro Verbindung verwenden, und wenn Sie so etwas sehen:

Code 
Max open files 4096 4096 files

bedeutet dies, dass die Gesamtzahl der Verbindungen, die vom Firebird-Prozess bedient werden, auf etwa 1000 begrenzt ist.

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, ob es angewendet wurde oder nicht.

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

5. Modernes Linux verwenden

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

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

6. 40% RAM für Dateicache unter Windows reservieren

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

Leider zeigt das einfache Tool Windows Task Manager Speicher, der für den Dateicache verwendet wird, als „frei" an, und einige Administratoren versuchen, Firebird den gesamten freien Speicher verbrauchen zu lassen, 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) lautet: Firebird-Speicher (Working Set) sollte weniger als 40% des gesamten RAM betragen. Wenn die Gesamtgröße der Working Sets aller 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 einstellen", sondern auch, den Speicherverbrauch anderer Software zu begrenzen. Wenn Sie beispielsweise MS Exchange oder MSSQL auf demselben Server wie Firebird haben, stellen Sie sicher, dass deren Speicherappsitite begrenzt sind.

Wenn Sie an Details interessiert sind, habe ich ein Webinar zur Speicherverwaltung in Firebird aufgenommen:

7. 30% RAM für Dateicache unter Linux reservieren

Linux arbeitet anders mit dem Dateicache als Windows, und im Allgemeinen kann die Menge an RAM, die für den Dateicache verwendet wird, deutlich geringer sein als unter Windows, ohne spürbare Leistungseinbußen bei Firebird. Um jedoch eine hohe Leistung des Systems mit einer 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. irqbalance unter Linux verwenden

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

9. Für virtuelle Maschinen - Vorsicht vor Memory Overcommit

Eine virtuelle Maschine kann so konfiguriert sein, dass sie mehr Speicher hat, als physisch auf dem Host vorhanden ist - mit einer Funktion namens Memory Overcommit (der Name kann in verschiedenen Virtualisierungssystemen unterschiedlich sein). Dies bedeutet, dass im Falle eines Speicherverbrauchsspitzenwerts (auf der VM mit dem Datenbankserver oder auf der benachbarten VM) 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 - VM-Limits überprüfen

Oft werden VMs mit Standard-CPU- und IO-Limits erstellt, die sehr niedrig sein können, wie 50 IOPS und 10% CPU. Überprüfen Sie die Einstellungen Ihrer Server-VM und entfernen Sie alle Limits - ein Hochleistungs-Datenbankserver sollte die gesamte mögliche CPU, Bandbreite und IO haben.

11. Firebird-Temporärdateien bereinigen

Firebird erstellt viele temporäre Dateien für verschiedene Operationen: Sortierung, 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, aber manchmal passiert das nicht (z.B. bei einem Server-Neustart).

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

12. Vergessen Sie nicht, den Dateicache mit 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 Kopf 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 als DefaultDBCachePages oder die Seitenpuffer ist, 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. Sicherheitsdatenbank beschleunigen

Jede Verbindung zur Firebird-Datenbank stellt eine Verbindung zur Sicherheitsdatenbank her (security3.fdb bei Firebird 3) und führt mehrere Lese- und Schreibvorgänge durch (Transaktionsseiten, Kopfseite). Wenn Sie häufige Verbindungen haben, kann die Leistung Ihrer Sicherheitsdatenbank zum Problem werden.

Mindestens können Sie Folgendes tun:

  • Seitenpuffer für securityN.fdb erhöhen (empirisches Optimum ist 256 Puffer)
  • security3.fdb auf ein schnelles Laufwerk verschieben (dies ist eine Standardfunktion in Firebird 3, in 2.5 erfordert es eine Neuinstallation)

Dann können Sie Forced Writes für die Sicherheitsdatenbank auf OFF setzen - das geringe Risiko 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 nicht oft Benutzer in der Sicherheitsdatenbank ändern, ist dies die beste Lösung.

14. SuperClassic bei Firebird 3 ausprobieren

In Firebird 3 wurde die SuperServer-Architektur stark als 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ühren Sie dieses Experiment sicher 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*Seitengröße*Anzahl_der_Datenbanken < 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 an den Ergebnissen interessiert.

15. Große Datenbank? Seitengröße erhöhen

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

  • 2.5 - 4096 Bytes
  • 3.0 - 8192 Bytes

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

Für Datenbanken über 100 GB ist es in 95% der Fälle besser, die höchste verfügbare 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 werden viel langsamer sein
  • Die Nutzung des RAM zu erhöhen. Der Firebird-Cache wird in Seiten angegeben, 1000 Seiten mit 8K Seitengröße ergeben 8 MB tatsächlichen 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 Zeiger-Zeiger-Datenseite) und hilft bei der Vorbereitung großer 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 die Erhöhung der Seitengröße die Fragmentierung entweder verringern oder erhöhen, und es ist schwer vorherzusagen, ob die Leistung steigt oder sinkt.

16. no_reserve-Flag nicht verwenden

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

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

Wie Sie überprüfen, ob es gesetzt ist oder nicht - sehen Sie die Zeile Attributes in der Ausgabe von

Code 
gstat -h database

Wie Sie es deaktivieren:

Code 
gfix -use reserve database

Nach diesem Befehl werden neue Datenseiten mit reserviertem Speicherplatz 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 Speicherplatz erstellt.

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

17. Hohe Anfangsgröße für die Firebird-Sperrtabelle festlegen

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

Firebird-Sperrtabelle kann automatisch wachsen, aber ihre Vergrößerung ist eine langsame Operation, die zu Mikro-Freezes führen kann. Die Sperrtabelle kann nur wachsen, beginnend mit der Anfangsgröße (diese 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 überwachen und sie dann als Anfangsgröße in firebird.conf festzulegen.

LockMemSize=99999999

Zu Ihrer Information: LockMemSize liegt bei Systemen mit hoher Last und ~1000 Benutzern normalerweise unter 200 MB.

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

Die Anzahl der Datenbankverbindungen zu ermitteln, 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 ist es besser, die Alternative zu verwenden:

Führen Sie aus:

fb_lock_print -d Datenbankname | Alias

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

19. Vermeiden Sie unnötige LEFT JOINs

Oft sehe ich Abfragen mit einer Konstruktion wie dieser:

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

Im Wesentlichen schließt die Bedingung an T2 NULLs aus der Ausgabe des LEFT JOIN T2 aus, daher ist es möglich, LEFT JOIN in INNER JOIN zu ändern - das Ergebnis der Abfrage wird dadurch nicht beeinflusst.

INNER JOIN gibt dem Firebird-Optimierer mehr Freiheit, und in den modernen Versionen von Firebird wird es 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 gespeicherten Prozeduren ist die Verwendung von select count(), nur um die Existenz eines 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 einen Datensatz zurückgibt, ist die vorgeschlagene Option viel schneller, da sie nicht alle Datensätze liest, sondern nach dem ersten abgerufenen Datensatz stoppt.

21. Vermeiden Sie unnötige Sortierung in gespeicherten Prozeduren

Die Sortierung der Abfrageergebnisse innerhalb der gespeicherten Prozedur sollte durch die Geschäftslogik gerechtfertigt sein.

Zum Beispiel ist in der untenstehenden gespeicherten Prozedur die ORDER BY-Klausel aus Sicht der Geschäftslogik 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

Überprüfen Sie Ihren PSQL-Code auf ähnliche Situationen und entfernen Sie unnötiges ORDER BY (sowie distinct und UNION).

22. Halten Sie Abfragen nicht ohne Notwendigkeit im vorbereiteten Zustand

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

Die überwiegende Mehrheit davon wird nur einmal ausgeführt und sitzt dann nur im RAM, wodurch der Firebird-Arbeitssatz 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 (dies kann bei sehr großen Abfragen mit vielen Joins und Zugriffen auf riesige Tabellen der Fall sein).

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 mit erhöhtem TempCacheLimit werden langlaufende Abfragen mit einer großen Anzahl sortierter Datensätze irgendwann die gesamte zugewiesene Menge verbrauchen, und als Ergebnis geht die Sortierung in temporäre Dateien (d. h. auf die Festplatte). Dies kann zu erheblicher Verlangsamung führen.

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

Fragen?

Bitte zögern Sie nicht, mich bei Fragen zu kontaktieren: [email protected]!